GRG's Miscellany

Picante: Basic Graphics Features Complete! The fundamental graphics feature set is there:  clearing the screen drawing 32x32 bitmaps with optional transparent colour index drawing coloured text from bitmap font All features are accessible via python script and clip against the screen edge. It's not yet built to be robust - I was having too much fun to bother writing exhaustive error checking. Whilst the basic design is meant to be fairly speedy without eating too much RAM, there's plenty more that can still be done to optimise it. Blitting: The tiles are processed from a single bitmap, but blitted individually (no fast tilemap feature yet).  It runs at about 15fps, all off a single core.    Text: The text is processed from a png into a 1bpp binary format for the picante engine to load.  This runs at about ~20fps. It's designed to be able to handle any font up to 8x16px, but I've only tested it with the 3x5 tom-thumb font so far.  The small screen really ne...

What's gone wrong My initial approach to rendering in a timely manner involved native/C code to 'blit' bitmaps to an 8bpp render buffer.  Every frame, that render buffer is expanded into 16bpp stripes for transfer to the display.  At about 18-19fps, this was pretty tidy. The next step I wanted to take was to render tilemaps to the background, so I found a tileset online and converted into bytes() objects in a .py file for import...and promptly ran out of RAM. The New Proposed Approach So then I started looking at a 4bpp (16 colour) render buffer with colour palette, and I didn't like the amount of pixel operations involved in drawing to it, let alone expanding it out to the stripe for display. So my intention now is to store a list of render commands for each stripe of the display.  These commands could be partial 'blits' of a bitmap, or straight colour-fill, or whatever else.  The key thing is that they are only actually executed once all render commands have b...

In The Beginning... I'd been experimenting with SPI displays on the Micro:bit before now and was lamenting how little RAM they have. So when I read about the Pi Pico 's whopping great 264KB of RAM I immediately wanted to make a DOS-a-like handheld game platform.  It easily has enough RAM for a full 320x240x8bpp frame buffer and at 133MHz it's about the same speed as an original-series Pentium.  Plus, it's dual core! All those figures made me think it would be an absolute doddle to make a DOS-a-like. ...but then I started to think about how it would actually be used.  Sure, I could make it so that C programmers could make games for it, but that might just end up with curiosity value. But what if I could make it so that the students I teach could program games in Python?  That way it would have loads of inspiration power whilst also having high educational value! With the magic mix of both idea and plausible use case, I set about making a prototype. The Hardwa...

I've finally got off my backside and tested out the N20 motors I ordered what feels like a billion years ago .  Part of the delay was that I lost the original L293D motor controllers I was going to use.  I am just that awesome. It took a little fiddling around, but I got the motor and raspberry pi powered from an ATX PSU and the pi's pins connected via an IDE cable to the L9110S module I got from ebay . Then, I used gpiozero's PWMOutputDevice to create a forward device on one pin and a backward device on the other.  I didn't even have to faff about with the frequencies - just set the value on the object and away it went! So now, my plan is to build the base frame for my CNC router and attach this motor to a threaded rod and rotary encoder.  Fingers crossed that tiny motor has enough torque to move the cutting tray. :S