Author: jingchux

Added mapper 1, 2, 3 support. Contra is now running fine in both single-player and remote multiplayer modes. Added game state hashing to confirm the syncing status when running in remote multiplayer. Game state hash matched for an extended period of play, even during frequent game stalls, thereby proving the correctness of the lockstep protocol implementation.

I am currently on schedule. In the upcoming week, I will finalize the remote multiplayer testing and complete the video recording and editing.

Completed the remote multiplayer feature. The games running on separate boards are correctly syncing. Extra latency is negligible with the controller input wait time configured to 2 frames, and no game stall is seen with a direct Ethernet connection. I’ve also conducted additional latency testing.

I am currently on schedule. Next week, I’ll proceed with more testing on remote multiplayer’s resistance to network latency and jitter.

 

Integrated the APU with the CPU and PPU. Successfully output sound on the Arty while the game is playing. Successfully integrated the frame-gating logic for the remote multiplayer feature.

I am currently on schedule. Next week, I’ll finalize the remote multiplayer and start testing.

Demoed the current working CPU+PPU implementation on Monday and Wednesday. Finalized the UDP communication implementation. Tested the implementation with a Raspberry Pi 5 as a mock receiver+sender. Set up the Pi with netem to introduce latency and jitter for future testing. Currently working on integrating the UDP protocol with RTL changes to support control input buffering and frame gating.

I am currently on schedule. I will continue working on the remote multiplayer feature in the upcoming week.

Established a new testing/debugging workflow, standardizing the log traces of software emulation reference and hardware simulation to catch behavior divergences.

Pushed CPU and PPU correctness further. Successfully synthesized the design and programmed the board. The latest design is able to advance to the game demo after the title screen, matching the behavior of a software emulator.

I am currently on schedule. Next week, aside from the interim demo, I’ll proceed to integrate the UDP button state sending implementation with the current status, and try to integrate the APU if time allows.

Completed controller implementation. Implemented a controller demo that allows the PS to read the PL for the state of the controller and print to uart. Started on the remote syncing protocol implementation that builds upon the existing controller demo to send the controller signals to a remote board through UDP.

I am currently on schedule, and I will finalize the basic control signal syncing next week, ideally completing a demo with two uart sessions monitoring two boards, and pressing buttons on one board will show signals on both sessions.

 

Acquired and tested the newly arrived Arty Z7-20 boards. Previous issues with the Zedboard are resolved. Validated ROM loader correctness. Validated CPU official opcode correctness with both simulation and hardware. Set up PPU validation workflow with Mesen2 as the golden model. Implemented HDMI video output (not yet connected to the NES core).

I am currently on schedule. Next week, aside from continuing the validation for the PPU, I’ll start to add the controller inputs and the UDP syncing algorithm.

Finalized the design and completed the design review. Completed the code for controller input. Ready to pick up the ordered board next Monday and test the ROM loader, AXI-lite interface, and controller inputs.

Continued the investigation of the unstable JTAG debug link on the ZedBoard we’ve acquired from the parts list. I’ve tried switching to a Linux dev environment, changing the USB cable, and decreasing the JTAG frequency. But the issue remains unresolved. Given the current status, it is very likely that the issue is with the hardware rather than the setup or software. Instead of continuing to fight an unstable JTAG link on an aging ZedBoard, we’ve decided to purchase two new Arty Z7-20 with the same SoC for our project.

In the meantime, I’ve done some research on the AXI4-Lite we’ll use for interfacing the PS and the PL. I’ve also planned a minimal register map for the interface.

I also presented the design presentation on Wednesday.

Due to the persistent issue with the ZedBoard, a lot of my current work cannot be verified. I plan to use my time during Spring Break to work on the new boards, assuming they arrive on time.

Implemented bare-metal application flow for game ROM loading and another diagnostic application to test UART. Both are implemented in C and to be run by the ARM core on the ZedBoard. UART has been confirmed to work end-to-end with manual UART byte injection. However, the JTAG/AP debug link is unstable (intermittent AP transaction errors, DAP-only enumeration, e.g. 0x30000021). Because JTAG/AP is unstable, launch/debug outcomes are inconsistent. Software correctness for ROM load and uart_smoke is therefore not yet verified. 

The instability could be due to the current WSL2 dev environment. I’m planning to switch to native linux for another test run. Other potential causes could be the default JTAG frequency being too high, a bad power supply, core overheating, or simply having a defective board (unlikely but possible). Due to the issue described, I am slightly behind the new schedule we drafted. I plan to invest more time to debug the current situation. Once it gets resolved, I’ll continue to work on the rest of the development.

In addition to the above progress and obstacles seen, since I am in charge of the SoC integration, I’ve finalized the design plan using the Zedboard with its ARM core to serve our goal of recreating the NES with remote multiplayer capabilities.