Status Reports

Adolfo’s Status Update for 2/29/2020

This week I changed my focus to the design review and document. I took this as an opportunity to further understand the PPU and how it interacts with other systems. I think this helped a lot since I now have a much clearer view of how the PPU and its interactions with the rest of the system will play out. I am excited to start working on this part of the system once the CPU is done.

We decided to be proactive about the design document so we started working on it throughout the week. To do this, we had to do further research and we also incorporated the feedback from the presentations to further flesh out parts of our project that we thought were not well defined such as our metrics and evaluation, so did our classmates.  To do so, we looked at the performance of other emulators and try to pick based on varying levels of success. We are going to be using Verilog Boy as our baseline performance goal. We do this because that is the best emulator that we found in our area (hardware).

For the design document, I wrote the abstract, the design requirements, the architecture and principle of operation, the CPU sub-system description, the PPU sub-system description, and related work.

Next week we plan to go full force into implementation and have ambitious goals for the end of spring break. My personal plans for the end of spring break are as follows:

  • Get a working CPU implementation with interrupts disabled.
  • Get a working PPU implementation, try some display tests.

Failing to achieve these goals may put the success of our project into question since we still have to deal with integration.

Pratyusha’s Status Update for 2/22/2020

This week I worked on understanding the different parts of the DE10 Standard Board, and going through the manual. I also tried setting up my laptop with the board (still ongoing), and procuring a spare windows laptop just in case.

I’ve been looking into how memory works on the game boy, and memory/storage specs on the DE10 Standard Board.

Memory on the GameBoy:

Here is my understanding of the important parts of memory mapping on the game boy/boi. When the Game Boy first boot’s the bottom 256 bytes of memory is occupied with the boot ROM.

Once the Game Boy is done booting, it unmaps the boot ROM from memory. Then the to address 1-> 0x3FFF are occupied by game code loaded in from the cartridge. Inside of this memory are the interrupt table and the cartridge header area. I’m not sure how flash interacts with this cartridge header area, and I’m going to discuss my interpretation with my teammates tomorrow.

The remaining sections of memory are the tile ram (0x8000 – 0x97FF) which  contains data about the graphics that can be displayed to the screen. The Game Boy uses a tiling system for graphics meaning that a game doesn’t control the specific pixels that get drawn to the screen. The placement of tiles at certain positions happens in the “background map” (0x9800 – 0x9FFF).

Next up is Cartridge RAM. I’m looking into whether or not the games we load need this, (0xA000 – 0xBFFF) Cartridge RAM. Since we don’t have the external cartridge, might have to specially map this to some other section of memory.

(0xC000 – 0xDFFF) is Working RAM; it’s function is as you’d expect of working RAM  and (0xE000 – 0xFDFF) is Echo RAM.  This section of memory directly mirrors the working Working RAM section.

0xFE00 – 0xFE9F: OAM (Object Atribute Memory) – Used for special characters (sprites). 0xFEA0 – 0xFEFF: Unused – This area is completely unmapped: reading from it just returns 0s and writing to it does nothing.

0xFF00 – 0xFF7F: I/O Registers

0xFF80 – 0xFFFE: High RAM Area

0xFFFF: Interrupt Enabled Register

Other notes

In total, the above Memory mapping amounts to 64 KB, and we have 1 MB of persistent storage that we can use through the Mircro-SD slot. So we’re more than covered for game switching / random hacks that we may need to put together for our gameboi to work. I am amazingly shocked by how much memory was allocated per game… a mere 64 KB!! Either ways, we have more than enough RAM to work with, considering the 64MB (32Mx16) SDRAM on FPGA, 1GB (2x256Mx16) DDR3 SDRAM on HPS and the MicroSD Card Socket on HPS. Since game switching requires persistant storage, I was thinking of storing the different game states in the Micro SD card Socket, and a table that knows which game maps to which section of memory in there too.

Meanwhile…

I looked into other DE10 Standard Projects, to understand how they employed memory. I also found a project , part of which could be done as a warm up to understand the board better.

I will also be working on some of the CPU Fsms before tomorrow’s group meeting, and have a discussion on whether DDR3 SRAM or the standard RAM is better to use.

 

References:

https://github.com/AntonioND/giibiiadvance/blob/master/docs/TCAGBD.pdf

https://gekkio.fi/files/gb-docs/gbctr.pdf

Adolfo’s Status Update for 2/22/2020

This week I managed to get all the information we need to make the PPU. I used various sources to get a good idea of the timings and the overall architecture of the PPU and I think I’ve achieved a good understanding of its inner workings. I used the following sources:

I also browsed through some emulator forums’ threads to check for more specific architecture details about the Gameboy since these docs didn’t mention specific hardware details that could be useful for achieving maximum PPU fidelity. In the end, I decided that it may be a bit hard to get an architecturally accurate PPU representation, so I will just attempt to have one that matches the timings and expected values at each moment.

After this, this is the datapath I came up with:

A PPU “cycle” is divided into 4 stages, these will give the datapath above a bit more meaning:

  • OAM Search: In this stage, the sprite fetcher will look for the sprites that are needed for this VBlank stage and put them in the sprite buffer. It can only fetch up to 40.
  • Pixel Transfer: In this stage, the fetcher will start fetching tiles from memory and then put them in the pixel FIFO. Since it can fetch a whole row at a time (8 pixels) then the FIFO supports pushing 8 items at once. Based on the registers (which are not shown) the fetching may either fetch sprites, background tiles or window tiles. The pixel FIFO pushes the pixel at the front onto the screen.
  • H-Blank: This is the time between each row of the screen. The CPU usually does some work here.
  • V-Blank: This is the time between being done with the screen and starting to render the next screen. The CPU usually uses this time to modify VRAM.

I will further expand on these on the design review.
My goals for next week are as follows:

  • Start implementing the PPU
  • Finish the CPU design and start implementing it.
  • Work on the design report.

Team Status Update for 2/22/2020

This week we worked together to finish the FSMs for the CPU. Since there were so many FSMs, we decided to divide them amongst the team members so everyone had a thorough understanding of how the CPU worked and what the control signals would be. This will help make implementing the datapath and FSM easier in the future.

Furthermore each member developed a datapath/system diagram for their individual section (see further description in individual status updates). We now have to work together to understand how they will need to interact with each other so we can set standards for dependencies. This is one of the biggest risks because each part has their intricacies and we don’t want to violate any dependencies.

We had to shift our focus and polish our designs for the design presentation next week. For next week’s report, we hope to have implemented the CPU datapath and FSMs, and begin debugging. Individually, we hope to have our individual parts planned so they can be implemented as well.

Tess’ Status Update for 2/22/2020

This week I worked on finishing the FSMs to manage the CPU when there are multi-cycle instructions. Last week, Adolfo and I determined that we would need either one big FSM with multiple branches or multiple smaller ones. We decided to make the smaller ones. I worked on the FSM for the 8-bit ALU operations, 16-bit add operations, pop/push, inc/dec, and CB instructions. Adolfo and Pratyusha are finishing the final 2 FSMs. During this process, I realized there were a lot of flaws in our original CPU datapath so I was updating it with needed connections.

Afterwards, I did more research into how the Game Boy audio works. To save space, the Game Boy had a real time synthesizer because holding an entire audio file in the cartridge took up too much space. There are 4 voices with 5 registers each. Two of the voices are pulse waves that produce the tone. One voice defines the wave shape and the other is used to output white noise. The bits in the register define the voice so each wave needs its own decoder because the bits are in different locations and mean different things depending on which wave you’re looking at. From there, the voices are mixed together and controlled by 3 sound controlling registers. With this information, I was able to design a preliminary datapath for the APU:

With knowing more about the audio, I was able to select and order at DAC. I selected the Monolithic 16-bit AD669 DAC. It is 16-bit with parallel transfer and has a sampling frequency that will be more than suffice for our sound quality. Additionally, it is a through-hole chip, so we need to wire the GPIO pins of the development board to a breadboard. To get the audio into a speaker, we also had to purchase an audio jack breakout board.

Action items for next report:

  • Design how the mixer will work
  • Read through DAC manual to know what circuit requirements are needed
  • Implement FSMs for CPU

Pratyusha’s status report – 2/15/2020

This week we worked on designing the datapath for the CPU. We currently have a two stage pipeline with fetch/decode/execute as stage one, and memory as the second stage. We went through each instruction and used a couple of references such as Gekkio’s Game Boy manual and the original Game Boy handbook to figure out the datapath.

I then worked on the datapath for the CPU. It was hard to get started because I am not as familiar with system Verilog, considering I haven’t taken 18-447 (currently registered for the same) and/or 18-341, but I’m hoping to learn more through capstone, and my teammates. The biggest challenge was figuring out the overall structure of the modules for the CPU, and how to represent pipelining via Verilog code.

I have started looking into  memory mapping for the FPGA, and hope to have more details fleshed out for switching game state in time for the design review.

Action items for next report:

  • Memory mapping for FPGA
  • Controller and flash drivers

Tess’ Status Update for 2/15/2020

This week I worked with the rest of the team to design the datapath for the CPU (which can be found in the team’s status update for the week). Our original CPU design was a two stage pipeline where stage 1 was fetch/decode/execute, and stage 2 was memory. When we learned that all memory accesses use the same memory, we had to rearrange our pipeline. Once done, we were able to add the needed components and connections to match the timing of the Game Boy.

Afterwards, Adolfo and I worked on determining a way to handle multi-cycle instructions. For Game Boy architecture, only 8-bits are sent at a time. Therefore, for multi-cycle instructions, we are continuously receiving new information that is needed for one instruction. To handle this, we decided to use an FSM that would save state for the datapath so it would know which instruction we were handling at all times. The idea is that the FSM will be located in the fetch/decode stage. In the cases of single cycle instruction, it would only enable the pipeline register. In all other cases, it would essentially take the place of the decoder and send the needed control signals. After designing the one large FSM, we realized that it would be cleaner and easier to debug if we had multiple smaller FSMs to handle each category of multi-cycle instructions. We currently have 7 FSMs.

On my audio work, I was researching the different ways we could get audio from the FPGA to a speaker. The first was to use the on-board CODEC that would allow us to directly insert a connection between the board and a speaker. The issue is that the CODEC is dependent on the I2C protocol, which would take significant research, implementation, and testing to assure it is correct on top of the Game Boy audio itself. The alternative is to use a DAC to convert signals for us. This is the more straightforward option because there is no protocol. I have found two DACs that we can potentially use: Monolithic 16-bit DACPORT AD669 and PCM2704CDB. I will continue to look at their data sheets and consult a TA before making a final decision.

Action items for next report:

  • Finish FSMs for CPU
  • Finalize which DAC we will be using
  • Draft an audio datapath

Team Status Update for 2/15/2020

This week we worked together on designing the datapath for the CPU, we tried to reverse engineer the datapath based on the instruction timings and known aspects about it. With the help of this reference, we were able to get a datapath that we believe accurately represents that of the Gameboy. We hand executed some instructions through it and they all matched the cycle timings that the Gameboy reference manual specified. Here is the datapath we came up with:

Furthermore, we made a first draft of the FSM for multi-cycle instructions, this is what we came up with:

For next week’s report, we want to be able to have an initial implementation of the CPU and have a testbench for it so we can start ironing out bugs. We think this is important so that we can all start focusing on our areas of the project.

Adolfo’s Status Update for 2/15/2020

This week I worked with the rest of the group on figuring out the CPU’s design. I found this document which gave accurate timings for each instruction (it is incomplete though as it is a work in progress). With it, we were able to draw a datapath we believe accurately represents the Gameboy’s pipeline. Afterwards, Tess and I tried to figure out implementation details of multi-cycle instructions. We decided to solve this problem with an FSM which would control the different stages of a multi-cycle instruction. The basic idea is to have the FSM divide each multi-cycle instruction into smaller single cycle instructions. We believe this behavior mimics the Gameboy’s behavior best because it has been observed in the emulator community that in the middle of a multi-cycle instructions flags get set multiple times.

On my graphics work, I did some research on the inner workings of the Gameboy PPU. My next action item based on this will be to sketch out a datapath for it so that we can talk about it in the design review and also so I can get started with implementing it. Furthermore, I got the VGA controller working and tested it on the screens in the labs. It has a small bug with the bottom line of the display, I will try to figure it out sometime this week, but it’s not a priority. One thing that I will have to figure out is how to display the Gameboi’s output since the resolution doesn’t match the 640×480 resolution of the lab’s screens. I was thinking of probably having a pixel in the original Gameboy’s screen represent multiple pixels on the screen. This is a discussion for the future.

Action items for next report:

  • Make a PPU datapath drawing
  • Get the Gameboi decoder and datapath implemented
  • Fix the VGA glitch