Posted on

Bharathi’s Status Report for 3/15/25

 

My goal(s) for this week were some subset of:

  • Get DMG PPU integrated with CPU (if CPU gets integrated with memory)
  • Fix scrolling / sprite bug in DMG PPU
  • Debug CGB PPU
  • Attempt to read from and write to WM8731 using i2c and get some confirmation that it was configured correctly.

Accomplished

DMG PPU (4-color PPU)

I fixed a few more bugs, and wrote a new testbench to do the equivalent of the dmg-acid2 test. Ruslana and I also performed a basic VGA test which was successful, and I have integrated the updated VGA logic with my PPU. 

CGB PPU (full-color PPU)

I propagated bug fixes from the DMG version to the CGB version. The CGB PPU now renders basic backgrounds with hardcoded color palettes.

APU / CODEC Research

I also implemented a basic test on the WM8731  by writing to the reset register. This test appears to be successful so I have implemented the full WM8731 configuration i2c logic to set 10+ registers and setup i2s communication.

SignalTap screenshot of reset test on FPGA using WM8731
Full Configuration works in Simulation

Summary of time spent this week

  • VGA test: 2 hrs
  • WM8731 Reset test: 5 hrs
  • WM8731 Full Configuration implementation + simulation debug: 8 hrs
  • DMG debugging + CGB updates: 3 hrs

Schedule / Progress

Overall, I’m very much on schedule.  I don’t have any concerns regarding getting the full PPU working once we get everything integrated (as the PPU is fairly well tested in my opinion). The APU still remains a bit of a risk, however, using the CODEC directly now definitely seems viable.

Next Step(s)

  • Validate full WM8731 configuration.
  • Sketch I2S implementation (+ test with basic wave on FPGA).
  • DMG PPU integration.
  • CGB PPU debugging — target: get backgrounds and windows working.
Posted on

Katherine’s Status Report for 3/15/25

Accomplished:

  • Figured out how to read ROMs in System Verilog.
  • Made a testbench to run Blargg tests on the CPU.
  • Did the ethics assignment.
  • Debugged the CPU using Gameboy Doctor.
    • Passing all CPU Blargg tests except test 2.
Next Step:
  • Update controllers to use the new, thinner wires.
  • Integration.
Other Notes or Concerns:
  • Progress is on schedule.
  • Blargg test 2 (interrupts) requires integration with MMU and PPU.
Posted on

Team Status Report for 3/15/25

Progress:

  • CPU:
    • Made testbench to test CPU using Blargg test ROMs
    •  Almost all CPU Blargg test ROMs pass. (~24M instructions)
      • Test 2 (interrupts) requires integration with MMU and PPU to pass.
  • PPU
    • DMG PPU debug + CGB PPU Updates.
    • basic VGA test on FPGA works + VGA & Frame Buffer logic integrated with PPU.
  • MMU
    • Made personal testbench for MMU
    • All basic BRAM tests are passing, currently debugging IO and DMA features. Expected to start integration next weekend.
  • APU
    • WM8731 I2C reset test works on FPGA –> learned SignalTap on Quartus to get this working.
    • Full I2C Config logic implemented + fully works in simulation.
    • I2S logic sketched out.
Design Changes:
  • Reworked a lot of interrupt routine handling after talk about CPU/MMU

Risks and Risk Management:

  • Integration must start by next weekend.
Posted on

Ruslana’s Status Report for 3/15/25

  • Went through MMU code review with Katherine/Bharathi. Reevaluated some interrupt routine code and corrected it accordingly
  • Created python script for acquiring .mif files when given a binary ROM obtained from online
  • Created basic testbench for MMU to stress memory r/w, IO r/w routines.
  • Testbenching MMU and verifying:
    • basic memory cpu/ppu read/writes to all BRAMS(ROM, VRAM, EXRAM, WRAM, OAM, HRAM)
    • basic cpu IO read/writes (timer registers, APU registers, PPU registers, interrupt registers)
    • DMA transfer during hblank/vblank works without interfering with the above
  • Currently, basic BRAM tests to each memory unit are good for all ppu modes.
  • Currently waveforming and debugging IO integration  (timer registers are working, still need to verify the rest)

Remarks:

I’m confident that integration can start by next week, because I am developing high confidence in the Memory Controller being ok-enough for talking to the CPU. The edge cases can be caught during actual execution. I caught a lot of erroneous behavior with my personal testbench, but it’s still a model of what I expect the communication to be based off on Pandocs, not the actual ROM’s behavior.

Posted on

Team Status Report for 3/08/25

Progress:

  • CPU:
    • Instructions implemented: 103 (all of them)
    • Interrupts implemented (needs thorough testing)
  • PPU
    • DMG PPU (4-color PPU) is pretty much done!
    • Integrated testing and debugging with VGA logic
    • Full-color (CGB) implementation done, debugging in progress
  • MMU
    • MMU has been written, undergoing debugging and soon-to-be integrated
  • APU
    • APU writing has started and will be completed soon. Debugging postponed until after MMU/PPU/CPU integration.
    • Research into how to use WM8731 (Audio CODEC on the DE2-115)
    • Implemented simple I2C based sound check test for the WM8731
  • Other I/O
    • Spent a lot of time researching USB integration
    • Confirmed GPIO NES controller works.
    • Resolved NIOS II blocker of lacking library support (had to source specific directory and add to LD_LIBRARY_PATH)
Design Changes:
  • Block RAMS are all 16 bit-width, 2 column format (given that the original gameboy’s data is 8 bit data words).
    • The reason for this is because we can instantiate dual port RAMS with 16 bit width that can allow OAM entries (32 bit wide) to be accessed in a single clock cycle by the PPU
    • Leaving other Block RAMS as 16 bit width as well is reasonable for the CPU and makes things consistent

Risks and Risk Management:

  • Switching to Joypad GPIO for now to reduce USB integration complexity
  • Postponing NIOS II integration for after MVP gets hit, especially because its more well understood now

Additional Information:

A was written by Bharathi, B was written by Katherine and C was written by Ruslana

Part A — Global factors:

Emulators such as our project help preserve classic video games by allowing people to play them on modern devices, even after the original hardware becomes obsolete. This has global importance, as it makes retro games accessible to people everywhere, regardless of location or resources. Additionally, studying older gaming systems through emulation helps developers understand how past technologies shaped current gaming, inspiring innovation for the future. Our project not only keeps the GameBoy experience alive but also contributes to preserving gaming history on a global scale.

Part B — Cultural factors:

The Gameboy, The console that popularized handheld gaming devices, was discontinued in 2003. It was a significant milestone in gaming history, being the start of many beloved franchises such as Pokemon. However, as time passes, these games, especially lesser-known titles such as Dr. Mario, are fading into obscurity. Our Gameboy emulator helps preserve this gaming history and provides a pathway for the gaming community to reconnect with its roots.

Part C — Environmental factors:

There are several environmental considerations on how our choice to emulate a Gameboy using an FPGA. The greatest benefit of our choice to use an FPGA is the inherent reconfigurable capabilities of an FPGA compared to an ASIC. FPGA development boards can be reprogrammed to serve completely different purposes, and do not require manufacture of new chips. In fact, we were able to avoid incurring any actual cost in our project because FPGAs already exist in the inventory. Once we complete our project, the FPGA can simply be returned and reused for a completely different purpose–therefore, we generate no E-waste with our project.

In addition, if our project succeeds and we open source our FPGA capstone project to other people, they also may be encouraged to enhance or build upon our work. This also can reduce material consumption in the greater community.

Posted on

Ruslana’s Status Report for 3/8/25

Accomplishments:

  • Finished writing first version of MMU and pushed to github.
    • Created the block rams we intend to use for ROM banks and RAM units (VRAM, WRAM, External RAM, OAM table, HRAM)
    • Wrote logic for all IO hardware registers
  • Currently debugging MMU against a simple testbench to check bram read/writes and register read/writes
  • Currently writing first version of APU to be pushed because of my current familiarity of the audio hardware registers from writing MMU

Goals for next week:

  • Top priority is to complete testbenching MMU so that it is compatible for handoff to the CPU and PPU, this will take a some days from now but it’s looking up
  • Begin testbenching APU afterwards
  • NIOS II work put on hold for now, but I resolved the blocker from last time of unable to use the terminal tools on ece machines

Remarks:

Feeling a little bit tight on schedule with MMU because I spent too much time digging at other more exploratory forms of IO integration, but if I lock in for the next week, we should still be on track to hit MVP.

 

Posted on

Katherine’s Status Report for 3/8/25

Accomplished:

  • All CPU instructions implemented and pass simple tests
  • Interrupts implemented.
  • Modified NES controller to use GPIO
  • Simple input test for NES controller

 

Next Step:
  • Setting up a testbench to run Gameboy Doctor and the Blargg test ROMs
  • Debugging any bugs in CPU.
Other Notes or Concerns:
  • Progress is on schedule.
  • The wires I had on hand were too thick and made the left and down buttons hard to press on the NES controller. Thinner wires are required.
Posted on

Bharathi’s Status Report for 3/08/25

Accomplished

My goal for this week (and break) was to mainly finish debug the PPU and get started on the full color implementation.

DMG PPU (4-color PPU)

  • I spent most of my time this week on getting the DMG PPU fully functional—and I was pretty successful! I decided to rewrite the testbench so that it would also generate the final image (in PPM format) so I wouldn’t need to use a Python script. This sped-up my debugging progress considerably. 
  • The other main breakthrough with debugging came in the form of SameBoy (GameBoy emulator), which I used to get the VRAM data and the OAM data for each frame. This method is not perfect as it doesn’t really give me information for crucial control registers that can change on a line by line basis. However, it helped me find many of the weirder bugs in my PPU a lot more quickly. 

    SameBoy Emulator
  • The DMG PPU is very close to being done. I still have minor issues with certain sprite and scrolling edge cases, however these frames (or sequence of frames) involve CPU writes to VRAM so I have no way of verifying if the issue is with my RTL or simply because I don’t have the perfect snapshot of the memory.
  • In summary, I’m pretty happy with the progress and feel confident moving onto working on the full-color PPU. Here are some frames I rendered this week:
    Tetris — Reference (from SameBoy)

    Tetris — Frame I rendered

CGB PPU (full-color PPU)

I used the information I collected during the prior week to make the necessary updates for the full-color PPU. Because of my modular design of the rendering pipeline, I am able to make changes on the DMG PPU but still treat the layers as “black boxes” in some sense and extrapolate to make the CGB PPU integrated with larger memory sizes, many more color palettes and many new edge cases.

APU / CODEC Research

Given the NIOS / Quartus based roadblock we hit last week, I spent some time researching alternative solutions with Ruslana. The most promising approach is directly using the CODEC (WM8731) without using the NIOS softcore by configuring the registers on the WM8731 using i2c and then transferring the actual data using i2s. This appeared to be quite complex at first, especially because we weren’t able to find any evidence that someone else had managed to do this. But we’ve recently found some labs (form digital design classes at other universities who also using the same FPGA) that implement different fragments of the logic on the WM8731 directly.

I plan to use very simple i2c based test with the WM8731 to see if we get an ACK after a write to the reset register on WM8731. This should help us evaluate on the feasibility of using this approach for the APU.

Design Report

I also spent a decent chunk of time working on the design report the week it was due. We ended up working almost until the deadline as we received some crucial feedback from our design presentation somewhat late, but we were able to make the necessary updates before the deadline.

Summary of time spent (Week of 2/23 to 3/1):

  • Researching how to use WM8731 (Audio CODEC on the DE2-115): 6 hrs
  • Design Review Report: 8 hrs

Summary of time spent (Week of 3/2 to 3/8):

  • Writing new testbench: 2 hrs
  • PPU debugging + VGA testing : 12 hrs
  • Full-color (CGB) implementation: 3 hrs
  • Writing I2C based sound check test for the WM8731: 2 hrs

Schedule / Progress

Overall I’m on schedule or maybe slightly ahead as I feel relatively confident about the correctness of the DMG PPU (wrt to our MVP games — Tetris and Dr Mario should both be pretty much correct  as they have no scrolling).   I will also likely be spending some sizable amount of time on the APU from this week onwards as that remains as our largest unknown at the moment.

Next Step(s)

My goal(s) for next week are some subset of:

  • Get DMG PPU integrated with CPU (if CPU gets integrated with memory)
  • Fix scrolling / sprite bug in Pokemon Red:
Correct Frame (from SameBoy)
Frame I rendered
  • Debug CGB PPU
  • Attempt to read from and write to WM8731 using i2c and get some confirmation that it was configured correctly.
Posted on

Team Status Report for 2/22/25

Progress:

  • CPU:
    • All memory instructions completed
    • Instructions implemented: 26
    • Instruction tests written: 40
  • PPU
    • Single frame test debugging mostly done (still debugging testcases with more than one sprite)
    • Debugging multi-frame rendering test
    • Scoping full-color PPU design updates
  • MMU
    • Created several Altera MM modules that were able to be placed in Qsys Platform Designer, and routed to the SRAM controller and other interfaces
  • Other I/O
    • Spent a lot of time researching USB integration
Design Changes:
  • After evaluating the Cypress USB Controller, the decision was made to pivot to the Raspberry Pi GPIO approach as a backup plan, while exploring the synthesis of the NIOS II soft core CPU for improved integration

Risks and Risk Management:

  • The main risks involve the trial-and-error nature of writing a custom RTL unit for USB communication and potential resource limitations with the NIOS II soft core CPU consuming LUTs
Posted on

Ruslana’s Status Report for 2/22/25

  • Spent a lot of time researching USB integration again
  • Tore through Altera Memory Mapped Interfaces for Master/Slave, seems feasible to integrate with SRAM Controller. Less worried about that integration.
  • Created several Altera MM modules that were able to be placed in Qsys Platform Designer, and routed to the SRAM controller and other interfaces
  • Qsys (platform designer) allows individual IPs to be layed out along with Avalon IPs, and the interconnect logic gets automatically generated
  • Looked through on chip Cypress USB Controller and realized it had to use NIOS II soft core cpu to communicate, other forms of communication would be our own version of writing a USB OTG Controller to interface with it
    • All altera examples involved declaring the NIOS II soft core cpu on the FPGA (thereby using up LUT resources)
    • And also writing USB driver code in C to support talk to the USB peripheral. This seemed tedious at first.
  • After many hours of research for documentation, results on the doc were sparse. Although writing a custom RTL unit to communicate to Cypress doesn’t seem impossible, it would involve trial & error and a lot of stabbing at a black box.

Therefore, I’m pivoting to trying the Raspberryp Pi GPIO route as a back up plan, but also trying to synthesize part of the NIOS II soft core CPU. This may also enhance integration with the audio CODEC as well, because the Wolf chip has a similar problem.