gnuboy - Playing Gameboy & Gameboy Color on an Omega2

Maximilian Gerhardt

This is the third release in a series of at least 4 projects, coming over the next week. First release was here, second here.

Today I'm presenting to you my port of the gnuboy Gameboy and Gameboy Color emulator.
Github page: https://github.com/gamer-cndg/omega2-gnuboy

It's using the previous two releases of this series for video output and joystick input. In the demonstration, I'm using a very cheap USB audio card in order to get the sound to a PAM8403 stereo amplifier and the loudspeakers. Due to my unshielded cables and the quality of my potentiomeneter and this 3€ DAC, some noise can be heard in the video. However, when you listen to the sound via headphones, it's almost crystal clear.
Video still has isses, mainly being extremely slow. If anyone has info on faster and usable hardware SPI, tell me.

Features include:

a stable Gameboy and Gameboy Color emulator, works with every commericial title I've tested
save state loading via ZR and ZL buttons on gamepad
outputs video on a ILI9225 176x220 color display over SPI
outputs audio in stereo or mono over any connected USB audio card, thanks to ALSA
uses a Nintendo Wii Classic gamepad as joystick input

Issues include:

still the same issues from the ILI9225 driver, that is: 2 FPS (at maximum) and color corruption thanks to SPI bugs. See the second project for more info.

Pictures and Youtube video:
hardware setup
games
Video (links to youtube):

Happy Hacking!

elefas GR

Great project!!! So the low fps are solely due to the ILI9225 driver or the omega is not powerful enough/ emulator needs optimizations to run a gameboy emulator?

Maximilian Gerhardt

@elefas-GR
The speed is mainly due to the Omega2's SPI driver (spi-gpio-custom) only accepting transfers of at maximum 16 bytes, which forces me to send my 220x176x2 Byte (=77440 Bytes) big framebuffer in chunks of 16 bytes, or 4840 transfers, which is extremely slow (SPI is bitbanged, lots of driver overhead for these ~5K calls). The color corruption is due to a bug in the SPI hardware corrupting the most significant bit of the first byte in a transfer (here: MSB of the red value of the pixel, R5G6B5 format). The github page links to more threads and info. If the SPI interface on the Omega2 was bug free and usable (read: transfers are DMA accellerated, 40MHz or 80MHz clock speed, no corruption, big maximum transfer size), this display would achieve 60 or 120 FPS. This is e.g. the case on an ESP32 (which runs at 240MHz CPU speed and 40MHz SPI speed). The emulator itself does not have any speed problems on the Omega2's CPU, the problem is just in the hardware/software bugs and issues of its SPI interface.

elefas GR

Thanks for the answer, just one thought, since GameBoy has screen resolution 160x144, is there any trick you can do to send just only 160x144x2 Bytes (=46080 Bytes) / 16Bytes = 2880 transfers which is almost half than you do now?

Maximilian Gerhardt

@elefas-GR That's right, but even a factor of 2 makes it still unplayable, which is why I gave up on this project altogether after completing it in the current state. I just don't see why I should invest more time in workarounds or optimizations on this broken interface. Instead I'll be switching over to the ESP32 for this project.

Maximilian Gerhardt

Performance and visuals have increased with the new Firmware b176. From ~2 FPS this is now at ~20 FPS. Also I'm no longer getting color corruptions now because the MSB SPI bug was fixed (for this display, at least).

I can get it to about 40FPS with some optimization on framebuffer sizes, I think. But all tested games are all well-playable now!

I will release an updated version of libili9225 and video soon. The gnuboy executable won't have any changes because it just links against the display driver. Now that SPI is better working I guess I'll also write a ILI9345 driver or other where I can have 2x scaling for the graphics for a bigger screen.

Maximilian Gerhardt

New demonstration video:

There are random corruptions happening on the SPI display, where some other pixels outside of the normal rectangle are overwritten. I don't know yet if that's an issue in my driver (timing violations maybe?) or with the SPI interface, but because the entire frame is overwritten each tick, the corruption is only visible for a short amount of time.