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.

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.

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

Katherine’s Status Report for 2/22/25

Accomplished:

  • All memory Instructions implemented.
  • Started writing test benches for arithmetic and control flow instructions.
  • Wrote the first draft of CPU parts of the design report.
  • Looked into some other options for the NES USB controller.
  • Learned what the DAA instruction does (binary coded decimal addition)
Next Step:
  • By the end of spring break, I hope to have a fully implemented CPU that passes all hand-made tests.
Other Notes or Concerns:
  • Progress is ahead of schedule.
  • The Altari controller can be connected directly to GPIO pins. With some modifications it might be a possible substitute for the USB NES controller.

Katherine’s Status Report for 2/15/25

Accomplished:

  • New CPU multicycle framework completed.
  • Half of the memory instructions pass tests
  • All memory instruction tests were created.
  • Adjusted schedule to account for CPU reworking.
Next Step:
  • Continue implementing memory instructions
  • Start creating control flow instruction tests
Other Notes or Concerns:
  • Progress is well ahead of schedule according to the new schedule.
    • More work has been allocated to spring break to account for CPU reworking.
  • The CPU had to be reworked to be cycle-accurate.
    • Gameboy programmers use the cycles/instruction to create wait loops.
  • The original Gameboy seems to have assumed combinational memory, but our memory is synchronous.
    • Modifications must be done to many of the multicycle instructions that involve memory.
  • Many instructions (20+) are listed as TODO in “Gameboy: Complete Technical Reference”
    • Software emulators and Intel 8080 instructions will be used to figure out what these instructions do.

Team Status Report 2/8/25

Progress:

  • CPU:
    • All frameworks completed.
    • Instruction buffer added.
    • Instructions implemented: 2
  • PPU
    • RTL completed based on datapath.
    • Testbench development in progress.
  • MMU
    • Re-designed memory controller to utilize FPGA Block RAMs instead of DE II SRAM/SDRAMs for simplicity of integration
    • Synthesized and tested Block Rams of different sizes (in ROM and RAM variant) and confirmed that they work
  • Other I/O
    • Did research into USB/Audio integration. Discovered that NIOS II cannot be used,  but there are IPs provided by Altera that use an Avalon master/slave interface.
Design Changes:
  • Swap to 32-bit word memory is under consideration.
  • Swapped memory units for BRAM

Risks and Risk Management:

  • If a swap to 32-bit words is confirmed, a full reworking of the instruction buffer will be required.
    • CPU will be developed with the assumption of 16-bit words until told otherwise since the 16-bit word architecture is harder to implement.
    • To make the possible transition easier, we will mark all code that must be removed or replaced if this change occurs.
  • Memory has been tested but I/O parts still need to be confirmed ASAP.

Katherine’s Status Report for 2/8/25

Accomplished:

  • Proposal presentation thouroghly practiced and given.
  • CPU testbench framework made for ModelSim.
    • Tests can be easily added to the testbench.
    • Can pick which test to run from the terminal.
  • CPU basic framework completed.
    • ld r,n (load immediate) passes handmade tests.
    • ld r,r’ (move) passes handmade tests.
  • Instruction buffer implemented and passes handmade tests.
Next Step:
  • Implement all memory instructions.
  • Make handmade tests for all memory instructions.
Other Notes or Concerns:
  • Progress is slightly ahead of schedule.
  • Memory and control flow operations are being prioritized so the other units can be tested using ROMs