Posted on

Bharathi’s Status Report for 4/26/25

Accomplished

  • Debugged Tetris and Dr.Mario on VGA with team. Tetris looks mostly functional but the game appears to run 2x faster. Dr.Mario is stuck after the pill is spawned & before it is thrown.
  • I spend some time debugging the issue on simulation. Sadly, this was a fairly slow process as many of the bugs in the games we want to play show up somewhat later so I need to run the simulation for a while to get more information but this still offers a lot more visibility so I am optimistic that I will be able to debug the issue with Dr Mario and Tetris.
  • Katherine and I also plan to test a few other games on synthesis.

Next Step(s)

  • Finish debugging Dr.Mario and Tetris.
  • Prep for demo.
  • Work on poster, final report.
Posted on

Team Status Report for 4/26/25

Progress:

  • Tetris is playable, with fully working controller inputs, but runs at ~4* speed
  • Found a timer initialization and incrementation bug.

Risks and Risk Management:

  • FPGA debugging is a very “guess and hope for the best” process, even with signal-tap.

Tests:

  • CPU
    • Handmade test for every Gameboy instruction
    • Blarrg cpu-instrs tests run on CPU.
      • Fixed some misunderstandings of Gameboy specification details.
  • PPU
    • Basic static frames from Tetris/Dr. Mario with fixed tile/sprite preloaded memory
    • Dmg-Acid tests on Simulation
    • Basic static frames from MMU/CPU/PPU integration
  • MMU
    • Basic testbench checks on synchronous cycle BRAM accesses (R/W)
    • Synchronous cycle I/O registers (PPU/APU/Interrupt) (R/W)
    • Basic timer register checks
  • Simulation
    • Blarg cpu-instrs tests.
      • Many MMU bugs fixed
    • 1st pre-loaded frame of Tetris test.
    • 1st Tetris frame generation test.
      • 3 clocks were added to the design
      • CPU IME (interrupt enable) register misunderstanding fixed.
      • Many MMU bugs fixed
    • 1st, 2nd, 3rd frame + controller input test on Dr. Mario.
      • Fixed PPU palette issue
      • Joycon register spec misunderstanding fixed.
      • Many MMU bugs fixed
  • Physical
    • Basic controller button to LED test
    • DMG-Acid test rendering
      • Fixed jagged clock issues (ensured that clocks were derived off of others for adequate timing)
    • “Play” Dr. Mario.
      • Synthesis results in non-deterministic behavior.
    • Play Tetris
      • Joycon issue determined via patterns and fixed.
Posted on

Katherine’s Status Report for 4/26/25

Accomplished:

  • Found and fixed the bad controller input issue.
  • Verified lines will disappear in Tetris.
  • Found timer initialization and incrementation issues in the simulation.
  • Determined bank switching is required to play any part of Link’s Awakening/Pokémon
Next Step:
  • Continue debugging Tetris and Dr. Mario on hardware
  • Attempt other games to see if we can find more working games for the demo
  • Make aesthetic updates for the demo
Other Notes or Concerns:
  • All games are stuck in hard mode (runs at about 4* speed)
Posted on

Bharathi’s Status Report for 4/19/25

Accomplished

  • Debugged DMG Acid Test — frame rendered appears to be fully correct. Also fixed the missing hand issue on Dr.Mario in simulation.
  • Debugged Tetris and Dr.Mario on VGA with team. Tetris looks mostly functional but the game appears to run 2x faster. Dr.Mario is stuck after the pill is spawned & before it is thrown.
  • Fixed synthesis issues related to the Audio Test. Technically we have all the pieces for the APU but integrating it is likely to introduce a number of other issues so I have postponed it until we get Dr.Mario and Tetris working perfectly.
  • Ruslana and I spent a lot of time investigating the Dr Mario pill issue on simulation. Unfortunately, the bug happens after such a long time that looking at in simulation is not the most productive way to attacking the problem. However, simulation allowed us to get more specific areas / registers / addresses to look at.

Schedule / Progress

We are somewhat behind schedule given the APU status but otherwise integration is going pretty well.

Next Step(s)

  • Finish debugging Dr.Mario and Tetris.
  • Potentially integrate APU.

Tools/knowledge:

  • We need to learn the GameBoy spec thoroughly to implement it correctly. The largest challenge with this was trying to parse the many informal / unofficial documentation (that was usually contradictory).
  • I also learnt a lot related to Intel / Altera tooling and designing specifically for FPGAs. Prior to this, most of my hardware experience had been on simulation.
  • Implementing the PPU from scratch also forced me to explore more new and complex strategies to testbench my code (both separately and after integration).
  • I also got plenty of practice using wave viewers and software debuggers during debugging.
Posted on

Ruslana’s Status Report for 4/19/25

Mostly all included in team update list.

  • Debugging FPGA with the rest of team
  • Learned how to use SignalTap to focus on probing CPU register values/Interrupt register values, but it’s been slow
  • Resynthesizing design gives different behavior, which is worrying, but our design is also quite sensitive to change right now (we attempted to refactor to eliminate X’s and this caused some new frame artifacts to show up)
  • Hoping to fix immediate issue with double speed and pill

Learned things:

  • Learned about NIOS II processor and how complicated altera toolchain is
  • Learned about signal tapping to debug on FPGA
  • Learned about dealing with multiple clocks on design
  • Learned from my partners about how to tackle large scale combinational loops in a pragmatic manner
  • Learned about modelsim
  • Learned about memory interfaces and communication protocols (to SDRAM, SRAM, Audio CODEC), though we haven’t been able to utilize it so much for our project

Most of this came from trial and error + scouring the internet.

Posted on

Team Status Report for 4/19/25

Progress:

  • Tetris is playable, with bugs
    • Games run at double speed (but seemingly, this unfortunately is not tied to clock frequency or timer registers)
    • Joypad inputs don’t always get processed
  • Dr. Mario
    • Mario won’t toss his pill. We are suspicious of an HRAM or vblank handler interrupt routine error.
Design Changes:
  • Implemented Serial Transfer Control/Data Registers because Dr. Mario ROM polls from them

Risks and Risk Management:

  • FPGA debugging is a very “guess and hope for the best” process, even with signal-tap.
Posted on

Katherine’s Status Report for 4/19/25

Accomplished:

  • Debugged FPGA implementation with teammates
    • Tetris is playable, but glitchy
      • Runs at double speed.
      • Sometimes joypad inputs aren’t processed.
    • Dr. Mario doesn’t toss the pill.
Next Step:
  • Continue debugging Tetris and Dr. Mario on hardware
Other Notes or Concerns:
  • We found that recompiling will sometimes give us different results.
  • Debugging is really difficult, even with signal tap, often coming down to guessing and seeing if it works.

Tools/knowledge:

The major thing I had to learn was the Gameboy specification. Although there are some online resources, such as YouTube videos, fan-made documentation, Discord chats, Reddit posts, and software emulators, they are often incomplete or give false information. I had to cross-reference many of these sources to get the full picture. Discord was particularly helpful when learning how to get Verilog to read a .gb file.

Tool-wise, I had to learned how to set up very user-friendly scripts to simulate using free software called Modelsim, which is much more convenient and has more debugging tools than VCS.

Posted on

Team Status Report for 4/12/25

Progress:

  • Integration
    • Full integration in progress
      • We are able to render specific frames statically with Tetris/Dr.Mario/other rom tests in simulation now, but rendering the full game code in synthesis is still being debugged.
        • Successfully generated first frame for Tetris in simulation.
        • Successfully generated 3 frames for Dr Mario using actual Joypad interrupts in simulation.
        • VGA Support added in synthesis.
        • Full design (including controller) integrated and synthesized on FPGA  — debugging (using SignalTap 🙁 ) in progress.
        • DMG Acid Test face runs and shows up as a mostly intact fact on synthesized design
        • Dr. Mario ROM in synthesis has yet to work–after starting it up on an FPGA, the first frame shows up as a flicker and then it’s a white screen. We are fixing this currently. 
  • PPU: DMG Acid Test in simulation almost fully debugged. PPU integrated with design fully. VGA + BRAM based Frame Buffer support added.
  • APU:
    • Wrote/compiled APU (4 channels, 2 PWM, 1 wave ram, 1 pseudorandom with envelope/sweep/frequency change support)
  •  I/O
    • New controllers have been assembled

Design Changes:

  • There are now 4 clocks in the design. 
    • MMU clock that runs at 8MHz
    • PPU clock that runs at 4MHz (1 cycle is called a dot) 
    • CPU clock that runs at 1MHz (1 M-cycle = 4 dots)
    • VGA clock that runs at 50MHz 
  • The reason for these clocks is due to the spec. 
    • The MMU must run twice the CPU frequency, because our FPGA BRAMS (gameboy memory) have a 2 cycle read latency. 
      • The PPU is clocked at 4 MHz according to Gameboy spec
      • The CPU executes an instruction across 4 cycles of the 4 MHz clock–hence, we made the CPU clocked according to 1 MHz. This is a subtle distinction that took us a while to dig out during integration and clarify. The discrepancy between the CPU and PPU clocks are documented poorly online and likely isn’t as big of a concern for software emulators.
      • The VGA must communicate at 50 MHz. 
  • In our FPGA, we have two clock generators – a 50 MHz one and an 8 MHz one. The other 4 MHz and 1 MHz signals are derived from the 8 MHz to ensure that the clock edges are properly aligned. This was another bug we fixed this week. 

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
  • Potentially cutting APU from final, because of time considerations (even though the pieces to put it together exist)

Verification & Validation Progress:

  • CPU:
      • passes Blargg Test ROM cpu-tests (minus interrupt tests due to optimizations in PPU)
      • passes hand-made tests
      • Is able to generate multiple frames and process joypad input.
  • PPU: 
      • Passes mode-level, line-level, and frame level timing requirements 
      • 100% palette mapping accuracy
      • Minor Sprite bugs – but these will be debugged soon to achieve sprite accuracy requirement 
      • Frame Output latency well under requirement threshold 
  • MMU:
      • Passes in personal testbench that did:
        • Queries to memory regions (rom/wram/exram/vram/oam/hram)
        • Queries to memory IO registers
        • DMA Query
        • Basic interrupt checks
  • APU: Work in progress – no tests have been done so far 
  • I/O:
  • All key presses on the controller are very responsive – complete testing of latency will be done soon to validate if controller response time meets use case and design requirements. 

Bugs we fixed over the last two weeks:

  • VRAM/OAM cpu write propagation (simulation)
  • Reworked MMU/CPU/PPU clocks (simulation/synthesis)
  • PPU reset behavior (simulation)
  • Sprite priority bugs (simulation)
  • Sprite horizontal and vertical flipping bugs (simulation)
  • Window internal counter bug (still needs to be fully fixed) (simulation)
  • Sprite sorting edge case (when sprite is technically off screen) (simulation)
  • Horizontal and vertical background scrolling glitch (simulation)
  • Fixed clock misalignment issue between PLLs on FPGA (synthesis)
  • HRAM access issue (simulation)
  • VGA upscaling issue (synthesis)
  • VGA frequency issue, had to reparameterize to fit different resolution specs (synthesis)
  • Joypad reading bug (simulation)
  • Joypad register writing bug (simulation)
  • Color Palette map bug (simulation)
  • Lingering `DOC flag that took 4 hours to find (synthesis) 
    • I hate signaltap
  • LCDC reset condition bug (simulation)
  • Improper LY increment bug (simulation)
  • Timer bug (simulation)
  • IE IF register bug (simulation)
  • STOP instruction bug (simulation)
  • STAT interrupt and LY==LYC flag bug (simulation)
  • TMA and TIMA mapping bug (simulation)

Known bugs that need be fixed:

  • Simulation: DMG Acid Test – tile flipping bug
  • Simulation: DMG Acid Test – window internal line counter bug (off by 1 line)
  • Simulation: Dr. Mario – Frame 3 – Mario’s right hand is missing (overlapping sprite case)
  • Synthesis: Dr. Mario’s first frame from ROM has yet to show up successfully. It flickers on FPGA screen and vanishes currently. 
Misaligned Clocks
Goth Mario
Dr. Mario — Frame 2 (Buggy)
Dr. Mario — Frame 2 (Correct)
Dr. Mario — Frame 1 (Correct)
Tetris — Frame 1
Dr. Mario — Frame 1 (Buggy)
Dr. Mario — ?
Dr. Mario — ???
Posted on

Katherine’s Status Report for 4/12/25

Accomplished:

  • Debbuged Tetris and Dr. Mario in simulation with teammates
    • Tetris reaches the first frame
    • Dr. Mario reaches the third frame
Dr.Mario — Frame 1
Dr. Mario — Frame 2
Dr. Mario — Frame 3
  • Debugged controller input in simulation with teammates
    • Was able to do multiple controller presses to access new screens in Dr. Mario
  • Debugged FPGA implementation with teammates
Next Step:
  • Work on debugging Tetris and Dr. Mario on hardware
Other Notes or Concerns:
  • FPGA tests do not match the simulation.
    • Proving to be very difficult to debug.
    • Signal taps and lights on FPGA are being used for visibility.
  • Verification and Validation discussion is in the team status report