Month: February 2021

This week, aside from helping with the presentation and discussing the overall plan with Joseph, I worked on research for the Audio, Input, Software, and Communication systems. I’ve attached a copy of my notes.

Suffice it to say, the current plan for audio is to have a single channel of 8-bit PCM audio and 32KHz, which will be representative of the GBA in sound power. Note that our users will be able to produce better sound, as they aren’t bound to a 16MB cartridge, though. Audio will be output by sending samples supplied by the CPU over I2S to the HDMI output. The interface itself hasn’t been designed yet, as I’m not sold on how it should be done specifically, so I’m a touch behind. I plan to get that done as soon as possible, and I’m confident I can be back on track by the end of next week.

For input, we plan to use a SNES controller over GPIO. I go over the details of the SNES controller communication protocol in my notes. It’s a simple protocol thats clocked well below what our FPGA will be clocked at. It should be relatively simple to bring up, as long as we can find controller ports.

For software, I took another look at the C standard and realized that our requirement of providing it to the user is completely infeasible if we are also creating our own kernel. The C standard has a lot to say about what an OS should provide, and we won’t be providing much of it. I’ve narrowed it down to a useful subset, which is listed in my notes.

For communication, I spent way too much time trying to understand how the FPGA and HPS communicate with each other. From what I can gather, the last GB of the HPS’ address space is mapped to the HPS-to-FPGA AXI bridge, and reading from/writing to it will send a signal to the FPGA that it can interpret and respond to. I think I’ll have to run some experiments when I get my board to convince myself of this. I’ll also need to spend some more time with the Cyclone V manual, it seems.

Finally, I also wrote a small C program to convert 16-bit 32KHz Mono Microsoft PCM Wave audio to pure 8-bit samples. It works with all the wave files I’ve exported from audacity into this format, though I didn’t rigorously test it. I did this so that once the audio system is brought up, we have working audio to make a direct comparison against. The program will also output 8-bit wave form audio in the wave format, so that it can be played on a computer and compared to our FPGA’s output. The source code for the program has been attached as well, though I’ve not tried building it on Windows/Mac.

Program source

Design Notes

This past week, outside of our group meetings, I looked into what would become our requirements for the processor in our handheld. Previously, all we really had nailed down was that we wanted something Arm clocked at at least 16MHz. We can now specify some more detail on that.

 

Based on our projects overall goals of providing a safe development environment, we decided to create a small software kernel for our console. This means our processor must provide the tools to implement such a kernel, namely memory protection. Arm processors do offer memory protection, but as an optional component, so we’ll need to ensure that if we use an Arm processor it offers memory protection. We must also ensure that any processor we use allows us to externally send interrupts to it. This will become important when managing our graphics and sound output. Finally, we’ll need a timing register to allow our kernel to support some basic timing facilities. Currently, I think our best bet is to simply expose a configurable timing interrupt to the user. Such an interrupt would hand off to some user provided function in a specified interval and allow the user to perform some time sensitive operations. Doing so would allow the user to track the passage of time and perform time based actions like multi-threaded code, should they wish to. Due to timing constraints, providing the user with a full threading library is outside the scope of our project.

 

Additionally, I also was able to get more firm requirements on the memory of our console. The GBA offers 256KB of slow ram + 32KB of fast ram, with the latter often used to cache full arm instructions as it was the only ram in the console to use a 32-bit bus. Since our project is aiming to provide a similar experience to consoles like the GBA, we must provide at least 512KB of ram. Since we’ll be including a kernel with our console, we should provide more than that, likely closer to a megabyte. In any case, I doubt this requirement will be difficult to meet. The more interesting one is the long term storage requirement. GBA cartridges ranged in size from 4MB to 32MB. We’ll need to ensure that our console offers long term storage in this range, and preferably said storage will not be unbearably slow. One option could be to ensure that we find an FPGA which offers at least this much flash storage.

 

At this moment, we’re right on schedule. In this next week, we will finish off our proposal presentation and research the hardware we will use for our project.

 

The basic GBA hardware information was obtained here:

https://www.copetti.org/writings/consoles/game-boy-advance/

 

The cartridge size information was obtained from here:

https://projectpokemon.org/home/forums/topic/22987-what-are-all-possible-rom-sizes-for-clean-dumps-gb-gbc-gba-nds/