Team C0 Carnegie Mellon ECE Capstone, Spring 2020
Here is the link to the VM image that I used for SoC dev.
http://users.ece.cmu.edu/~dpratyus/VM-341_S20_GAMEBOI.tar.gz
Further instructions/information can be found at https://github.com/tchannn/Game-Boi/tree/SoC/SoC, guide is in SoC.pdf.
Have fun VM’ing!
This week I focused on getting the PPU finished and in an “excellent” state. I did this by running the dmg-acid2 test, which helped us pinpoint all the inaccuracies that the PPU had. I spent a good chunk of the week getting it running, as I was confident that with this test and our CPU verification tests we would be good to run most games that we throw at the emulator.
Furthermore, after much struggle, Tess and I managed to get the core running on the FPGA. We were able to run some tests, but there were some glaring graphical glitches. This was because we had not accounted for the memory not having combinational reads, all the memories offered by the FPGA required registered inputs. We got around this by speeding up the clock and changing some internal details to account for this change. In the end, it worked out!
Furthermore, I planned out the joypad integration into the Gameboi. I read the docs and made a module where we can just plug in the controller’s signals to make it work.
After getting the FPGA working with the whole system, we were able to run the PPU stress test on the board and all the other instruction tests we ran before, with the same results as simulation. I am excited to say that we also got Tetris and Doctor Mario running. Tetris didn’t seem to have any bugs and Doctor Mario was suffering from some timer issues, which I think we have diagnosed.
This week we’ll get memory banking working so that we can run all of our stretch goal games. Furthermore, we’ll also squash any bugs that remain. Our goal is to have the Gameboy working without game switching by the end of the week. We are also looking into an audio module that looks promising, it is built for our FPGA so it’s worth a shot!
This week I had two objectives
For 1. as per last week’s meeting, the last approach I was going to attempt before switching over to USB/ps2 keyboards was to checkout into the linux kernel version of the angstrom distribution, specifically to the unofficial commit of the drivers, compile the module with the linux source tree of that version, figure out the special flags needed for compilation, and then port over that driver to the board, load it without conflict to existing linux code and drivers, and then attempt to identify the controller through the driver.
There was an initial conflict with compiling both joypad and hid-dr modules, but after realizing that we could make do with just hid-dr, I chose to stick with that, and it ran with the existing linux source code, and I was able to retrieve bytes form the controller.
To make the NES-controller….controller, I had to understand the event structures, types and linux/input.h, details linked here. I then composed code to handle multiple presses and releases of the controller inputs, where the button packets were of different lengths, so I implemented a variable length buffer to handle this.
All in all, the end result is as shown here. Each button press and release maps to the respective led being on and off.
2. The next goal was to get qsys running on the VM, and compile a basic program. The manual also had an example of an SDRAM test, with installation setups, unique to Windows, so after finding workarounds for the linux VM, I got the SDRAM NIOS2 test to work on the FPGA board. This means we can copy over information to the SDRAM from the SoC, and read back from it and compare the bytes, to check if they are the same. Still have to implement checking the sums being equal for the bytes on FPGA and SoC.
Thus, this weeks goals were achieved. The goal for this week is to read from USB storage, and write those bytes to SDRAM, read them back and store it on the USB flash. I expect working with Qsys to be non-trivial for the same :'(. Using USB instead of micro SD card because currently the board boots from the micro SD card and I don’t want to mess with it.
