While of course I am also messing around with that Square Kernel, now trying to get a much faster sprite blitter to get that 85 RAM tiles more useful. I would really like to have it for a certain game idea...
But back to the ARM. The STM32G0 is a quite new chip, however it already has Nucleos, so maybe prototyping stuff wouldn't be too difficult. At least if I wasn't in the mess I am now, which definitely puts off any approach to hardware for much later. 128 KBytes of ROM and 36 KBytes of RAM, the odd number is because it optionally supports ECC for safety relevant stuff (when it has 32K RAM, the remaining 4K used for the ECC).
My general approach would be having the kernel in the ROM, a fixed thing, while games would only use the RAM. So something favoring small games and working around the tight space, but with more flexibility for larger games than with Uzebox as you can replace anything any time (code or data of your game) by loading parts from an SD card. The benefits are that there is no Flash wear, the hardware could work theoretically forever, and that the kernel provides the API for the hardware, actually anything capable of running ARM Thumb2 code could theoretically run the games (so you could have working implementations on bigger ARMs, potentially even producing display to HDMI with the appropriate part, or using USB game controllers or USB flash drive instead of SD card).
The STM32G0 would run at ~43MHz (12 * NTSC colorburst), with the flexibility of the PLL, any NTSC based crystal may be used including the most common 14.31818MHz ones. The video output would be 7 cycles / pixel, which is exact square, visible dimensions would be at most 288x216. The significance of square pixels is that it is possible to design a variant which drives a 320x240 LCD directly.
Palette would be RRGGBBII, I already designed the appropriate resistor network DAC for this. The 'I' bits are the least significant shared Intensity bits, so you could have 16 gray levels with this setup, and in overall, more smooth intensity ramps for any color. On the ARM it could be argued that more than 8 bits should be possible, yes, it is, but it reduces the flexibility for video modes. And I could come up with something quite wicked for this setup.
So the main video mode would look like as follows:
- Background VRAM is 16 bits / tile, 6 bits specifying palette, 10 bits the tile.
- The background tiles are 2bpp, but all the 4 colors are selectable by the 6 palette bits in the VRAM entry.
- Sprites use a blitter tile approach like Uzebox RAM tiles, using 4bpp blitter tiles. 12 sprite colors can be specified.
- Designed sprite blitter uses 2bpp sprites, the 3 sprite colors are freely selectable from the 12 available for sprites.
There are some uncertainties, but it seems like this video mode would work, and in overall it seems like just right for the RAM budget providing great flexibility. I also have an RLE mode which could be useful for vector stuff.
Otherwise the system is quite simple. SD card through SPI, no need for level shifters as the MCU is 3.3V already, stereo audio out by PWM, SNES controllers which as far as I see were reported to run just fine from 3.3V. It should have a similar overall part count to the original Uzebox (the video output using more parts due to the intensity bits, essentially needing a 4-4-4 RGB DAC, however less voltage shifting). The current design I sketched up can work with the smallest 32 pin LQFP package, such as the STM32G071K8.