GRG's Miscellany

My plan was always to do a SID-style synthesizer so I could make C64-style sounds on the picante. I've managed to make a thing! This is a software synth running on a RaspberryPi Pico attached to an Adafruit UDA1334 I2S module (recorded through the mic jack on my PC). Getting the UDA1334 working The official Adafruit guide was useful, but not perfect as it didn't cover the Pi Pico.  The micropython examples on how to play a tone and how to play a wav from an sd card were really  useful though. First, I got the play tone working, then I adapted the sd card (non-blocking) interrupt to play a continuous tone (which was just beautiful and didn't make my ears bleed at all). Starting on the Synth I then had to do a LOT of thinking about how I could make this synth fast enough and low-RAM enough for a Pi Pico.  After trying out a few combinations of parameters, I settled on a sampling rate of 16kHz and 16 bits per sample.  I wanted the synth to work on different wavef...

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...

 A good while back, I ordered an ISA network card for my socket-5 Pentium machine.  Finally today I managed to get it working with EtherDFS .  Finding the right steps involved a lot of web searching. First, I had to figure out exactly what model the card was.  Thankfully, it says it right on the chip: RTL8019AS .  I have spewed much bile about Realtek and their crappy audio drivers before now, but I was seriously impressed that they still had a page where I could download the packet driver for this ancient NIC. As far as I can tell, there are two types of NIC drivers for DOS-era machines: an NDIS type for Windows things, and a 'packet' driver with an open interface.  EtherDFS needs the packet drivers, and I don't care for Windows guff, so I'm happy with just that. I found a page at legroom.net which had the info I needed to install the packet driver.  That page has a whole wealth of stuff, but the bit I needed told me to save the packet driver (pnppd....

My C64 is still banjaxed, but now in a way that makes me feel it's closer to being fixed. I had thought it was just a dead PSU, so I ordered a new one.  When it arrived, I plugged it in and.....the same problems happened.  So that's the first potential fault ruled out. So I ordered a C64 dead test cartridge .  When this arrived, I plugged it in and powered on...and it gave me all sorts of crap on the display.  Still recognisable characters and border, but utter random garbage.  There was some screen flashing, which is the way the cart indicates dead-ram chips, but it couldn't decide which one - every time I switched the machine on it gave a different number of flashes. The internet had already suggested that garbage text meant a duff multiplexer, and with the cart encountering seemingly random errors across multiple chips, I decided to order a couple of spare multiplexers (there are two in the C64). So today I cautiously desoldered the U13 multiplexer and solde...

So moving house has been an absolute pain in the plums.  Monthly projects are on hiatus and until the start-of-term chaos has died down, I'm working on the odd piece of project here and there. The first such project is doing some C64 development, which I've wanted to do for literally years.  I bought an SD-card reader from the future was 8-bit and when it arrived, I dug out  my C64 from storage and powered it on... ...and it was dead. Not fully dead, just...weird.  Blue border and blue background are fine but the screen is filled up with garbage text. So step 1: order a new power supply.  The PSU I was using wasn't a Commodore original, but a replacement from the late 80s.  The problem could still be a b0rked or loose chip, but I got paranoid about using a vintage PSU anyways so I ordered one from Poland.  If that doesn't fix it, I plan to follow some of the procedures here . In the mean-time, I decided to search for an IDE that would run on linux and...