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).