itch.io

Thanks! It’s been a lot of fun learning the console!

Here’s a rather verbose answer. :)

The console is kind of a similar class to the Mega Drive and SNES. It has multiple background tilemap layers (and some bitmap layers), lots of colors, lots of sprites, dma for fast memory copy, a capable CPU, 16 bit bus and lots of memory. So kind of luxurious compared to the Game Boy/Color, and solid performance.

The tricky points are: Graphics memory access, Music and Emulators.

The main thing that was tricky and kind of annoying is the CPU takes priority over VDP for VRAM access. This is the opposite of the Game Boy, where the PPU (the GB’s VDP equivalent) has priority.

What this means is that if you try to write to graphics/VDP memory while the VDP is rendering, you’ll get “VRAM Snow”, speckly glitches all over the screen.

What’s worse is this seems to also apply to the VDP scanline counter that would normally be used to tell when it’s safe to write to graphics memory (without snow). So it required a workaround using a VBlank + timer based system that simulates a register indicating when it’s safe.

(Note, the above does not apply to the bitmap layers, which have dual ported VRAM, but I mostly use the tile based layers and sprites)

For sound, it’s (literally) more like a (casio) synthesizer, instead of having the usual chiptune type sound hardware. There is a built-in system for add-on sound hardware in cartridges, but the Flash Cart doesn’t support that. I haven’t done the sound yet so don’t know all the ins and outs.

And lastly, Emulation. Since it’s an obscure system the emulator support was limited and not very good when I started. Trying to use some interrupts or other features would crash or fail on some emulators, and there timing and speed problems. But I got lucky since the MiSTer core was being written about the same time and it’s been very accurate. And two software emulators improved a lot as well. There aren’t nice integrated emulator debugging tools such as in Emulicious and Mesen. I also wrote a few small test ROMs to help improve accuracy.

During the process I wrote a sparse GBDK-like compatibility layer which made porting Petris easier, though the layer took a lot of work and learning technical aspects of the system. It insulates the developer from the graphics access issues mentioned above. The code for that is open source which might make porting other GBDK based games easier (though would still require graphics changes and customization).