Weekly Status Reports

May 5, 2019

Team Update

This week we all spent time working on our presentation and poster. Aside from that each of us have been working in our areas to get ready for the demo. Diego and Oscar have been debugging, while Nikolai has been working on getting save states working.

Diego

This week was the final presentation and poster. I setup the slides and practiced the presentation. Moreover, I am still debugging the APU.  I have fixed some communication issues between CPU and the APU. The DMC channel still remains unusable. But as for things noticeably wrong for next our final demo only Bomberman and Super Mario Bros sound peculiar. My priority is to get Super Mario Bros working correctly since that is famous title. Also, it does not use the DMC channel so in fixing it, it may fix other problems that were not noticed in other games.

Oscar

This week was spent mostly debugging the last issues with the PPU thankfully I fixed most issues and we currently run 24/25 games. Here is an updated list:

YES:
Balloon Fight
Bomberman
Donkey Kong
Donkey Kong 3
Donkey Kong Jr
Donkey Kong Jr Math
Ice Hockey
Mario Bros
Pac-Land
Pac-Man
Space Invaders
Super Mario Bros
Soccer
Spelunker
Tennis
Xevious
Tag Team Wrestling
Ice Climbers
1942
Baseball
B-Wings
Excitebike
Kung Fu
F-1 Race

KINDA:
Ms Pac Man

Ms Pac Man runs however some of the background is not right. For demo we will just be working with the games that do work. I’ve also spent some time this week writing the SRAM loader which will load a game from SRAM. We will initialize the SRAM with 16 or so games and then the loader will read the game and write it to the CPU and PPU’s local BRAMS. Apart from that I also worked on the poster.

Nikolai

This week I spent a fair amount of time working on our final presentation and on our poster. As far as technical work goes, I’ve been working on the save states. Save states are proving to be more difficult than anticipated, though it seems like they should be up and running tomorrow. Tomorrow I will also spend some time working on upgrading the wiring for the controllers to be a little more reliable for our live demo.

April 27, 2019

Team:

Overall I think we are in good shape, we got Super Mario Bros working (for the most part) which is one of the harder games in mapper 0. There are still some issues with some scrolling games but I hope on fixing those in the upcoming week. APU works very well there are just some sounds it doesn’t yet produce but fixing that should not be too bad. We are currently looking into how to add save state support. At a high level it doesn’t seem like it should be a problem to add that feature, there is just a lot of signal book keeping that is needed to get it working. For our class presentation, I think we will have good results to share with the class.

Oscar

This week was mostly spent debugging some issues with the PPUADDR register. I reimplemented the way the register performed scrolling so it was similar to the original implementation. This had big results as we are now able to play Super Mario Bros (one of the most challenging mapper 0 games). There are still some issues with the title screen but I plan on debugging those issues next week.  The following is a list of games we have been testing on. YES means the games works well enough so you can play (there might be very small bugs such as title screen issues but nothing major). KINDA means the game is not yet playable but the game loads and things happen on screen. NO means the game either doesn’t load or it loads but you can’t do anything screen is unresponsive. My objective for the upcoming week is to get all the games in the KINDA category to work as well as identify the issues causing the NO games to not load. Once I finish fixing all these bugs I plan on looking into an aditional mapper that would require minimal work to get working (such as mapper 1 or mapper 3). I will also add the save state support for the PPU.

YES:
Balloon Fight
Bomberman
Donkey Kong
Donkey Kong 3
Donkey Kong Jr
Donkey Kong Jr Math
Ice-Hockey
Galaga
Mario Bros
Pac-Land
Pac-Man (vertical scrolling bit iffy)
Space Invaders
Super Mario Bros

KINDA:
Excitebike (Horizontal Scrolling? not quite)
Ice Climbers (Vertical scrolling still not OK)

NO:
B-Wings
Galaxian
Tag Team Wrestling

Diego

This week had the biggest results. After careful debugging the APU was able to pass many of the tests that NESDEV offers. More notably, this translated to a demo where the game audio could be heard. From the various mapper0 games the sound matched very well and the IRQ’s sent to the CPU did not seem to cause any problems. The only channel left to implement is the DMC. So far, the part that is missing is the memory reader which will require changing the memory controller and that could have a major impact on the PPU and CPU that also use it to interface with memory. Also, other tests that focus on the cycle accuracy of the APU seem to be failing; however, it may not be worth replicating it exactly especially since it appears to be working very well with mapper 0 games. Also, today will be dedicated to preparing the final presentation.

Nikolai

Towards the beginning of the week I focused my efforts on helping Diego debug the APU. Specifically I helped him with the sweep feature of the pulse channels. With the help of the waveform viewer we were able to track down and resolve our major bugs. Sound is now working for the most part, though at least one game has sound that is noticeably incorrect.
This week I also found a bug in our memory flashing script that has been causing some games to fail upon resting. The issue is that the game cartridges are budgeted 32KB of space, but some use only 16KB of that space. It turns out some games expect us to double the 16KB ROM to fill up that 32KB range.
Over the past few days I have been working on our save states. I have written a module that should manage most of the saving and loading protocol, but now we need to add some control signals throughout the NES so that each register can see when it should be loaded with a value. We will also need to add an interface with the board SRAM so we can store saved data there and also have many games flashed into memory at once.

April 20, 2019

Team

Overall our project is going well. The PPU, CPU and APU have been integrated and we are debugging them. For demo day we should have several games fully playable for 1 and 2 players using the original NES controllers, such as Balloon Fight, Donkey Kong, Donkey Kong 3, Ice Hockey, and Pac Land. After demo day we will be finishing debugging our system and add the SD card rom loader if time permits. The biggest challenge of the SD card rom loader will be getting the NIOS softcore to read roms from sd card and put the data in SRAM. If it comes down to it this feature could be dropped and I don’t think our project would suffer to much from it given that its a non-critical feature. Right now we are focusing on getting the actual console to work as well as possible before we add more smaller features like rom loading and save states.

Diego

Most of the APU has been implemented and it seems to be working with the CPU. It is still missing the IRQ and DMC channel. Moreover, only the noise channel seems fully functional. The others still fail some tests. I have spent quite a while debugging the pulse wave and triangle and it is probably best to start working on the DMC since that one interfaces with memory. Considering how simple it was to interface with the CPU using the memory controller I expect that it will just be a matter of adding a couple more signals from the APU to the memory controller. Furthermore, it might just be matter of dual porting the shared memory to avoid conflicts between the CPU and APU using memory. For this week, it will be mostly debugging the channels and working with Nikolai to get IRQs fully working. The other channels sound very close but some small error is messing up the output audio.  The things that need to be fixed are the triangle’s linear counter, the pulse wave envelope, and the sweep unit.

Oscar

This week I have been working on fixing bugs with the scrolling of the PPU. I was able to fix one major bug that was resetting the scrollX and scrollY registers incorrectly. This fixed some games such as Ice Hockey and improvevd other games like excitebike and super mario  bros however there are still some issues with the scrollnig logic which I will be debugging in the upcoming week. In addition to fixing a couple major scrolling bugs, I’ve identified other issues with how we are rendering backgrounds specifically the PPUADDR is not shared between amongst the PPU and the register interface when it should be. This is causing some issues with ppu vram changes midframe. I will continue to fix these issues throughout the week. After fixing these bugs I will move on to the SD card rom loader, which will be a hassle due to the lack of documentation for the NIOS SD card interface. I will have to look at some demos for the DE2-115 and base it off of that.

Nikolai

This week I didn’t do a ton, but I did a few small and important things.
I found a bug in the CPU which was causing several games to fail. The issue was that the interrupt handler was writing the wrong return address onto the stack, so we would execute illegal instructions after servicing the interrupt. This only happens after specific control flow instructions, so some games, such as balloon fight, were able to work despite this bug.
This week I added support for a second player controller. This involved crimping new wire connectors to one of the controllers that I found in the Capstone lab. In additional to adding support for the second controller, I rewrote large portions of the controller interface, to be more general and to more closely match the original implementation.
The rest of my effort was focused on helping Diego implement the APU. My first step in this was implementing the non-linear mixer, which combines the outputs of the 5 channels in the APU and turns them into a single output. Besides this I also started studying how the DMC channel works. At this point I have a good understanding of how it works, but I haven’t implemented anything for it yet.
My focus for the next week will be to help Diego finish the APU. After this I’ll probably switch gears and work on save states. We haven’t worked much on this, but it doesn’t seem like it will be too tricky.

April 13, 2019

Team

This week we got the controller to work, so we were actually able to play through Balloon Fight and other games. Getting the second controller to work from this point should be pretty straightforward.
Diego and Nikolai also spent some time talking about the interface between the CPU and the APU, and specifically how the CPU’s memory interface works.
At this points the controllers are mostly working, so our next goal is to get the APU up and running and integrated with the other components. Aside from that we need to continue debugging the PPU, CPU, and their interface, and we need to implement save states and SD card saving and loading.

Nikolai:

This week I added the IRQ interrupt to the CPU. In doing this I also refactored portions of the CPU design, and created a much cleaner implementation of the NMI and Reset vector, which mimics the original 6502’s implementation: it causes the CPU to go into a break instruction when it detects an interrupt, and the break instructions has specific ucode flags that tell it to behave differently when different interrupts are active.
I also worked with Oscar to get the controller interface up and running. After implementing an initial FSM, we got this to work, and were able to play balloon fight with a real controller!
The next step is to get a second controller working, which shouldn’t be too hard. This week I will also need to help Oscar debug some parts of our system, as we still have some unexplained bugs that break a few games.
Another issue is figuring out the interface between the CPU and the APU. For the most part this seems fairly straightforward, but there may be some gotchas.

Diego:

This week was dedicated to cleaning up the audio interface to drive the sound via the line out. The original IP’s specifically for the DAC was for a demo so it would use FLASH,  SDRAM, and a hard coded sampled sine wave. So I have been removing the unnecessary elements and adding inputs for the DAC IP. Furthermore, I have added the signals to the memory controller so that the CPU can communicate with the APU. I have also found tests on NESDEV for the APU. The main problem is that they require the CPU and APU interface to be set up to actually test it. Which is concerning since the problem might be with the APU or with the communication between these components. Luckily, some of these tests only require driving single channels so I can disconnect the other unused one to focus on the sound be ing produced by the design under test. The APU continues to be behind. Setting up the interface between the CPU and APU was not as complex as I expected so that gives me more time to continue implementing and debugging the APU. The next step is to synthesize it ASAP.

Oscar:

This week I worked with Nikolai to get controller support working. I specifically helped him synthesize the FSM needed to interact with the controller. We are now able to play games using original NES controllers. I also refactored some of our python scripts that flash the FPGA board so that they generate 32 Kb programs instead of 16 Kb, so we can now load larger games like Super Mario Bros and Excitebike. This week I’ve also been investigating some bugs with the PPU that are displaying sprites incorrectly. Additionally I implemented the horizontal and vertical mirroring modes that most games on the NES use.  I’ve also started implementing the scrolling feature and should have it working soon. Moreover, I’ve started thinking about how to load games from SD card so that when all bugs and features are done for the PPU I can move on to that last part of the project. I think by demo day I should have completely working PPU and the ability to load games from SD card. This upcoming week I will finish debugging the PPU and start implementing the SD card loading if I can. This week was less productive than ussual because of carnival, but next week should be back to normal.

April 6,  2019

Team

At the demo the CPU was unable to communicate with the PPU and the APU could not  drive any audio. The PPU was able to display complete frames. After the demo,  each of us have dedicated our time to getting something more demoable.. Some bugs were fixed in both the CPU and PPU so now the waiting screens of games animate and move the sprites around. Still, there are moments when these animations do some undefined behavior and clearly need to be fixed. Still, it is a massive victory in comparison to the black screen we used to see when the CPU and PPU interfaced.  As  for teh APU, parts of it have been rewritten to make it simpler and change the protocol it uses to read it’s registers. Very recently, a proof of concept managed to transmit a steady frequency modifications to this will be used to have the APU transmit its many signals.

The APU is the furthest behind but with the milestone of getting audio out, it should be easier to see if it is actually functioning properly. The next priority is add controller inputs. This is essential for our final demo but also serve as a major tool for debugging the CPU interrupts. This week Oscar will focus on adding scrolling to the PPU. Furthermore, Oscar will investigate what is causing the some dark lines in the frames.  Nikolai will focus on fixing some issues with the CPU and adding the controllers. Diego will continue to implement the APU.

Oscar

This week I worked with Nikolai to integrate the CPU and PPU for demo day. We unfortunately didn’t get full integration by then however we have them mostly integrate by now. Since we don’t have controller support yet, we tested the integration with the title screen animation of several games. So far Balloon Fight, Donkey Kong 3, and Bomberman all successfully load and run their animations. Games such as Pac-Man load the animation however certain collisions are not detected correctly. Other game such as the original Donkey Kong load but never play their animation. I think the DK code is crashing, which in our case means its jumping to an illegal instruction. We still have a bit of debugging to do but it is nice to see the systems working together nicely.

Overall I am on schedule, so I plan on finishing the PPU by implementing scrolling and debugging some of the issues we currently have. Then I will transition over to loading the ROM from an SD card.

Diego

This week was focused on completing the APU but the main problem that was discovered before the demo is that Altera’s Qsys tool is not as plug and play as advertised. From their guides and tutorials, the audio CODEC could easily be configured and driven with the inclusion of three IP’s. Furthermore, the IP’s simply needed to be instantiated with some settings predetermined via GUI. But after searching everywhere, there is little helpful documentation and forums are often left unanswered. Getting the IP’s to work together is essential for driving the audio jack and allow for the APU to output to a speaker. I will most likely be using parts of the IP and manually configuring them rather than depending on the Qsys tool. If that does notwork, then this could mean investing much more time in implementing an I2C controller and configuring the CODEC manually. This is tedious and error prone so hopefully this won’t happen but it is a back up plan.

This obstacle puts me further behind on schedule since the APU does not mean anything if it does not actually output audio. As of right now, Oscar is helping me figure out how to drive the line out. My goal is to have some method of outputting audio by this coming Wednesday and then testing and fixing the APU by the following status report.. According to the schedule, the APU should be completed and tested by now but that is not the case. So that means Oscar will most likely take over the controller interface since the PPU is essentially done.

Nikolai

This week I was primarily focused on developing the CPU, though I put some time into figuring out how to interface with the controller.
I wrote the bulk of the CPU on Sunday, and finished writing the rest of it on Monday, such that it would have the same functionality as the simulator. On Monday and Tuesday I worked on debugging the CPU, and got it to pass the same tests that the simulator had passed. I then added support for the non-maskable interrupt, and then Oscar and I tried to get the CPU and PPU to work together. While I was able to find some bugs during this process, we weren’t able to get the system to work in time for our Wednesday demo.
Throughout the rest of the week I helped Oscar in debugging our system. Most of the bugs that we have found since the demo were related with the memory mapping system, and memory sharing between the CPU and PPU.
For the controller, I was able to desolder the NES adapter from the NES-to-nunchuck adapter. I then used an arduino to try and see how to interface with the controller. The behavior I saw from our (3rd party) controllers was not what I expected based on the sources I’ve read online, but I found a genuine NES controller in a bin in the capstone lab, and that seemed to work perfectly with the interface I made. Hopefully I can get the third party controller to work, but if not, hopefully we can use the controllers from the bin.

March 30, 2019

Team

This week we have been working to make something to show for our demonstration this coming week. The PPU is in a modestly demo able at this point in time, since it can produce accurate frames from recognizable games, including sprites and background tiles.  Neither the CPU nor the APU have much to demo at this time.

Our goal to have done by the demo is to have the CPU implemented and synthesized and working to some degree with the PPU. Our expectation is that this won’t be perfect, but we do expect to have some communication between the two devices such that we would be able to show a small part of a game working.  We also expect to have our APU playing some sound by the time of our demo, even if it is not complete.

Nikolai

This week I continued to work on my CPU simulator, and have started work on the RTL design.
For the simulator I have been using tests from the nes dev website , which has been very helpful. I have found many bugs in my micro-code, most of which have been fixed now. Running these tests has also been helpful in clarifying some misconceptions that I had, especially regarding status bits. Several of the bugs had nothing to do with the CPU, but were issues with C programming, such as not accounting for leading zeros when negating a value. I have also implemented interrupt and reset microcode vectors, though I have not added interrupts to the simulator yet. I will add them when I have completed tests that verify all of the instructions first.
On the RTL front, I have written additional python code to generate SV files specifying the instruction control and microcode tables. I have also started diagramming my design on paper.
According to my schedule I am woefully behind, as I should now be done with my SV implementation, and moving on to work on the SD card interface. This will almost certainly have to be postponed, and I am confident that I can finish writing the base RTL implementation by tomorrow night.

Oscar

This week I was able to work on the Register Interface for the PPU. This is an important component of the PPU since it enables communication with the CPU. I was able to finish the SystemVerilog code for the module and I am almost done testing it. I wrote a testbench to test the registers that have to read and write memory: OAMADDR, OAMDATA, PPUADDR, PPUDATA, OAMDMA. OAMDMA was especially important to get write since its the most common register and the timing  of performing an OAM DMA has some quirks. The other registers were tested visually by synthesizing on the FPGA and hooking the switches and buttons to the registers to allow me to write specific values to them. This way I was able to confirm that the PPUCTRL, PPUMASK and PPUSCROLL registers are writing the values correctly. Since these will cause visual changes, it was easier to do this style of testing.  Over the next couple days we are going to try integrating the CPU and PPU to get something moving on screen. So far most of my design has been synthesized and tested which should ease the process.

In terms of schedule, I am back on track. According to the schedule I should be integrating with the CPU which is exactly where I am. Moreover there are some tasks that were initially left for later which I finished earlier in order to get a demo by next week.

Diego

This week was dedicated to actually implementing the APU, mostly because our mid-semester demo is this coming Wednesday. By then I hope to have the FPGA output the pulse, triangle, and noise waves. The DCM channel requires reading from memory so that one will likely be more time consuming and completed after the demo. Furthermore, the nonlinear mixer requires more research and all channels are needed for the frame counter to do its job so that is also for later. This week the triangle wave channel has been implemented with its sequencer, timer, linear counter, and length counter. My next goal is to synthesize the design and listen to the audio output before starting on the other channels.. The great thing is that all the other channels use many of the components that are sub-modules of the triangle channel so hopefully it will just be matter of instantiating them with different control signals. Furthermore,  I discovered that Quartus has IP to initialize and drive the Audio Codec on the de2-115. This is great news since after reading the datasheet for it it was a rather tedious and error prone process via i2c. This will allow me to focus more on the actual APU design rather than how to transmit to speakers.

According to my schedule, this coming week should be for testing the APU. The APU is not complete but this week is mostly free for me so testing the APU’s sub components will be very doable. Hopefully, this week will have the parts of the APU completed and verified so assembling them and testing will get us ready for the week after, By then it is integrating it with the CPU. My concern is that this would be one of the first times integrating the separate components which may be more difficult than we thought. Either way, the priority is completing the APU which should be done.

March 23, 2019

Oscar:

This week I was able to dedicate most of my time to capstone, as a result I got several things done putting me almost back on track (I’m only behind by a day or two). Some of the things I accomplished this week:

  • I designed and implemented the sprite rendering pipeline. I figured out the timing for prefetching sprite data from the OAM and prefetching the tile data for sprites. Since in background rendering and sprite evaluation I need to access chr_rom, the accesses have to be timed correctly so that they don’t overlap. This mean that I get the tile data for backgrounds while rendering pixels in the first 240 cycles of the scanline rendering, then the subsequent 64 cycles are for accessing the tile data for sprites.  I had some bugs with sprite evaluation and sprite priorities. Specifically, for sprite evaluation I was using incorrect row data to prefetch tile data from chr_rom. In terms of priority I had a misunderstanding of how priority worked however using my frame_sim script I was able to figure out the correct behaviour in software before implementing it in hardware.
  • Another important development was synthesizing the PPU on the FPGA to render static frames through VGA to a display. This was important for the upcoming demo, because we will be able to display something on a display. For this I had to do some calculations to figure out the front porch, sync pulse, and back porch timings specific to our design. Here is a picture of the PPU in action:

  •  Finally I started writing the testing framework to verify the correctness of the frames we render. I also figured out how to use the Mesen emulator to create snapshots of frames in game to use them as reference. This has been very useful because it aided me in finding bugs in my design.

Overall this week was very productive, I anticipate this upcoming week being equally productive. Specifically I aim to finish the PPU by writing the register interface and implementing scrolling. Having this will help us in the upcoming demo.

Diego:

This week was dedicated to planning how the APU’s sub-channels will be transmitted toa speaker via line-out (AUX). I searched the Altera website for tutorials and demos for using the 24-bit Audio Codec that comes with the de2-115. The resources I found were not very helpful because they were .sof files for synthesizing onto the FPGA so there wasn’t any information for interfacing with the Audio Codec. Instead I read the datasheet for the WM8731.  There it explains the address space and the register control used to drive the DAC and how to format this information for the NES audio output.

I am technically on track because I have made some progress on writing one of the channels for the APU (triangle channel). This will be essential since next I will use the I2C interface to try and output the triangle wave via the headphone jack. Most likely, I will use a split AUX cable to observe on an oscilloscope whether or not the triangle wave is being transmitted. As for next week, it will be dedicated to implementing and debugging the I2C controller and ensuring that a triangle wave can be seen at the Line OUT. Furthermore, once that is working. It should not be much more difficult implementing the other channels and testing their outputs. I hope to have this accomplished next week since the next major part will involve controlling and mixing the 5 channels to produce the finale wave. Essentially, in two weeks the APU has to be finished.

Nikolai:

This week I continued to work on the CPU simulator. I finished writing my simulator, and I am currently in the debugging process. The current code should be able to handle all of the MOS 6502’s functionality’s, with the exception of interrupts.
Although I don’t have interrupts handled yet, integrating them should be as simple as adding additional microcode to handle them.
My immediate goal is to finish testing my simulator, and then begin work on the System Verilog implementation. The transition seems as though it should be very easy now that the simulator is written. I can use my python script to generate microcode in System Verilog, and much of the code for the rtl implementation should be mostly a direct translation from the C implementation.
At this point I am behind schedule, as I’m still working on the simulator, when I should have the Verilog implementation done, but I believe that I can get the simulator tested and Verilog implementation written by the next status report.

March 9, 2019

Diego:

The week was dedicated to organizing and writing the Design Review report. My focus was on further fleshing out the APU and breaking down into sensible modules. It was also considering the possible risks and possible bottlenecks of the project with suggestions to avoid or overcome them as quickly as possible.  According to the schedule I am a bit behind. This week was dedicated to doing further research on how the different channels represent their output wave but I still need to figure out how the final wave will be outputted from the FPGA and if we have the hardware necessary to implment the mixer and use the DAC.

Oscar:

A good chunk of last weeks work was put into the Design Review Document. Apart from that I also worked on fixing the background rendering hardware. I had a couple bugs that took a while to track down but in the end I figured out the issues and it seems to be working correctly, for example the following frames only render the background:

These are the reference images:

You can actually see that the background for the Super Mario Bros game isn’t exactly the same. My camera is a bit shifted to the left. This is expected because the scrolling logic hasn’t been developed yet.  But for something like DK where there is no scrolling it matches perfectly. I also downloaded Quartus Prime on my computer so I am able to program the FPGA from my home. This upcoming week I don’t anticipate getting much work done because of the break. However, when I come back I plan on getting the sprite rendering logic done, and work on the VGA module to see if we can output frames to a display. After that I will implement scrolling logic as well as the registers.

Nikolai:

I was not able to complete much for capstone this week, as most of my attention was focused towards managing my pre-spring-break workload of projects, assignments, and midterms. This did include the ethics paper for this class, which is now conveniently out of the way.

I’m optimistic that I can get myself back on schedule over spring break, and that I’ll be able to finish our processor shortly after courses resume.

March 2, 2019

Oscar:

This week I started onboarding for the DE2-115 FPGA board, did some research as to what version of Quartus we want to use. We have commited to using Quartus Prime 16, available on the ECE machines. One of the biggest drawbacks of Quartus 12 is the difficulty of importing new IP blocks developed by Quartus, post Intel acquisition.  Newer versions of Quartus have an easily accessible menu where you can checkout the latest IP blocks, amongst which is an SD card IP which we plan on using for reading and writing SD cards. I also went through the steps of synthesizing a project on the board to remember what the process was and to ensure there were no major differences with how Quartus 12 worked. I used my 18-240 code for Brick Braker lab to test the synthesis. There were some issues with hit detection, when synthesizing with Quartus 16.  I asked Ford Seidel what he thought, and we came to the conclusion that it was most likely some undefined behaviour with my code that made it work on Quartus 12 but not Quartus 16, since there were no inferred latches.

This week I also started writing a SystemVerilog implementation of my PPU design. Currently, the hardware for rendering backgrounds is fully connected however there are some bugs. We render this:

 

Instead of this:

The color palette seems to be correct however the pixel locations are completely off. Most likely an issue with memory offsets. Will debug that in the coming days. Also wrote a testbench for our PPU design to render frames, which is how the above image was created. The testbench uses python scripts to create an image of a frame trace generated in SystemVerilog. In the upcoming week I hope to finish background rendering and start sprite rendering as well as a displaying frames through VGA, so that when I come back from break I can start working on the register interface of the PPU.

Nikolai:

This week I continued working on implementing and simulating the CPU. I have finished writing the microcode for the CPU, which is contained within a series of google doc spreadsheets which can be found here:
https://tinyurl.com/mymicrocode

This microcode will be used both in my c simulator as well as the final system verilog implementation. I have begun to work on a python tool that will translate microcode csv documents (downloaded from my google doc spreadsheets) into either c or sv files that can be used alongside the datapath simulator or implementation.

Additionally I spent some time this week working on our design review presentations.

Diego:

This week was dedicated mostly to get a good understanding of the APU. What once seemed as optional for the game functioning has gained a bit of priority. The APU is responsible for playing music and sound effects for games so a game is still very much playable as long as you can see it and send inputs via controllers. I recently discovered that the NES does not have a built-in timer so some NES titles use the DCM sample channel to play nothing and once the “empty” sample is finished it triggers an IRQ to the CPU to control events. Below is a the block diagram I assembled of the major components and signals they use to communicate.

The following days will be dedicated to continue debugging the current PPU hardware implementation. My main suspicion of the incorrect background frame creation is incorrect addressing. But it is also worth checking that the simple memory modules, for example the OAM, is loaded in with the correct data and the addresses access its corresponding initial data. So this week will mostly be writing assertions to quickly find the bugs.

Team:

We are still on track,  however no work is going to get done over break so this upcoming week we have to make sure we accomplish our goals. One system design change is a slight modification of the PPU rendering pipeline. For every scanline, we are going to render its pixels on the scanline prior and store the pixels in a scanline buffer. The once we reach the next scanline the VGA module will move the scanline buffer into another buffer that it has access to and either output the pixels twice at double the frequency or once plus a black scanline (CRT look) so that we reach the 31KHz scanline refresh rate expected by the display through the VGA interface.

February 23, 2019

Oscar:

This week I finished writing the frame simulator script, it now supports sprite rendering. Finishing it really solidified my understanding of how to render sprites and it helped me understand how to deal with scrolling backgrounds. I also completed a preliminary design for the overall structure of the PPU.

 

Now it is a matter of translating the logic from the frame simulator into hardware. To stay as cycle accurate as possible, we will be closely mirroring the rendering timing of the original PPU, which can be found here: http://wiki.nesdev.com/w/index.php/PPU_rendering.  In addition to this I also spent time thinking about the timing of the VGA and the PPU. I did research and concluded that we are going to be outputting a 640×480 signal from the VGA module. To upscale the NES’s video signal (256×240)  vertically, we are going to render the even scanlines normally and the odd scanlines are going to be all black, this will fill in the remaining scanlines needed to get to 480 and give our games a CRT-TV look. For instance:

Since we are running the VGA module at clock/2 and the PPU at clock/4 then the VGA module is going to sample the pixels we generate at twice the frequency, thus generating 512 pixels wide. The remaining 128 pixels we are going to black out. This week was busy, so I didn’t get to write any SystemVerilog yet, however with the overall structure of the PPU finalized and a better understanding of the PPU rendering pipeline I feel confident to start implementing the PPU on FPGA this upcoming week. The goals for this upcoming week are to start the PPU development and to write the Design Document.

Nikolai:

This week I continued working on the CPU. I have come up with a preliminary datapath design, and have started working on defining control signals. Most control signals are fairly obvious, and I have begun writing microcode to manage the control signals. In order to minimize the amount of time writing microcode, several opcodes can share microcode instructions in the microcode ROM, but each of these opcodes must have their own unique control signals. For example, an absolute addressed SBC and ADC are almost exactly the same, but they give the ALU a different input on one cycle. Instead of writing the same microcode twice, we have one set of microcode for different addressing mode types, and one set of microcode for the different instructions. The first set mostly manages the address line and reads and write to memory, while the second set mostly manages register to register transitions and ALU operations.

The microcode I’ve written so far can be found in this spreadsheet:
https://tinyurl.com/mymicrocode

While going through this process of writing microcode based on cycle timing tables and instruction specifications, I’ve noticed that I will need to do some iteration on the different types of microcode and data path, since implementing features in one area uncover features that need to be implemented in another area.

As of right now I am behind on my simulator, which I was hoping to have finished by now. Having the microcode finished and my datapath fully specified are the most important part of developing my simulator, so by next week I am optimistic that I will have my microcode and my simulator done, and then I can move on to testing the simulator and then developing the system verilog implementation.

Diego:

This week not much was accomplished. Before tomorrow I have to have a strong understanding of the APU and be able to create block diagrams for the major components we need to implement for audio. This will be the design proposed for the design review presentation.

February 16, 2019

Oscar:

What did you personally accomplish this week on the project?

This week I finished reading most of the NES PPU documentation on http://wiki.nesdev.com/w/index.php/PPU . This includes learning how the background rendering process works, how sprites are layed on top of backgrounds, the memory layout of the PPU, how to compose the vram tables (pattern tables, nametables, attribute tables, OAM, palette memory) to create a frame. To consolidate this understanding I wrote a frame simulator in python that takes a vram memory dump (obtained by debugging mode for the Mesen emulator) and composites the corresponding frame. At this stage it only renders the background, but will be extended to also render sprites. Here is a comparison, to the TOP is a screen grab of the Mesen emulator with sprites disabled and to the BOTTOM is the frame generated by my script:

                  

Is your progress on schedule or behind?

I am still on schedule, the script i wrote really help me get a better understanding of how to interpret the VRAM data. This week i was supposed to Read Sprites from VRAM and generate background sprites

What deliverables do you hope to complete in the next week?

This week I hope to perform a timing analysis to figure out if/how VGA might affect our fram timing, and ensure that there is enough VSYNC time for games to make their updates. I also hope to make block diagrams for hardware modules and implement background rendering on FPGA.

 

Nikolai:

This week most of my efforts were spent on researching the MOS 6502 CPU. This started with familiarizing myself with the user visible state of the processor (the memory, program counter, stack pointer, accumulator, index registers, and status flags), and an overview of the processor’s instructions and addressing modes. There are some gotchas that I’ve had to uncover, such as undocumented instructions, cycle by cycle timing, and other errata. To do most of this research I’ve had to scan through vintage console wikis and pore over ISA spec sheets, original manuals, and timing specifications. Below I’ve included a list of the most relevant links that I’ve found, with brief descriptions of what they are.

In addition to research, I’ve begun building a MOS 6502 simulator in C. I believe this tool will help me quickly figure out exactly how the simulator should behave, which will help me build a correct systemverilog implementation more quickly. The simulator is pretty baren so far, as it mainly includes definitions of structs used to model hardware state. Another thing to note is that I am planning on making a python script that will allow me to specify microcode, and have that specification be turned into an indexable array in either C or systemverilog, which will save a considerable amount of time.

Right now I am technically behind schedule. As I was supposed to be done with the control operations of the CPU specification by now. The subtasks of the CPU portion of the schedule were defined when we had a vague notion of how our CPU worked, and now I can think of ways to break down this section that make more sense. First I want to finish my simulator (including microcode) such that it can emulate the base ISA of the MOS 6502, and then I would want to implement the undocumented instructions. After that I would implement the verilog implementation, which should be quick since I won’t need to rewrite my microcode.

My plan for the next week is to finish my software simulator such that it will be able to run all of the documented instructions in the MOS 6502 ISA. I doubt I will be able to have this simulator bug free in a week, but I am optimistic that I will have at least an almost correct implementation by then.

 

Links that I’ve explored through my research:

This source give cycle by cycle explanations of what the processor should be doing when executing instructions of different addressing modes.
http://nesdev.com/6502_cpu.txt

 

Diego:

This week was focused on learning about the NES. I looked up information of an overview of the system and how they communicate/interconnect. More specifically, since I will be working on implementing the PPU the research focuses more on it. Much of my research involved learning how the NES stores the pictures efficiently. A combination of sprites, backgrounds, palettes,  patterns, etc.
Furthermore, my research also included information about memory mapped registers and the protocols used to communicate between the CPU and PPU and the overarching process of rendering on the image on the display Below you can find links to the different documents I read to better understand the   Nes internals.

Intro to NES Graphics:

NES Graphics – Part 1

NES Graphics – Part 2

NES Graphics – Part 3


Intro NES programs:
http://nintendoage.com/pub/faq/NA/index.html?load=nerdy_nights_out.html

PPU:
http://wiki.nesdev.com/w/index.php/PPU

It does seem that I am behind according to the schedule. By now, reading sprites from RAM and generating them should be complete. To catch up I would focus more on creating a simulator to read “banks of NES memory” to fetch and create the sprites. Once this behavioral model is implemented
and verified then it will serve as a proof of concept. Moreover, it would simplify actually describing this subset of the PPU in hardware. As mentioned previously, the goal for this week is to at least create a simulation for the sprite unit of the PPU. If possible, begin describing the hardware for the
background portion that has already been simulated by Oscar.