Spring Break Shennanigans

I made some progress with the GameTank Porting. I rewrote the block diagram after some reflection (see below).

I realized that instead of generating the the 3.5 and 3.5*4 MHz clock signals for the main and ACPU, I can have the base 100 MHz clock generated by the FPGA and pass a periodic enable signal. This lets me avoid CDC issues at the slight downside that the ACPU clock cannot have a 50 percent duty cycle (which I am OK with).

I also made some hacky UART debugging module to halt the entire system and examine memory addresses and CPU registers. I managed to implement and test each of the individual modules in the block diagram in isolation. I ran some integration tests in cocotb simulation, testing the video circuit, the CPU read/write access, the write back loop which muxes all of the devices together and zeros out the data from devices which are not the target device, the "manager" blocks which turn incoming r/w requests into No-OPS if needed.

I also emulated the external devices which need to connect to the bus (namely the gamepad controllers and the various game cartridges).

I've also made some live board tests to make sure that everything holds up in hardware; I'm running into issues with the blitter copying.

I have two options to actually build the system: one is making my own circuit board to interface with the IRL external components (as well as hold the entire sprite RAM, since there aren't enough BRAM blocks to hold everything). The second is to port things over to the misterFPGA; this would require porting the memory interface to use DDRAM instead (which would include non-deterministic memory access) or use SDRAM (which would force people to buy the $50 add-on board). I'm leaning towards the 2nd option with DDRAM, but I'm dragging my feet a bit on reworking the memory access patterns.