Quicker first tests of Pico code for Virtual 2315 Cartridge Facility

CODE BASE HAS DEBUG PRINT STATEMENTS ON SERIAL LINK

George Wiley sprinkled his code liberally with print statements to a serial communications link on a UART that is not used in normal operation. Thus, by connected a USB serial cable to the RK-05 Emulator hardware, the operation of the code is easy to track on a terminal recording the output. 

I left all of those debug statements in the code, although I didn't add any specific to my functionality (yet). I can download the software onto the Pico on the hardware box, hook up a USB link and verify quite a bit of the logic without worrying about the testbench I was preparing to capture the high speed SPI messages. Later I can use the Arduino to validate that the messages are as expected coming from my Pico code.

LOADING MY CODE INTO PICO OF THE RK-05 EMULATOR BOX AND INTO FPGA

Loading the Pico code is easy. Connecting a USB cable to the Pico before it is powered up will put it in load mode - the Pico appears as a disk drive to the system on the other end of the USB cable. I simply copy the code over that link to the Pico and it will boot up on the new code.

The FPGA is programmed with a bit of hardware that plugs into the JTAG connector on the board. JTAG is an industry wide protocol that is used to connect to and transfer data with FPGAs and PROMs of various types. I run the IceCube2 toolchain that I had used to build the bitstream, opening the programmer hardware that was connected by USB to my computer, then downloaded the bitstream. 

FIRST TESTS WITHOUT SUBSTANTIAL TESTBED INVOLVEMENT

I can see the code start up including verifying that it can talk with the FPGA via the SPI link. The versions must be compatible because the code changes version numbers returned from the FPGA and sent down by the Pico. 

When I turn the Load/Unload switch to Load, the code should read the microSD card, find a file with a .dsk suffix and open it for reading. Fields in the header are checked to validate the file. The code should then transfer the contents of the file to the FPGA via SPI messages (over a million will be sent), that loads the file contents into the SDRAM in the box. The final step is an SPI message to indicate cartridge content ready to the FPGA. 

Switching the Load/Unload back to Unload should cause the contents of SDRAM to be fetched via another million-plus SPI messages and written back over the file. If all worked well, the updated file should match the original exactly since no writes from an IBM 1130 would have occurred. 

Unloading will not work after the contents are loaded until the FPGA side declares the disk ready for access, which moves the Pico state machine to its running state. Only in the running state will the box look at the Load/Unload switch. To make the disk appear ready, I believe I will just have to ground one line - BUS_FILE_READY_DISK_L - which is how the disk drive itself reports that the heads are successfully loaded and it is ready to go.