Actually I’m not up on ARM assembly code at all. I was a layout engineer. I designed the cache memory for the ARM810 and ARM 920. That was 20 years ago now!
My problem was that, as jwunderl suggested, I had edited the Readme file directly in Github and things got out of sync, hence the Conflict. Without that, the PR from Makecode would presumably have been smoother and more intelligible. However, it probably still remains the case that the Makecode editor got its knickers in a twist when I deleted an extension by brute force. It’s not quite idiot-proof.
Yes we need to be more resilient with the deleted local dependencies.
Typically, if github can merge the PR, it will just happen. This is the happy path. If you make conflicting changes, we have a UI to resolve conflicts when you pull changes into your branch; but we are missing a way to merge changes from master right now – so that you could benefit from that UI. It’s planned, hasn’t happened yet. Glad this got resolved
I’m keeping it simple. I’m knocking together a veroboard with a joystick, four buttons, Microbit connector, one LED display. I’ve been soldering it just now.
Having written my graphics routines for the Pimoroni scroll bit which uses the IS31FL3731 charlieplexing driver IC - finding that the published extension was as lame as an old dog with a wooden leg - I have just translated it for this small 9x16 LED array and driver board using the same IC:
This has the rows and columns in a sensible order so is much better.
I’ve also ordered a pair of these tri-colour 8x8 stackable arrays so I can do something similar but with colours.
The point of this is to do very simple programming with our 11-yr old and to keep it bare-bones. However, within my extension I’ve made routines which scrolls the screen in all four directions and also creates a “world” upon which the 9x16 display is a window which can be position anywhere. Also a separate, fixed, 9x16 pixel buffer can be overlaid onto the display so that game characters which are fixed in the centre of the display are stored in a separate field.
My first project for my own amusement will be to recreate the old 1978 Apple II “Dragonmaze” game wth a maze of any size using my window-on-the-world routines. That was my introduction to programming back in 1980 or thereabouts.
Hmm, so there are two projects in my Makecode workspace which now won’t open presumably because I deleted the local copy of my scrollbit extension and despite the fact I have reloaed the lastest version after committing the changes.
How can I access these two projects? One of them is the bat and ball game that I got our youngest to work on with me. I can recreate it but that’s not ideal. The Makecode editor is stuck…
Thst might need a bit of work / be annoying to deal with, as a proper fix will require you to look at the browser database. I’ll try to replicate it real quick so I can get exact instructions - what browser are you using?
