Microsoft MakeCode

My extension for the Pimoroni scrollbit

My graphics extension for the Pomoroni Scroll:bit 17x7 LED matrix is now on github. The file is 75% complete but more functions (for the window mode) will be added later.

All the pixel, line, scroll and text-scroll functions work but the extension is still a work in progress.

I’ve got a question about out-of-range plotting error detection: my pixel routines don’t yet do full out-of-range error detection because I noticed that putting a value int a negative buffer index like this
x = -1
pixel_buffer[x] = 1

doesn’t appear to do any damage! However if x is 17 and the buffer is only 16 long, that does cause an error and the Microbit will crash. Am I OK to leave out negative error detection? What happens when addressing a negative buffer index?

You were lucky, you will want to do bounds check and ignore any input that is out of bound.

I noticed that you are using the built-in font in C++. We’ll have to see if we can give you a hook so that you can retrive that in TypeScript. In general, C++ should be avoided as it adds cloud compilation and does not work offline.

See this docs about enabling blocks rendering in your repo

Font: the font.cpp file is inherited from the original Pimoroni scrollbit extension. I didn’t bother to look to see if there was a Typescript function to access it, and I assumed this was in C++ for a good reason. Let me know what is the best thing to do!

Bounds: Interesting, as I just did a few experiments on out of bounds buffers indexes. Is there a definitive answer as to what actually happens? I tried defining a buffer length 7 and wrote to the non-existent [7] element and this did not crash the Microbit. However, creating a buffer length 8 and writing to the [8] element did crash it. Something to do with multiples of 2 or 4 bytes being the actual memory usage?

Luckily my y-coord is a bitwise operation which has no effect when given an on out-of-range Y, so I don’t need to check both x and y for bounds, only the x.

SVG: Do you prefer that I put SVG examples in the document? I can do that at some point. If there’s a chance this extension can be approved - it will certainly make the Pimoroni Scroll:bit a dmaned sight more useable - then I’ll happy put in some extra effort.

I’m just adding a rectangle draw routine and I have additional things to do with the extended window mode but I’m mulling over whether to make that a separate “advanced scrollbit” extension instead of one monstrous one.

Bounds: we check them…

I am currently using direct access via buffer[index] rather than buffer.setByte. I should so some runtime speed tests to see whether to use the in-built routines where bound-checking will be necessary.

You don’t need to put svg in the readme. if you use the “blocks” fenced code regions and our little javascript renderer, we’ll generate those on the fly.

Adding support for smaller buttons