Posted on

Team Status Report for 05/08/2021

This is the last FP-GAme status report. We have finished our project goals and are looking forward to Thursday’s demo.

Weekly Progress Summary:

Joseph finished documenting the project and creating the public repositories.

Andrew finished his emulator port enough to show off a few games at the public demo. We are planning to livestream the gameplay over Zoom (or something with smoother video if we can find it, and then provide a link).

Remaining Tasks:

On Sunday (tomorrow):

  • Finish final video

Next week:

  • Public demo thursday
  • Finish final report (unless it is done sooner)
Posted on

Andy’s Status Report for 05/08/2021

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.

Posted on

Joseph’s Status Report for 5/8/21

I finished the user documentation I assigned myself last week. This includes the “fpgame developer’s manual” and “fpgame getting started” guides. I have included these below. They are also available on the new public repositories.
fpgame_getting_started
fpgame_developers_manual

I split our development repository into two public repositories, one containing just the files and documents the typical user will need, and the other containing source files for advanced users.
https://github.com/FP-GAme

I changed the PPU kernel module as per Andrew’s request. In particular, the CPU’s virtual VRAM now clears upon de-initialization, allowing programs that run sequentially to start up without a modified VRAM. Andrew discovered this was an issue when switching games on his NES emulator port.

Lastly, I began work on the poster, video, and final report. We finished the poster just before writing this report. The final report is almost finished. The video has an outline written for it and a few recordings taken.

I plan to get the report and video finished sooner than later. The video will be my main focus as it has to be turned in by Monday. I have other presentations to prepare for next week, so my capstone work will be limited Monday-Wednesday.

Posted on

Joseph’s Status Report for 5/1/21

This week I pretty much finalized the PPU User Library. Andrew and I worked together to debug the User Library functions related to the Sprites and the Sprite-Engine itself. Most notably on the Library’s side, the way I was writing patterns to Pattern-RAM (holding graphics data) was incompatible with the Sprite-Engine. This has been fixed. Now the library is fully tested with all parts of the PPU. Any further updates to this library will be for user experience / convenience.

I wrote an updated test tech-demo for use in the final presentation. Features “The Mall” demo again, but with updated graphics, world animation, foreground objects, and new sprites. Currently, the tech-demo is missing audio, but this will be included by the final presentation.

I finished the snes_controller_mod_instructions document. This will be included in the fpgame-usr public repository when the project is ready. Unfortunately it cannot be included here since it is larger than 8MB (it is an image-heavy step by step guide). In next week’s status report, I’ll add a link to the repository where it will be included.

I got the kernel modules to autoload. This required minor modifications to the kernel module source code. More importantly, these kernel modules are copied to the SD Card image file in a new automated build process. Steps to use this build process are included in the Work-in-progress build_from_source_guide. This document will be kept with our source files in a separate repository from the user repository called fpgame-src. This repository is for advanced users (or Andrew and I) to build the hardware and kernel modules from source. Regular users will not need to do this. The work in progress document is included below:
build_from_source_guide_WIP

Lastly, I started updating some diagrams for the final presentation slides. There were some major system interconnect changes since the design review report and presentations. These changes will be covered briefly in the final presentation.

Unfortunately I didn’t get a chance to write the “high-level guide to FP-GAme document” I was assigned in the last status report. This was dropped in favor of two new documents: Getting Started, Developer’s guide. Neither of these documents have enough information in them yet to show. They will be done by the end of next week.

Posted on

Team Status Report for 05/01/2021

Andrew finished the Sprite-Engine, the last major hardware component. Hardware is pretty much finished at this point.

Joseph finished the PPU User Library. The User Library now has all necessary components to allow the user to easily operate the hardware. A tech demo was built off of this library and will be ready to show in the final demo and/or presentation.

Andrew has also recorded a short video displaying some of our most recent progress (the working sprite engine, tile engine, pieces of the NES emulator port, etc). That is available here: https://www.youtube.com/watch?v=Susc9KNKaJI

Next week:

  • Joseph will be working on user documentation, creating the public-facing repositories, and other remaining user-focused tasks.
  • Andrew will be working on porting his NES emulator to run on FP-GAme. This will enable us to demo games (albeit with some limitations due to not being an NES).
  • Final presentation!
  • Work on the final poster and video.
Posted on

Andy’s Status Report for 05/01/2021

This week, I was able to finish the sprite engine. Then, Joseph and I worked together to debug it and the library interface that is used to communicate with it. As seems to always be the case, debugging took more time than I expected. However, the sprite engine and library are now fully operational.

After some discussion at the beginning of the week, we decided to move away from the notion of making an entire game for our system. Instead, Joseph has made a small tech demo, and I’m porting an NES emulator that I wrote a few years ago to our system (while having it use our graphics card for hardware acceleration, so that it shows off the capabilities of our console and library).

As such, after the sprite engine was finished the remainder of my time has been spent working on the port. At the moment, the emulator itself can be built for our console and against our library, and the games will load and run. The audio and controller interfaces have been successfully moved from SDL2 to the FP-GAme library. Unfortunately, I haven’t yet finished the graphics card port yet (so I can hear Mega Man 2 and navigate the menus, but not see it; that’s fine, the music was the best part of that game anyway), but I didn’t expect to, so I’m still on schedule. The port will need to include functions to translate calls to the NES graphics card into calls to our PPU, so it’ll take a bit more work than the other pieces. My current goal is to have that done before Sunday night, so that we can include it in the presentation.

As part of my work on porting the emulator, I was able to set up a more consistent build environment for user mode C/C++ applications (oh yeah, our library works with C++ now because that’s what my emulator was written in). Before, we had been building all of our user mode programs against the c standard libraries installed on the system being built on. That isn’t a great setup, and so we now build against the libraries provided by our cross compiler.

Over the course of this coming week (the last week!), I’ll be finishing the NES emulator port and whatever else needs finishing (documentation, small tests, etc).

Posted on

Joseph’s Status Report for 4/24/21

My last progress report was posted on 4/10/21. A lot has happened in the meantime.

First, I fixed and tested the PPU DMA Engine using a new tool (Quartus SignalTap), which lets me probe various signals from the hardware while it was running. Very useful in helping me debug the DMA Engine while it was actually connected to the FPGA-to-SDRAM Bus.

I added buffering of PPU Control registers so that they sync whenever VRAM syncs (after a completed DMA transfer). This prevents screen tearing because background/foreground scrolling registers cannot be modified while a frame is being drawn, only in-between frame drawing. This wasn’t very visible over the Zoom live demo from last week, but it was there and is now fixed.

Next, I implemented the PPU Kernel Module. Andrew’s prior research and development in the APU and controller kernel modules streamlined my learning process. Unfortunately, while most of the kernel module worked okay, I ran into an issue with the FPGA-SDRAM bridge blocking DMA transfers from completing. Originally, we ran into this issue with the APU. Our solution back then was to simply move the APU to the FPGA-HPS bridge. However, I really wanted to use the SDRAM bus for PPU DMA transfers (especially since I spent significant time developing the DMA-Engine for that purpose). After long hours of debugging and trying out various things, I finally found a solution. It turned out that none of the bootloaders I had used enabled the SDRAM bridge, even though they were documented to. I had to make the PPU kernel module write to a hardware register on the HPS to enable the specific ports we were using on the SDRAM interface.

In the last few days, I’ve designed and partially implemented a User Library for interacting with the PPU kernel module. I’ve attached the WIP doxygen reference below. Feel free to take a look at the “Functions” section on the 1st or 2nd page, as they are the most legible in that PDF upload. Currently, enough of the library is written to enable a software version of the Interim Demo.

fpgame_ppu_user_library_doxygen_v1

Next week, I will

    • Test/Debug the remaining User Library functions.
    • Write an instructions document for modding an SNES Controller extension cable to work with FP-GAme GPIO.
    • Finalize an SD Card image with FPGA program file and Kernel modules.
    • Write a high-level guide to FP-GAme (FP-GAme user manual).
    • Work on Final Presentation Slides.
Posted on

Team Status Report for 04/24/2021

We are entering the last few weeks of the project and we have made some significant progress so far. We only have a few tasks remaining. Instead of providing a Gantt Chart, we’ve condensed our remaining tasks into a small list.

Next week:

  • Joseph finalizes PPU User Library and gets started on the Demo Game.
  • Andrew works on Sprite Engine. We meet on the weekend to verify it works with our user library.

After this, the hardware and software components of the FP-GAme console are finished. There are only a few user-experience tasks to accomplish.

Things we want to do for the user experience:

  • Finalize an SD Card image with FPGA program file and Kernel modules.
  • Write an instructions document for modding an SNES Controller extension cable to work with FP-GAme GPIO.
  • High-level guide to FP-GAme (FP-GAme user manual).

For next week, we also have some course-related work to accomplish. In particular, we will need to work throughout the week on the final presentation.

Posted on

Andy’s Status Report for 04/24/2021

These past two weeks, aside from the ethics assignment, I focused on fixing the APU (which happened very early in the first week) and designing and implementing the sprite engine.

I’ve attached a diagram of the internal logic of the sprite engine. It’s currently roughly 80% done, and I expect to finish the remainder over this weekend. On the diagram, everything is implemented except for the OAM scanner and memory port wrappers.

The sprite engine itself works as follows. The engine will receive a signal from the tile engines that they have finished buffering their data, and that the sprite engine may now access the M10K’s which function as VRAM. The OAM scanner will then begin to scan OAM (Object Attribute Memory) for sprite data that corresponds to the current scanline being rendered. The first sixteen pieces of this data found will be sent to the sprite manager.

The sprite manager, on receiving an Object Attribute, will ask the scanner to halt while it makes accesses to pattern memory for the sprites visual data. It will then send its data to the sprite file, which is drawn in the diagram as 16 sprite units and a sprite tournament mux.

The sprite units are linked in a chain, where the last unit in the chain is connected to the sprite manager. After receiving a valid sprite, each sprite unit will send the data down the chain until this is no longer possible. Having the sprite units connected in the chain means we don’t need a large number of muxes to allow the sprite manager to write to each unit individually, and the cycle delay of things moving down chain is invisible to the rest of the board, as the sprite tournament logic will hide it. The sprite tournament logic is simply a special mux that chooses a sprite based on its visual attributes.

The sprite engine is the last piece of hardware we need to implement. After it’s done, we’ll just need to do some more tests and finalize our documentation before working on the game. I expect work on the game to begin around the middle of this coming week.

Sprite Engine Diagram: Sprite Engine V2

Posted on

Joseph’s Status Report for 4/10/21

My initial task for this week (finished on Sunday/Monday) was to fix the Tile-Engine scrolling and Y-Mirror issue. Last Saturday, Andrew helped me find the bug in the Y-Mirror feature of the Tile-Engine. Every tile entry in Tile-RAM has a Y-Mirror bit, which reverses the order in which rows of a tile are fetched from Tile-RAM when it is time to display that tile in the video output. This causes the final rendered tile to be vertically flipped. The bug was that the tiles were being reversed in chunks of 2 tile rows (instead of every tile row being reversed). As for the scrolling bug, I saw artifacts when scrolling in the horizontal direction, but the vertical scroll was working just fine. I found, after much simulation and debugging, that the way I had been applying the horizontal scroll needed to be rethought. The correct behaviour was to use the most-significant-bits of horizontal scroll to determine which tiles were fetched for a given row, and then use the least-significant-bits of that horizontal scroll to determine which pixels were fetched when it came time to render.

This week, I finished the video demo used for the interim demo. It features a scrollable pixelated world modeled after “The Mall” (at CMU), with the scroll inputs controlled by the SNES controller.

I also began the rework of the PPU-CPU communication, this time using DMA over SDRAM. So far, I’ve split the VRAM into a PPU-Facing VRAM (which is accessible only by the PPU) and CPU-Facing VRAM (accessible only to the DMA Engine). Note that there were always 2 VRAMs in our implementation, but their connections were not fixed as they are now. Most notably, the CPU-Facing VRAM has had its data-width extended to 128-bits to be more compatible with the SDRAM bus and DMA Engine. Next week, I will be finishing this implementation, and (hopefully) beginning some work on the PPU driver.