Rescue 1130: 2014 Pickup of an IBM 1130 System and More

DIABLO 31 WITH STANDARD DENSITY IS COMPATIBLE WITH IBM 1130 DISK DRIVE

The Diablo disk drive accepts 2315 style cartridges and was used on a range of minicomputer and microcomputer systems. Evolved from technology licensed from IBM from the design for the 2310 and 1130's 13SD disk drive, most shipments used high density ceramic heads and wrote at twice the rate of the 13SD. 

However, Diablo provided a single density version with a chrome plated metal head identical to those on the 13SD and therefore the drive would compatibly read and write cartridges for an 1130 system. The electrical interface was not compatible, just the bit rate, track width, track spacing and sector pulse specifications that allow the signal on the disk platter to be identical. 

MINE CAME WITH CRASHED HEADS WHEN I PICKED UP MY 1130 SYSTEM

When I picked up my personal IBM 1130 system, it came with a frame with a Diablo 31 single density drive inside, plus a controller to use it with the 1130. In addition, the frame supported a third party line printer. The heads had previously crashed, being all scratched up and unsafe to use again. 

The disk heads on this generation of disk drive technology are available in very limited quantities from sources such as eBay, but only in the high density form that is not compatible with the 1130 cartridges. In more than a decade, with searches set up on eBay and many independent searches, I only found one head of the single density metal type. Therefore my Diablo sat on the shelf waiting for a future acquisition of heads. 

RECENT ARRIVAL OF 2302 DISK ARMS PROVIDES SOURCE OF GOOD HEADS

The heads for the 13SD were the same as the heads used on the 2311 and other 360 disk drives, including a rather rare device, model 2302, that did not have interchangeable media like the 2310, 2311 or 2314. Although the platters were fixed, the heads moved on arms unlike the 2305 drum that had each head fixed in place over its track. 

I was given a set of arms from a 2302, each of which has two disk heads on it. These were identical to the heads I need for the IBM 1130 and they were in good clean condition. The entire arm is completely incompatible, but the head portion mounts onto an arm via two screws. This allows a common head type to be used on 2302, 2310, 2311 as well as Diablo 31 standard density. 

The picture above shows the Diablo 31 disk head on the top and two heads from one arm of the 2302 arms below it. You can see the portion of each arm that is the interchangeable head assembly in the picture below, marked with a red rectangle. The screws that mount this interchangeable head onto the specific arm for a disk drive type are circled in green.

DISK FILE FORMATS FOR USE WITH THE VIRTUAL 2315 CARTRIDGE FACILITY

The IBM 1130 Simulator(s) use a version of the simh disk format which stores each word as two bytes in little endian 8086 format. Each sector is 321 words of 16 bits on the 1130, thus 642 bytes in the disk file. These are stored sequentially in the file, sectors 0 to 3 within each of the two heads, within the 203 cylinders. Thus cylinder 1, head 0 sector 0 begins at byte 5,135 in the file. The entire file is 1,042,608 bytes in size.

The Virtual 2315 Cartridge Facility has a header with information about the cartridge followed by the data in big-endian format. The data is sector 0 to 3, within heads 0 to 1, within cylinders 0 to 203. The header is 365 bytes long and the entire file is 1,042,973 bytes in size. Thus, cylinder 1, head 0, sector 0 begins at byte 5500 in this type of file. 

FINDING THE SECTOR DATA FOR CYL 10, HEAD 1, SECTOR 2

Opening the IBM 1130 Simulator format disk file, I calculated the start location for Cylinder 10, Head 1, Sector 2 which is the data I emitted in the debug log when testing the system. This starts at byte 55,212 which is hex 0xD9A0. Below is a hex editor showing the contents of locations 0xD9A0 to 0xDA2D so that we can compare it to the debug log. 

THE DATA MATCHES UP

The only conversion needed when comparing these is to swap the two bytes of each word in the sector, since the file I dumped is in little-endian integer mode while the Virtual 2315 Cartridge Facility implements big-endian integers as does the IBM 1130 hardware. 

The first two words from the dump are 5600 and 2461. The debug log shows these are 0056 and 6124. The final word of the dump is 204C and the final word from the debug log is 4C20. 

THE TEST

I set up the logic to pretend that the disk drive goes ready and stays that way for almost two minutes, then drops File Ready status. I instrumented various print statements to watch on the serial terminal (debug console). 

I turned on the unit and waited for it to initialize. I then flipped the Load/Unload switch up to the Load position where I saw the code open the virtual 2315 cartridge file and purportedly download the contents to the FPGA to be stored in the SDRAM chip. I displayed the individual bytes being transferred for a specific sector (cylinder 10, head 1, sector 2). 

After the time limit expired, I expected to see the Ready light go out but the box remain loaded until I flipped the Load/Unload switch down to Unload. At that time, it should rewrite the cartridge image file on SDcard with the contents of SDRAM as pulled up from the FPGA. After that completed it would return to its idle condition until a cartridge image was loaded again. 

ANOMALIES I OBSERVED

First, during the entire time that the image was loaded, the SEEK lamp remained lit. In my design this should only flicker when a seek is requested by the IBM 1130 controller. However, lamp was originally labeled On Cylinder in the RK-05 code; because the FPGA side is still running the original code, that might explain the lamp. Otherwise, the FPGA is continually executing seeks. 

Second, when the time limit expired and the File Ready lamp extinguished, I immediately saw the unit rewriting the cartridge image back to SDcard although the Load/Unload switch remained in the Load position. Something is not working as I expected here.

Third and most serious, the bytes printed for loading SDRAM don't match the bytes printed when retrieving the data from SDRAM. Initially it appeared that the test failed, but I did see that the exact same stream of bytes is returned on every rewrite, even with power cycling between tests. This means that the data is consistently written and read back but somehow I am not displaying it correctly. 

FIXES FOR MOST ANOMALIES AND RETEST

I ignored the Seek lamp since in a few days I will be running with my version of the FPGA code, when this becomes worth chasing.

I found code I inherited from the original RK-05 Emulator code where the Pico treated the Load/Unload switch as being in Unload while in the run state RLST10 - the normal running condition. Instead, I need to see the actual value since my code will drop ready but wait before writing back until the Load/Unload switch is physically manipulated. 

I altered my instrumentation to display the sector at Cylinder 10, Head 1 Sector 2 in a way that should be consistent on both load and unload. 

The retest went much better. I did indeed see the same data consistently, both when downloading it to the FPGA/SDRAM and when uploading it from there as the virtual cartridge was unloaded. The state machine did wait for me to manually flip the Load/Unload switch to Unload, exactly as it should. 

This first log output is the startup of the Virtual 2315 Cartridge Facility, before I switch to Load.

This log output below shows the loading of the virtual cartridge image from when I switch to Load until the process is complete. It includes a dump of the bytes for Cylinder 10, Head 1, Sector 2 as a means of validating the ability to move data into and out of SDRAM. 

Switch toggled from UNLOAD to LOAD
  Drive_Address = 0, RLST1, 1, 0
Card present, microSD card detected
  DISPLAY STATUS: "microSD", "detected"
  Drive_Address = 0, RLST2, 1, 0
filesystem started
  DISPLAY STATUS: "filesystem", "started"
  Drive_Address = 0, RLST4, 1, 0
file_open_read_disk_image
sd_spi_go_low_frequency: Actual frequency: 398089
V2-Version Card
R3/R7: 0x1aa
R3/R7: 0xff8000
R3/R7: 0xc0ff8000
Card Initialized: High Capacity Card
SD card initialized
SDHC/SDXC Card: hc_c_size: 121811
Sectors: 124735488
Capacity:    60906 MB
sd_spi_go_high_frequency: Actual frequency: 12500000
Disk image file is open
  DISPLAY STATUS: "image file", "is open"
  Drive_Address = 0, RLST5, 1, 0
Reading image file header
Reading header from file '2315.dsk'
controller = 1130 internal disk controller
bitRate = 720000
numberOfCylinders = 203
numberOfSectorsPerTrack = 8
numberOfHeads = 2
microsecondsPerSector = 10000
Image file header read successfully
Reading disk image data from file
  DISPLAY STATUS: "Reading", "image data"
  Drive_Address = 0, RLST7, 1, 0
Reading disk data from file '2315.dsk'
  1130 internal disk controller
 cylinders=203, heads=2, sectors=8
  cylindercount = 0
  DISPLAY STATUS: "Read card", " Cyl 0"
  DISPLAY STATUS: "Read card", " Cyl 10"
address for c10 h1 s2 is ac00
loading for sector c10 h1 s2
00
5661 246d 0000 78c0 f34c 207c 5865 807a 2469 22c1
0018 01e0 2990 294c 187c 5890 1c48 2090 1b48 2090
1a48 2090 1948 2090 1848 2090 174c 187a 7090 154c
207a 586c 007c 6f70 1b65 807a 61c1 0018 02e0 0cd0
0175 0000 0070 dd00 00f8 003c 00dc 0030 00fc 0030
0008 0001 ff00 0b7c 0008 0000 0000 0000 0010 10d4
007c 6fd0 fbd4 007c f969 0167 0000 00c3 0048 0473
0118 01e0 ed90 2e4c 207a b7c3 0190 2b4c 207a b7c3
0290 284c 207a b773 01c3 0390 294c 187a b790 214c
207a 94c0 00d0 2170 f590 1c4c 207a 99d0 1c70 f090
184c 207a 89c0 174c 207a 89c3 0490 154c 187a a690
0f48 2070 e3c0 89e8 8a4c 207a b762 324c 007b 4718
00ae 24c5 17ff ef00 1000 0e02 0000 0000 1ee8 0071
01c1 0048 1070 0271 0170 fb94 007c fb48 2070 06c0
ab4c 207c fc71 014c 007a 3ec1 0090 a14c 187a cc70
efc0 a24c 187a d569 9ec0 9d94 007c 624c 187b 4671
ffc1 0048 0870 fc6d 007c 6210 1062 05d6 007c 6872
ff70 fc62 05d6 007b 2072 ff70 fcd4 007d 2a71 01d0
40d4 007d 2bd4 007c 6844 007d 2d94 007b 16d0 224c
187b 714c 087a fa90 1f4c 087b 2bc0 264c 207b 01c0
1790 194c 187b 78c0 204c 207b 08c0 1090 134c 187b
7ec0 1a4c 187b 89c0 0990 0d4c 187b 1390 0b4c 207b
8968 11d0 0f70 d900 0000 3000 09ff dbff d5ff de00
1200 6400 c000 0100 0500 0000 0000 0000 0000 0000
0000 0000 0a00 00a0 0800 00c0 f64c 207b 3868 f6c0
e544 007d 63c0 ee4c 187a ee74 017b d670 b6c0 eda0
ed10 9080 d9d0 e910 10d0 e4c0 e690 db4c 107b 4674
017b 2070 a862 176a e065 807a 61c1 0018 02e4 007a
6984 007a 61d0 0166 0000 00c4 007a 2590 fcd0 0167
0000 0073 01c1 00e0 c2e8 ccd1 00f0 bf4c 047b 6480
bdd1 0071 01c0 c3d1 01c2 00d1 0272 0171 0173 ff70
fa71 016d 007a 254c 007a 58c0 b04c 207b 38c0 b04c
20
  cylindercount = 20
  DISPLAY STATUS: "Read card", " Cyl 20"
  DISPLAY STATUS: "Read card", " Cyl 30"
  cylindercount = 40
  DISPLAY STATUS: "Read card", " Cyl 40"
  DISPLAY STATUS: "Read card", " Cyl 50"
  cylindercount = 60
  DISPLAY STATUS: "Read card", " Cyl 60"
  DISPLAY STATUS: "Read card", " Cyl 70"
  cylindercount = 80
  DISPLAY STATUS: "Read card", " Cyl 80"
  DISPLAY STATUS: "Read card", " Cyl 90"
  cylindercount = 100
  DISPLAY STATUS: "Read card", " Cyl 100"
  DISPLAY STATUS: "Read card", " Cyl 110"
  cylindercount = 120
  DISPLAY STATUS: "Read card", " Cyl 120"
  DISPLAY STATUS: "Read card", " Cyl 130"
  cylindercount = 140
  DISPLAY STATUS: "Read card", " Cyl 140"
  DISPLAY STATUS: "Read card", " Cyl 150"
  cylindercount = 160
  DISPLAY STATUS: "Read card", " Cyl 160"
  DISPLAY STATUS: "Read card", " Cyl 170"
  cylindercount = 180
  DISPLAY STATUS: "Read card", " Cyl 180"
  DISPLAY STATUS: "Read card", " Cyl 190"
  cylindercount = 200
  DISPLAY STATUS: "Read card", " Cyl 200"
Disk image data read successfully
  DISPLAY STATUS: "Image data", "read OK"
  Drive_Address = 0, RLST8, 1, 0
Disk image data read, file closed successfully

The final log output shows the process of rewriting the cartridge data to the virtual cartridge file after I switched to Unload until the write is complete. 

Requested unload

  Drive_Address = 0, RLST11, 0, 0

file_open_write_disk_image

sd_spi_go_low_frequency: Actual frequency: 398089

V2-Version Card

R3/R7: 0x1aa

R3/R7: 0x40ff8000

R3/R7: 0xc0ff8000

Card Initialized: High Capacity Card

SD card initialized

SDHC/SDXC Card: hc_c_size: 121811

Sectors: 124735488

Capacity:    60906 MB

sd_spi_go_high_frequency: Actual frequency: 12500000

finished file open for write, code 0

Disk image file is open

  DISPLAY STATUS: "Image file", "open"

  Drive_Address = 0, RLST12, 0, 0

Writing header to file '2315.dsk'

Disk image header written

  DISPLAY STATUS: "Writing", "image data"

  Drive_Address = 0, RLST13, 0, 0

Writing disk image data to file '2315.dsk':

 cylinders=203, heads=2, sectors=8

  cylindercount = 0

  DISPLAY STATUS: "Write card", "Cyl 0"

  DISPLAY STATUS: "Write card", "Cyl 10"

retrieval address for c10 h1 s2 is ac00

fetching for sector c10 h1 s2

00

5661 246d 0000 78c0 f34c 207c 5865 807a 2469 22c1

0018 01e0 2990 294c 187c 5890 1c48 2090 1b48 2090

1a48 2090 1948 2090 1848 2090 174c 187a 7090 154c

207a 586c 007c 6f70 1b65 807a 61c1 0018 02e0 0cd0

0175 0000 0070 dd00 00f8 003c 00dc 0030 00fc 0030

0008 0001 ff00 0b7c 0008 0000 0000 0000 0010 10d4

007c 6fd0 fbd4 007c f969 0167 0000 00c3 0048 0473

0118 01e0 ed90 2e4c 207a b7c3 0190 2b4c 207a b7c3

0290 284c 207a b773 01c3 0390 294c 187a b790 214c

207a 94c0 00d0 2170 f590 1c4c 207a 99d0 1c70 f090

184c 207a 89c0 174c 207a 89c3 0490 154c 187a a690

0f48 2070 e3c0 89e8 8a4c 207a b762 324c 007b 4718

00ae 24c5 17ff ef00 1000 0e02 0000 0000 1ee8 0071

01c1 0048 1070 0271 0170 fb94 007c fb48 2070 06c0

ab4c 207c fc71 014c 007a 3ec1 0090 a14c 187a cc70

efc0 a24c 187a d569 9ec0 9d94 007c 624c 187b 4671

ffc1 0048 0870 fc6d 007c 6210 1062 05d6 007c 6872

ff70 fc62 05d6 007b 2072 ff70 fcd4 007d 2a71 01d0

40d4 007d 2bd4 007c 6844 007d 2d94 007b 16d0 224c

187b 714c 087a fa90 1f4c 087b 2bc0 264c 207b 01c0

1790 194c 187b 78c0 204c 207b 08c0 1090 134c 187b

7ec0 1a4c 187b 89c0 0990 0d4c 187b 1390 0b4c 207b

8968 11d0 0f70 d900 0000 3000 09ff dbff d5ff de00

1200 6400 c000 0100 0500 0000 0000 0000 0000 0000

0000 0000 0a00 00a0 0800 00c0 f64c 207b 3868 f6c0

e544 007d 63c0 ee4c 187a ee74 017b d670 b6c0 eda0

ed10 9080 d9d0 e910 10d0 e4c0 e690 db4c 107b 4674

017b 2070 a862 176a e065 807a 61c1 0018 02e4 007a

6984 007a 61d0 0166 0000 00c4 007a 2590 fcd0 0167

0000 0073 01c1 00e0 c2e8 ccd1 00f0 bf4c 047b 6480

bdd1 0071 01c0 c3d1 01c2 00d1 0272 0171 0173 ff70

fa71 016d 007a 254c 007a 58c0 b04c 207b 38c0 b04c

20  cylindercount = 20

  DISPLAY STATUS: "Write card", "Cyl 20"

  DISPLAY STATUS: "Write card", "Cyl 30"

  cylindercount = 40

  DISPLAY STATUS: "Write card", "Cyl 40"

  DISPLAY STATUS: "Write card", "Cyl 50"

  cylindercount = 60

  DISPLAY STATUS: "Write card", "Cyl 60"

  DISPLAY STATUS: "Write card", "Cyl 70"

  cylindercount = 80

  DISPLAY STATUS: "Write card", "Cyl 80"

  DISPLAY STATUS: "Write card", "Cyl 90"

  cylindercount = 100

  DISPLAY STATUS: "Write card", "Cyl 100"

  DISPLAY STATUS: "Write card", "Cyl 110"

  cylindercount = 120

  DISPLAY STATUS: "Write card", "Cyl 120"

  DISPLAY STATUS: "Write card", "Cyl 130"

  cylindercount = 140

  DISPLAY STATUS: "Write card", "Cyl 140"

  DISPLAY STATUS: "Write card", "Cyl 150"

  cylindercount = 160

  DISPLAY STATUS: "Write card", "Cyl 160"

  DISPLAY STATUS: "Write card", "Cyl 170"

  cylindercount = 180

  DISPLAY STATUS: "Write card", "Cyl 180"

  DISPLAY STATUS: "Write card", "Cyl 190"

  cylindercount = 200

  DISPLAY STATUS: "Write card", "Cyl 200"

Disk image data written

  Drive_Address = 0, RLST14, 0, 0

Disk image data write, file closed successfully

WAITING FOR MY FPGA PROGRAMMER TO ARRIVE IN THE MAIL

Ebay and other sites are awash with clones from China for the Lattice programmer, but either have the usual delays waiting for overseas transport or they came with a healthy 'scalper' premium from sellers who kept them in the US. Further, others who offered them locally didn't ship particularly promptly as it appears they order from China to fulfill. 

I stepped up and purchased from Lattice directly - at a considerable premium over the clones - which was to be fulfilled by Mouser. I paid for two day UPS shipment when I ordered it on Saturday, but the order wasn't marked as shipped until today (Tuesday) and UPS states it is not yet in their possession.

Thus best case is Thursday delivery but that is only if Mouser hands it over to UPS before their cutoff today, otherwise my 2 day order will arrive Friday or later. If I wasn't eager to debug further with functions that require my code in the FPGA, it wouldn't be worthy of mention. 

I will program the FGPA once I have the gear in hand and run through more checks to verify how it interacts with the Pico code. I am getting much closer to testing with a real hookup to the IBM 1130 and its 13SD internal disk drive. 

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. 

SERIAL DEBUGGER LINK CONNECTED, CODE IN PICO AND NEW DISK IMAGE ON CARD

I had the modified RK-05 Emulator hardware set up in my lab with a serial USB connection placed on the debug UART pins. A microSD card with a valid 1130 disk image was inserted in the card reader. The Pico had been reprogrammed with my Pico code that I need to test. 

The only part not yet updated was the FPGA, as I was waiting for the Lattice programmer that I apparently need to load its proprietary bitstream into the FPGA chip over the JTAG interface. I hoped that I could get some preliminary testing done before I have the programmer which should arrive by Wednesday. 

POWER UP WITH CARD INSERTED BUT LOAD SWITCH LEFT OFF

I was expecting the box to power up with a drive number (0) displayed in the small OLED screen, although there could have been some issues reported by debugging print statements such as a mismatch of FPGA version number. 

However, the OLED remained blank. All I saw on the serial terminal was the first print showing that the emulator was starting up. I didn't see the messages that should occur while it initializes the SPI links to the SD card reader as well as starts up the FPGA. 

To determine where exactly it was stalling, hopefully pointing me at the fault, I put in quite a few more diagnostic print statements. They showed me that it got mostly through the initialization of the GPIO (I/O pins that drive LEDs and other functions from the Pico) but seemed to be locked up after a couple of SPI calls to the FPGA. 

I am diving in with more detailed diagnostic information, although this could simply be a consequence of the mismatched FPGA code. It isn't immediately obvious to me how it would stall but I will find out.

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. 

COMPARING V1 AND V2 OF PICO CODE TO DETERMINE DIFFERENCES

I used WinMerge to check the code from both the original and latest versions of George Wiley's RK-05 Emulator on github. I found changes in

• RK05_emulator_V00.cpp (main program)
• disk_definitions.h
• emulator_command.cpp
• emulator_hardware.cpp
• emulator_hardware.h
• emulator_state.cpp
• microsd_file_ops.cpp
• _software_licenses.txt to be included with derived products

These mainly involve two areas - a new format for the files used on the MicroSD card and changes to the tester and debugging interfaces. There is also the addition of the explicit file describing the MIT license granted by the maker of the SSD1306.C and SSD1306.H code that was included in George's emulator and thus in my design. 

REQUIREMENT TO ADJUST MY CODE BASED ON THOSE CHANGES

My design does not have a tester mode, unlike the RK-05 Emulator which can connect one unit to another so that the tester unit drives the tested unit through its paces. There was also quite a bit of instrumentation such as serial log output and debugging signals that were included in George's design. I don't make any use of the debugging signals so the V2 code changes for these areas are irrelevant.

George developed an elegant flexible way of using his emulator with a variety of systems, supporting different disk formats, densities and other parameters. These were embedded in a header on each virtual cartridge file, but in V2 some of the parameters were communicated by two prefix words in each sector on the file. 

I had already substantially reworked the virtual cartridge file format and hardcoded the parameters that match the 2310 disk drive. Therefore I didn't make use of the information that supports flexible disk types, and considered the changes for this irrelevant.

The header designed by George contains a version number and a magic number, along with the various parameters being communicated. I created my own version number and modified the magic number. Because of this, I also changed the file suffix to be used on the microSD card. George used .rk05 in version 1 but switched to .rke for V2. 

I instead picked .dsk which is the type of suffix used with the IBM 1130 Simulator too, although the files are not directly compatible. One change in V2 was the addition of a Board Version in the file header, which specifies the minimum revision of the RK-05 Emulator hardware needed for this disk file. My design does not depend on the new board version (mainly because it supported the larger max sector count in V2), but I did include that field in the file header. 

Because of this, the changes to my Pico code were quite modest - interrogating the FPGA board number, handling the new field in the microSD card file headers, and a couple of minor message changes. 

TESTBED BEING READIED TO VALIDATE THE BEHAVIOR

I have a Pico and breakout board arriving this weekend which will allow me to hook up a microSD card reader and eventually a test driver Arduino. In this way, I can insert a card with a virtual cartridge image and validate that the Pico code correctly interprets it and sends the proper SPI transactions that the FPGA would need to load and unload that from SDRAM.

Further, I can test out the startup and shutdown logic which uses SPI messages to watch the state of the FPGA. When the Pico sees the Load/Unload switch activated, it mounts and reads the cartridge file. It transfers the contents down to the FPGA via over one million SPI messages. The Pico code will watch the state of the FPGA via SPI messages until it sees the File Ready signal turned on. 

Some of the lights on the emulator are driven by the Pico code, which interrogates the state of the FPGA for conditions like File Ready, seek active, read active or write active; others are set by the Pico code, such as Ready Only. I can drive these from Arduino and sample the LED output pins the same way.