Boot ROM programmer is finished!

I finally finished the SPI programmer. I can now program the boot ROM in 5 beautiful seconds with a single command. I'm so satisfied.

SPI programmer final status

I overhauled the design I had last post, because of some issues I had. An important change is the now in firmware implemented SPI slave. Instead of re-using the EFB SPI core, I opted to just implement an additional core in firmware. Because it is dedicated to use by the programmer core, the rest of the design is much simpler. I now don't have to worry about configuring the SPI core for its different uses and can just send programming data immediately after powering up.

I also increased the scope of the programmer core (now called the debug core). It is now also able to read from or write to any arbitrary address within the cartridge's memory map. Not only does this allow for flashing the boot ROM, it also allows me for access the DRAM. This will be handy in the future when developing the game launcher, since it will run from DRAM.

Along with the new core design, I also developed scripts for file upload. One such tool is ecgc-upload which, as the name implies, uploads a file to the cartridge. It can only upload the boot ROM at the moment, but I will add the aforementioned DRAM flashing feature in the future.

Current endeavors (DRAM tests)

After having finished the programmer, I immediately continued development of the bootloader. Specifically, I wanted to finally develop DRAM tests. I have tested the DRAM by writing to and reading from it a few times, but I never actually rigorously tested it.

I currently have most of the test finished now and have found some errors. The way the test works is in 4 stages:

1. Write zero (0B)
   • DRAM is filled with 0x00
2. Read zero (RB)
   • DRAM is checked whether it is filled with 0x00
3. Write random (WB)
   • DRAM is filled with pseudo-random data.
   • This data is generated using the xorshift method.
4. Read random (RB)
   • Test sequence from random write test is checked to be correct
   • Random numbers are re-generated using the same algorithm.

Every test is divided up into the DRAM banks, where each stage loops over every bank to test it. For example, the Write random test first fills bank 0, then bank 1, then 2, 3, etc.

The test results are shown below. 0B, WB and RB are the bank counters, showing at which bank the test is currently at. This updates during the test, giving me an indication on the progress. The EC number below is the error counter. Logically, I'd want this number to be 0.

Now what I observe, is that the Read random stage finds ~80 byte errors in each bank. These errors also look like they appear in the upper addresses of the bank (i.e. close to 0x7FFF). I haven't looked much at the other banks, but I suspect this to be a trend. Additionally, the data at these addresses is always 0x00.

This could indicate that the address decoding is going awry and the cartridge thinks the address to be unallocated (which ignores writes and always reads as 0x00). I still need to investigate further, but please let it be something simple.

Open-sourced project

After having finished the programmer, I also opted to finally open-source the project. I planned to open-source it from the beginning of its conception, but didn't want to do it too early. I didn't want the scourge of an abandoned public repository on my GitHub. But the project is going nicely and I think I might actually finish someday (far in the future).

I'll eventually link the repositories on the project page, but I still need to figure out how I'll do that. For now, I'll list them here:

• ecgc-firmware
  • FPGA firmware for the ecgc Gameboy cartridge written in VHDL
• ecgc-hardware
  • Hardware documentation of the cartridge
• ecgc-spi-programmer
  • SPI programmer written for Arduino Pro Mini to program cartridge boot ROM
• ecgc-boot
  • Cartridge boot code for the ecgc project
• ecgc-util
  • Utility scripts for development with the ecgc Gameboy cartridge

Closing remarks

I am currently starting a new school semester, so I am not sure how much I'll be able to work on the project. The semester has a personal project, where I could, maybe, possibly continue working. However, I have to present something to do with signals (convolutions, Fourier, Laplace and what not). So I am unsure how I this will fit (if possible).

If I do manage to continue on this project, I'll continue investigating the DRAM issues. I'll probably start on SD card communication next. I have dabbled in the SD protocol before a year or so back, but I have to develop the necessary disk and file system routines on the Gameboy now, which ought to be very fun.