SOLVED STARTUP ISSUE DISCOVERED YESTERDAY
The problem from yesterday was caused by residual code I had modified that tried to send an SPI message to the FPGA to clear the fault latch. Since the SPI link and the FPGA were both uninitialized at the time, this hung the Pico. The state upon startup for both FPGA and the Pico is to have the fault clear anyway, so I simply removed the code.
I may have to make changes to turn on a fault if the cartridge loading in the Pico encounters an error, because the fault latch should block any access to the drive from the IBM 1130.
WATCHED SYSTEM FULLY INITIALIZE
From the point that the startup was failing yesterday, it initialized the SPI links, initialized the FPGA and set up the OLED display. The goal was to wait in the idle state, with a phony drive number visible on the OLED screen, waiting for the Load/Unload switch to be moved to the Load position.
It did complete the startup as you can see from the terminal screenshot below, however, some code I changed caused a problem at that point. Whenever the Pico is idle (cartridge not loaded) the original emulator code threw up a large numeral indicating the drive number of this virtual disk drive. I wanted to change it to display a bitmap image of a disk platter or cartridge - limited by the small resolution and lack of color of the installed OLED display.
LOOPING ERROR MESSAGE TRYING TO LOAD BITMAP IMAGE
My code did not use the SD card code that mounts the card as a VFAT file system and does I/O, instead using code from previous programs running under Linux where the standard file I/O support existed. This led to an error on the attempt to open the file.
The SD card is opened, mounted and a file searched for only when the Load switch is activated. It is possible for me to do a similar set of actions when the image is going to be displayed in the idle condition, but there is the risk of conflict if the Load switch is closed just as I begin to open the card for the bitmap
For the time being, I disabled the attempt to throw up the image, leaving the splash screen which displays Virtual 2315 Cartridge Facility. If I want a bitmap to be displayed during idle time, I will have to work on an alternate method such as including the bitmap in the code itself. Further, with the screen only 80 x 40 pixels in black or white, there isn't much meaningful I could show.
IGNORING THE LOAD SWITCH
The next issue in debugging was that it ignored the load/unload switch being turned to Load. After a quick examination of the code, it was because the FPGA was not returning a 1 bit indicating that the drive was unlocked and ready to receive a (virtual) 2315 cartridge. I did a temporary bypass to continue testing.
 |
| Looping without trying to open cartridge file |
LOADED MY 2315 CARTRIDGE IMAGE VIA LOAD SWITCH
The logic when Load is activated will open the SD card reader link, open the VFAT file system, look for the first file with a suffix of .dsk, and open that file. Some checking is done to validate the file, then the logic will read the file and write its disk data over the SPI link to the FPGA in order to get the data into the SDRAM.
The load began but partway through reading (and downloading to FPGA) an I/O error was encountered. I instrumented the code in order to figure out why this is happening - it looks like something is doubled up so that about halfway through the file we run out of data.
The instrumentation made it immediately clear that I was reading twice as many sectors per track as exist on the file. This is an artifact of the 2310 drive, which has eight sectors (generating 8 sector pulses) per rotation, but the controller combines them to treat the disk as having four logical sectors.
For much of the simulation, I need to account for the physical sector count, but not here where I am reading or writing the cartridge data. I divided the parameter in half for the read and write loops and retested.
Everything loaded properly. I couldn't try writing back the contents of SDRAM because my state machine is smart enough to know that if you load a cartridge but the disk drive never goes ready, then there is no need to write it back since nothing could have changed. This is the same path taken if the Read Only state is toggled on by the front panel switch at the time the load/unload switch is put back to Unload - the image on SD card is not updated.
TRYING TO FORCE A WRITE-BACK WHEN I UNLOAD
I made a temporary change to report the drive went ready, so that the state machine moved to the normal running state and from there an unload would lead to overwriting the file on SD card with the SDRAM contents.
When I turn the load/unload switch to Unload, it didn't unload. The logic requires that the disk drive be switched off, with File Ready turning off, before we unmount the data. This ensures that the 1130 does not do any further writing to the drive.
I might be able to do some more sophisticated patching to force the unloading to occur - somehow change what I report for ready status depending on where we are in the overall state machine - but it isn't a single line type of change.
The potential value of achieving an unload where we update the cartridge image on the SD card is that I could compare the two. If they are identical, then the data was preserved properly in SDRAM and however we are addressing it from the Pico, we get the same data we put in each location.
I am close to the end of the workday so this is something I will mull over until tomorrow.
No comments:
Post a Comment