Status Reports

Pratyusha’s Status Report for 4/12

The first thing I did this week was to get internet (WiFi from MaC) working on the board, so I could use okpg (the Angstrom package manager) to install basic commands and kmod.

Then, I tried meddling around with connecting the NES USB controller to the board, but I couldn’t see any additions in /dev/input. To start simpler, I acquired a wired mouse, and added it on the second port, though couldn’t find it either. However, lsubs and fsdisk showed the devices.

After figuring out which device was the addition, I looked into the events in /proc/bus/input/devices and found the mouse event. It then also appeared in /dev/input.

I later realized that the NES Controller wasn’t going to appear in /ttyUSB* because it wasn’t a serial device, and thus the approaches outlined in here  wouldn’t work.

After isolating the character event through dmesg and simple hacks like printing out system state at various points of plugging and removing the attached device, I couldn’t read legible data from the device.

The kernel modules that would’ve made it easier to read the usb input weren’t compiled into this distribution of the Angstrom kernel.  So I tried to compile the missing kernel modules that would enable me to read human-readable signals, (modules – xpad/joydev). I am currently attempting that.

In the meantime, I have started reading up accessing the SDRAM. I will use a USB storage device to store memory instead of flash (or so is the plan, for now), because the board is still booting off of the Linux console version on the flash storage media (mirco SD card), and as far as I can tell, the guide doesn’t have a way of flashing the board, but I’ll keep searching for one. It is not a priority if the USB storage device can store persistant memory.

However, I’ve to understand how Qsys works, because from the SOC community, it seems like using qsys to initialize the AXI bridges is the best way to communicate with the SDRAM on the fpga side. I don’t have a Windows machine, and System Builder needs a Windows machine to generate the basic template (figuring that out).

Goals for next week include getting further along with saving data from USB storage to SDRAM, and making sure data integrity is persevered. I also hope to get NES controller unit tests working.

 

Some relevant sources:

  • https://www.raspberrypi.org/forums/viewtopic.php?t=160400
  • https://stackoverflow.com/questions/15949163/read-from-dev-input
  • https://stackoverflow.com/questions/3737655/reading-usb-input-stream-on-linux
  • https://forums.nesdev.com/viewtopic.php?f=9&t=19698 + latching????
  • https://stackoverflow.com/questions/3737655/reading-usb-input-stream-on-linuxhttps://stackoverflow.com/questions/15949163/read-from-dev-input

Adolfo’s Status Report for 4/12

This week Tess and I worked on the CPU side to get it up to the standards needed to run most games. I worked on making automated testing for our tests, afterward, we started running the Mooneye’s tests and blargg’s instruction tests. They are the gold standard for emulators and are commonly used to compare the accuracy of emulators against each other. Tess and I debugged the CPU this whole week, in the end, we managed to pass all of Blargg’s tests. A significant milestone, given that it was our main accuracy requirement for the CPU. We are currently working on passing Mooneye’s tests. We passed the CPU tests, but we are still working through the tests that stress the Gameboy’s peripherals.

Apart from the PPU work, I worked on getting DMA and the PPU working with the CPU. I managed to get our setup to pass Mooneye’s DMA tests and am currently working on getting the PPU to pass the tests, although our reference or “goal” for performance, VerilogBoy, fails all the PPU tests. We’ll see if we can improve upon them!

PPU saw a lot of progress. I first worked on getting it to display an image in simulation. Shoutout to Ford, which let me use the script that he used for his project to output what the emulator displayed in sim. With this, I was able to get the PPU to display a pattern. The more challenging part was to get the PPU to display its outputs on the FPGA. It proved to be non-trivial due to the VGA running at a 25MHz clock and the PPU running at 4.19MHz. I remedied this by adding a framebuffer to the VGA and putting an async-fifo between the two, a solution that took a long time to get right. After that, everything worked perfectly! Finally, I was able to get the PPU to display images rendered by the CPU in simulation, Tess is working on getting the tests to run on the FPGA and see if it also works there.

This was a very exciting week in terms of progress, we are now able to match some of the well-known emulators in CPU, Timer, and DMA performance and accuracy. This upcoming week our goal is to get our setup running Tetris and Doctor Mario. Two of the first games most emulators run. To be able to run the rest of the tests we’ll need to add memory banking.

Team Status Report 04/12/20

This week Adolfo and Tess worked on finishing the overall system by running the Blargg test suite. At the beginning of the week they had almost all the components needed to run the tests. After the mid-semester demo, they completed and put everything together. They worked on debugging and fixing issues that came up during the extensive and thorough testing. At the end, they were able to pass all the tests and now they are moving towards putting the system on the board.

Tess is working on getting the entire system on the board. She used the Megafunction wizard to set up memory and is currently compiling the entire system in Quartus. She will be working on getting Tetris running by the end of the week and then she will move onto memory bank switching.

Adolfo also worked on the PPU. His first goal was to display a background. When he was able to display that, he moved on to displaying static images. With this, he and Tess can start debugging on the board because he can display the result on the screen now. After this he worked on scrolling. He got scrolling working, but since our first goal is to run Tetris, he is moving onto displaying sprites.

Pratyusha set up internet on the board to get opkg to install relevant packages. She also detected the NES controller on the board, and is trying to compile the missing kernel modules and load them onto the board, to use joydev a the driver that converts the signals from the USB port to signals that can be used. The alternative to that, would be individually manipulating the latch, clock and data lines on the USB port to the controller, while reading and buffering data, after which we’d have to interpret it.

She also started working on memory component, and is trying to configure the AXI buses on Qsys to be able to talk to the SDRAM. Her goal is to get the unit tests for the NES controller working next week, and move further along on running Qsys and being able to access SDRAM from SoC.

Tess’ Status Report 04/12/20

This week I worked with Adolfo to finalize the CPU so we could move towards getting the project onto the FPGA. At the beginning of the week, we had a self-tested CPU that covered a majority of the tasks and we had a working timer and memory. Throughout the week, we realized we had small issues with the memory so we redid that.

We were able to run Blargg’s test suites, one of our benchmark unit test suites. These tests extensively tested our CPU because they tested each possible instruction with every possible bit location and number. Currently, we are able to pass all the tests so we believe we have a solid and completed CPU.

Now we are moving toward putting everything on the FPGA. We have all the components that we need by using the Megafunction Wizard. Currently, I compiling it in Quartus and loaded the memory with one of Blargg’s test so we can test on the board rather than in simulation.

Goals for next week:

  • Able to run Tetris on the FPGA
  • Start working on the memory bank controller to support more games

Pratyusha’s Status report for 04/05/2020

The goal for this week was to set up a network, a way to transfer files, run a c program that uses the fpga peripherals, and have a program for the controller to talk to the soc.

I spent  the initial phases of the week setting up minicom and transferring files. Ideally, I’d be able to scp files from the linux vm to the board and vice versa, but there was no means of setting up a network, which is why I ordered the ethernet peripherals.

In the meantime as a backup, I set up minicom. Since the board had no internet or network, there was no way of downloading any software onto and any other source of obtaining files other than direct serial com, I had to figure out a way to transfer files that didn’t involve xmodem or another decoding service. After much trial and error, I decided to go with base_64 as a primitive decoding service to transfer basic c files.

I then set up cross compilation and download intel fpga embedded suite which didn’t have a lite version as claimed in the guide :(. However, I found out about community version that some older versions came with and got it installed instead, and fixed issues with paths and root permissions as ece341.

Unfortunately, the ece341 VM comes with the memory portions pre-segmented and frozen, though I gave the VM extra gigs, it went towards an unallocated pool since the swap memory followed the /sda disk space. I installed gparted and though possibly jank, booted the ece341 VM onto the linux OS image that acts as host for gparted, and reassigned disk space by manually moving the swap memory placement. This took me quite a while to figure out.

Today, finally managed to set up ethernet connection. Getting right parameters configured, understanding network interfaces and different parameters, /etc/ folders relating to startup scripts and network and device dir, various commands relating to networking..

Now i can scp files, and set have run scp’d a c file compiled binary that I used to talk to the HPS peripherals.

Goals for next week include receiving signals from the USB hub and looking into Memory mapped RAM and game state saving.

 

 

Adolfo’s Status Report 04/5/2020

This week Tess and I worked on getting the CPU to an almost finished state. We wrote tests that stressed each of the different possible instructions that the CPU can run and debugged the relevant parts. We spent the whole week on this.  At the beginning of the week I got the testing infrastructure working. Testing assembly files is really easy now, since I made a testbench that loads files without the need to recompile and also made a bash script that automatically generates .hex files to load into memory. On Friday, we managed to pass all the tests we wrote for all the supported instructions. The CPU is able to run assembly scripts of varying complexity, the hardest test we wrote is Fibonacci. This test stresses our different load instructions, arithmetic instructions, conditional execution, and function calls. We also had more focused tests that tested specific instructions.

This weekend we worked on the peripherals, I worked on the PPU. The PPU FSM is working correctly and the fetcher also is working correctly. Unfortunately, due to issues related to setting up the new board, the PPU testing got delayed. Fortunately, setup issues didn’t last too long since I was able to get the VGA test running again on the new board. This wasn’t a waste of time since I got the pin assignments for the board and also figured out how to upload everything. This was the first time any of us worked with the new board with respect to uploading FPGA files and setting pin assignments.

Tess and I also researched the functionality of the other peripherals and got the DMA and the timer working. We also have a rough draft of the MMU and memory bank switching. We were very excited since we are now able to run some of mooneye’s tests, which are the benchmarks for cycle accuracy. We did not pass because of small of by 1 errors, which we hope to fix with an improved timer design which is more .

These were really useful resources for the peripherals and the instruction timings (I was able to merge typo fixes in one of them!):

Cycle Accurate GB timings

Gameboy Complete Technical Reference 

These were the assemblers and linkers that we used to compile our tests:

RGBDS

WLA-DX

For this week we want to finish the simulation testing and go on to FPGA testing. I plan to finish the work on the PPU.

Team Status Report 04/05/2020

This week Tess and Adolfo worked on implementing the CPU in simulation. They had to polish each component in the CPU and finish implementing all the instructions. Once they implemented everything, they wrote unit tests for each instruction to assure the system worked. Adolfo found a compiler to convert from .asm to .gb to .h so we were able to easily write unit tests.

After this, Tess worked on creating a memory controller that would handle the DMA process and manage access. A majority is done but she still needs to research memory bank switching. Since that was not a priority for getting the overall system running right now, since Tetris doesn’t use a memory bank controller, she started working on the timer. Her and Adolfo are working on getting that finished before the demo tomorrow.

Adolfo also worked on finishing the PPU. He is currently focusing on displaying a background image as the first layer of the display. He has the PPU FSM working correctly and fetcher. He was able to get VGA test running again on the new board. In addition, he was able to upload FPGA files and set pin assignments, which will be make it easier for the team to transition from simulation in the near future.

Pratyusha set up minicom to transfer files to the SoC, in the initial absense of a network and internet for the board. She then set up a network to talk to the board, and ethernet connections on either side (VM and Soc). She also rearranged memory of the VM by booting VM OS onto another linux OS to repartition and rearrange memory. After creating the cross compiled binary of a HPS program ,she scp’d it onto the board, and can now use ssh. The program uses HPS key to light the HPS led. Her next goal is to interpret USB signals from the hub controller, and understand memory mapped RAM.

Tess’ Status Report for 4/5/20

This week I worked on getting the CPU ready for demo and other components to integrate with the CPU. For the CPU, I worked with Adolfo to finish implementing it. This included polishing the ALU and datapath, and implementing miscellaneous instructions. After we implemented all of them, we tested all of the instructions with written unit tests. We wrote the test in asm and Adolfo found a compiler to convert it to a .hex file that the CPU could read. We now have a working CPU that includes interrupts and supports all the instructions.

The next component I worked on was memory. I wrote the memory controller for simulation that would handle memory access from the CPU and PPU. It gives each section in memory its own magic memory. In additional, it handles cases when the PPU and CPU want to write to the same location. In the memory controller, DMA processing are handled, which is when memory in one area needs to be copied to the OAM area. Currently, Adolfo and I are working on implementing the timer so we can run the tim00.gb test from Moonete test suite.

Goals for next week:

  • Implement entire system in simulation
  • Begin system wide test

Adolfo’s Status Report for 03/29/202

This week I finished the decoder and FSM for the CPU. Furthermore, Tess and I worked on hooking everything up to get it ready for unit testing.  We did this by writing  a magic memory module which will load instruction files that we generate. Currently, I am still working on getting unit testing up and running for the CPU, I found some GB assemblers which I’ll use to write tests. I also worked on a few PPU components,  I am working on trying to display a basic background.

For the next week, I hope to have a good testing infrastructure up and running and start the process of testing the whole CPU. Furthermore, I want to get the PPU to display a background of any color, and if I have the time perhaps a valid background from some game.

Tess’ Status Report for 3/29/20

This week I worked with Adolfo on getting the CPU running. I finished coding the datapath with the parts that Adolfo finished coding and worked on polishing the ISA and signals files. To help our testing, I made a magic memory component for our test based on 18341 P6 magic memory.

While Adolfo finished the ALU and decoder, I started writing basic ALU testbenches.  This would make sure our timing was right, the correctness of our output values, and the correctness of our FSM. We plan on creating more unit tests for our components before using the test suite since it will be easier to control the debugging process with our own tests.

Additionally, I worked on writing the updated risk management plan and Gantt chart. I incorporated how we were going to use the unit tests and test suites to minimize debugging integration. The Gantt chart reflects us removing the audio portion, how we changed our division of labor, and schedule changes due to the transition period.

My goals for next week are:

  • Finish debugging the CPU
  • Incorporate interrupts