Over this past week (the last week of classes!) I finished the NES emulator port and made some bug fixes to the sprite engine. I also worked with Joseph to create the poster for our project.
The portion of the emulation this week focuses on translating calls to the NES PPU made by the game being run into calls to our PPU. This is done by translating the corresponding calls for each subsection of the PPU. When the emulation signals to the application that the emulated graphics card has finished drawing the frame, the emulator inspects VRAM and recompiles the name tables of the NES into a partial name table for our PPU. It also updates the palette and OAM settings. These updates are sent to our PPU for rendering. Pattern RAM may be updated too, but that is not recompiled on the fly and is only sent when the application actually makes a change (since pattern ram is by far the largest and most expensive to transfer). Other changes were also made to the emulation for compatibility, but the details of that are far less interesting and relevant.
After bringing up the video output for the emulator, some bugs were noticed in the sprite engine hardware and had to be addressed. Notably, the sprite engine embarrassingly refused to draw more than one sprite per scanline due to a misunderstanding of what the $right() function in system verilog does (expected it to grab the least significant set bit, actually just gets bit 0). Additionally, a more obscure bug caused the sprite engine to ignore the last sprite defined in OAM at all times, which caused some flickering issues in NES games (the reasons make perfect sense but require understanding how NES games and hardware interact).
With all these issues fixed, a number of games work well enough on the FP-GAme port of my NES emulator to make for a fun and exciting demo. Notably, Mega Man 1/2, Metroid, and The Legend of Zelda work very well. Games like Super Mario Bros and Castlevania rely on a hardware feature of the NES’s PPU that ours does not support, namely the changing of the horizontal scroll value of the background layer in the middle of the frame. This means those games function, but have a graphical glitch that causes their menu items to “shake” as the game scrolls (the actual problem is that the menu graphics can only move in 8-pixel increments and the rest of the screen can move 1 pixel at a time). We plan to demo the games that work well so as to not confuse our audience with problems caused by emulation issues.
Over the course of this last week, we will create the final video and put the finishing touches on the final report.