Author: dpratyus

This week, I spent most  of my time understanding the different types of memory on the board, writing the design document, as well as helping with the CPU FSMs. While working on the document, I realized I needed to read more into the SoC and how it integrates with the FPGA and controllers.

I worked on the introduction, memory management, qualitative requirements and SoC sub-system parts of the document.

Since the bios on the SoC has a way of interacting with the USB port (to say, decode NES Controller signals), the next question is figuring out how to get the SoC to talk to the FPGA. We plan on using the SDRAM on the FPGA, using it as MMIO accessible by SOC else, we are going to resort to the FPGA using DDR3 memory on the SOC. I am also looking into the HPS-> FPGA bridge tonight, and will have a more conclusive approach.

Here are the two manuals I am cross referencing at the moment:

Hard Processor System Technical Reference Manual

DE10 Standard User Manual

Meanwhile, SOC has access to the flash memory, can load and store game state.When a game switch happens, the SoC will let the current screen finish rendering and then stop the CPU’s execution. Once the execution is stopped, all of the CPU’s state and the memory will be saved for later re-execution, in flash memory. Afterwards, all of the state will be cleared and the new game state will be loaded in from flash to SDRAM.

By the end of Spring Break, I hope to have:

• A way of manipulating memory through SoC and FPGA
• Help with implementing CPU

 

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

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