GRG's Miscellany

This is a record of my experience of setting this up.  It's meant more as a record for my future self than a tutorial, but maybe somebody will find it useful. 1 - Install DCS First step, install DCS World via the Steam client as normal.  2 - Install LinuxTrack Linuxtrack Download here: https://github.com/uglyDwarf/linuxtrack/wiki/Downloads   Instructions here: https://github.com/uglyDwarf/linuxtrack/wiki/universal-Linuxtrack-package   Using the gui (ltr_gui) requires qt4 libraries, which I could not find in my standard Ubuntu repositories, so I had to use the ppa instructions here: https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04 Run ltr_gui from linuxtrack's bin directory to check everything works so far before moving on to get it running under Proton.  3 - Install LinuxTrack into the DCS World prefix NOTE: Attempting to install for Wine games WON'T WORK e.g. here https://github-wiki-see.page/m/uglyDwarf/linuxtrack/wiki/Wine-Games   This is because Ste

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 waveforms (s

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 needs something

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 Hardware