VerilogBoy - GameBoy on FPGA

Original Goals for the CMPEN 275 course project

This project aims to recreate the whole Game Boy gaming system on an FPGA development board, with the ability to play commercial game like The Legend of Zelda with no major glitches.

To be specific, it should be able to run the unmodified Game Boy machine code, produce gray-scale graphics and output to an external monitor, produce the sound and output to the 3.5mm jack on the FPGA board, and accept user input to control the game. Other functionalities like serial communication and IR communication are currently not part of this project.

Current Goals

Besides getting it running on a development board, I am designing a dedicated handheld console for this. The console is simply called, the VerilogBoy Handheld. GameBoy Color support and serial communication capbility is also in the long term plan.

System Architecture

The main system architecture is designed as follows (outdated):

There are three major parts needs to be implemented: the Game Boy CPU (8-bit CISC Processor, Intel 8080 like), the PPU (or GPU), the Sound unit. Several interfacing modules are needed to support the IO capability provided by the FPGA development board. Game ROM would be stored in on-board NOR flash, and RAM would be implemented with on-chip Block RAM.

Specification of the Handheld

XC6SLX16-FTG256 FPGA
8MB ISSI IS66WVE4M16 PSRAM
Wolfson WM8960G Audio Codec
XPowers AXP209 Integrated Power Management Unit

Progress

Able to run Is That a Demo in Your Pocket with sound. See demo video! (Please turn down the volume, I found the signal from the FPGA is too hot for my recording device).

Pokemon Yellow and The Legend of Zelda: Link's Awakening DX are also tested to work with DualShock 2 support ( I should have picked a Nintendo(R) controller instead of Sony(R) one... But that's what I have. ).

After finishing the presentation, I started refactoring the code, starting from the CPU. I also started working on the handheld as described before. They are all still working in progress as of the time I am writing this. You can follow the progress on this page and on the GitHub commit history.

Project Logs

Collapse logs

Revised handheld hardware architecture
Wenting Z. • 02/02/2019 at 14:36 • 3 comments
This is a project update about the hardware side of the VerilogBoy Handheld.
After testing the previous prototype (Rev 0.1), I feel like several changes are required:
- Add a dedicated DPI-to-DSI bridge chip. My poor implementation of the D-PHY transcevier simply couldn't meet the signal integrity requirement. This is an experimental change to test how much it can improve without doing major change to the board (for example, moving to 6-layer, adding decoupling capacitors that would interfere with overall structure, etc.).
- Replace the Micro-Type-B USB socket with Type-C socket. No Alt Fn or PD support is planned, just working under USB 2.0 FS slave (sink) mode.
- Add a microcontroller to handle hardware initialization, RTC, and USB FS communication (for example, flashing new firmware to the on-board SPI flash.
- Fix various incorrect component footprint.
Here shows a revised hardware architecture. This is probably overly complicated for a hobby project.
Due to the closure of PCB manufacturers because of the Chinese New Year, we are probably not going to see the new prototype (Rev 0.2) in the Feburary. I will continue working on the HDL side of the prototype and trying to finish the CPU refactoring within the coming weeks.
For the time being, thanks for reading.
Hello from the DSI screen
Wenting Z. • 01/28/2019 at 17:41 • 0 comments

Here it is. 320x320 IPS MIPI DSI screen. DSI running at 268 MHz (256 MiHz), that's exactly 64 times the Game Boy pixel clock rate (4 MiHz). With every GameBoy pixel quadrupled, and every pixel being 16 bits (FYI, the GBC uses 15bpp), it is going to transmit the pixel output from the PPU to the screen perfectly in sync. DSI controller is implemented in FPGA. A custom boot ROM running on the GameBoy CPU takes care the DSI controller initialization as well as screen initialization. More details about DSI is coming.
The Assembled PCB.
Wenting Z. • 01/14/2019 at 02:11 • 1 comment

Unfortunately due to the system design, I have to finish refactoring the CPU first before I can do some practical tests (which all need the BootROM to run on the CPU within the FPGA). But, at least, here is a nice looking board!
On the way designing the hardware
Wenting Z. • 10/22/2018 at 23:40 • 0 comments

Finally I decided to design the hardware for it, rather than just running on the devboard. Here is the short video provides a time lapse of me designing the hardware, and a short introduction to the project.
DualShock controller working
Wenting Z. • 04/16/2018 at 03:39 • 0 comments

For the controller, I decided to use the PSX controller (DualShock 1). I know that I could use something like a NES controller, which is probably easier to interface with (?), but I just thought that it might be used in my future projects, having more buttons is probably better. So, as I result, I got a cheap DualShock 1 clone off eBay.
I spent some time writing and testing the driver for it, and now it is working (partially). I am able to read all buttons out, including two analog joystick. However, I am unable to enter the escape mode and manually set it to work under analog mode rather than digital. The controller simply refuse to ACK my 0x44 Set Major Mode command. I guess this is not a big deal, the Game Boy does not even need the analog joystick, and I can always set the mode by pressing ANALOG key.
Here is a screenshot of the oscilloscope showing it working in the analog mode:
And here is a screenshot of it refuse to ACK my 0x44 command:
For more information about the driver itself, please refer to the code.
Demo video!
Wenting Z. • 04/15/2018 at 18:16 • 0 comments

(Please turn down the volume before play)
Audio
Wenting Z. • 04/11/2018 at 19:47 • 0 comments

I am almost finishing the audio part (depend on how to define audio). Currently all 4 channels are working fine with no audible problems (I am not sure how accurate it really is, but it literally "sounds" good.) The original Game Boy sound system is kind of buggy (See "Obscure Behavior" at http://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware ), and I am not currently trying to implement these bugs. Since these bugs are inconsistent among different models of Game Boys, I guess not many games are actually making using of these quirks.

There are several things in the audio part worth noting. The first is that the duty cycle. The pandocs and the Game Boy Programming Manual are describing the duty cycle setting totally different. The pandocs is defining the duty cycle to be the percentage is LOW while the GBPM is defining it to be the percentage is HIGH. I guess I would have to do some probing to figure this out.

The next problem is mixing. I am guessing that the GameBoy are using OpAmps to mixing things together rather than using digital adder. Both documents claims that each channel have a dedicated DAC. The presence of the Vin function could also be a suggestion that they are mixing in an analog manner. Also I believe that they are using a PGA to control the volume rather than digital multiplier. (If the mixer is OpAmp, then the volume control could not be a multiplier, after all). But apparently I cannot do this with an FPGA, so I am using adder and multiplier to do the job.

Another problem is the signal sign. Audio processing nowadays usually use a signed number to represent the level. The Game Boy could possibly do the same thing (offset binary, not 2's compliment), but I think they didn't. The reason are this: The advantage of using a signed number is that it would have a constant zero level (Vmax/2), rather than a variable zero level (Vsignal/2), but the disadvantage is that it would be hard to do the volume control. For a square wave, controlling the volume would be easy when it comes to unsigned number: it simply output the volume when the waveform is high, and 0 when it is low. If it is a signed number, we can possibly do the same thing, output Vol/2 when it is high and -Vol/2 when it is low, at a cost of losing 1 bit of volume precision which is undesirable. (The reason is simple, if it is signed number, output would make sense only if Vhigh = -Vlow, this would make some combination of high and low value unusable). As a result, the Game Boy should be using unsigned number rather than signed.
Last, the current design of Sound module is using around 600 Virtex-5 LUTs, expect the number to be higher for Spartan-3E LUTs or Cyclone II LEs. This number include output adder and multipliers.
Working on the PPU...
Wenting Z. • 03/07/2018 at 04:19 • 0 comments

I am trying to implement the PPU according to the "Pixel Pipeline" model as in the Ultimate GameBoy Talk. Currently BG/Window rendering works fine.
GameBoy Boot ROM
Wenting Z. • 02/19/2018 at 00:30 • 0 comments

When a GameBoy is powered on, the very first code gets executed is the boot ROM. It will scroll down the Nintendo logo, make a chime, and jump to the cartridge.
So that would be also my start point to test the whole system. Fortunately the boot ROM binary is available only so I do not need to dump it from my GameBoy (it would be very difficult to do so). I also got a copy of disassembled source code.
Unfortunately the source code I got will not pass the assembler, but it is easy to modify to make it work. While I was reading the code, I also added some comments along the way.
In order to test my boot ROM in the emulator I also added a header and some initialization code to make it like a Game ROM which could run in the emulator. Since these things are outside of the Boot ROM area so they would not affect the final output.
Full code available on GitHub: https://github.com/zephray/GameBoy/blob/master/Tools/bootstrap/bootstrap.s