Identifying issue capturing data on write to Virtual 2315 Cartridge Facility

THE ISSUE I WAS INVESTIGATING

The Virtual 2315 Cartridge Facility (V2315CF) attaches to an IBM 1130 computer and works in conjunction with the internal 2310 disk drive of that computer. The disk uses swappable 2315 disk cartridges to record 512K words of data stored as 1,600 sectors of 321 words each. A word on the IBM 1130 is 16 bits long. 

The V2315CF allows mini cartridges to be used instead of actually reading and writing to a physical 2315 cartridge. The IBM 1130 sees the V2315CF system exactly as it sees the real 2310 drive, other than diverting data to stream on and off of the mini 2315 cartridge instead of the disk surface of the 2310 drive. 

When the 1130 writes a sector of data to the disk drive, the V2315CF should capture the stream of data and use it to update the sector in the RAM inside V2315CF, which will be used to update the mini 2315 cartridge (containing a microSD card to hold the data) when the virtual 2315 cartridge is unloaded at the end of a session. 

Currently the data is not recorded correctly in the RAM and thus the mini 2315 cartridge contents are corrupted for any sector where the 1130 wrote. In addition, the V2315CF checks the data that is coming from the 1130 to be written on the sector. At the end of each 16 bit data word, the 1130 sends four additional bits of error checking code that allow the 1130 to detect if a word is corrupted when being read from disk. Any time the 1130 reads a sector from a mini 2315 cartridge, the V2315CF generates valid ECC bits at the end of each word during transfer into the 1130. The 1130 will see the incoming data as valid. 

The V2315CF verifies that the data word and its ECC bits are valid during the write to a sector - data transfer from the 1130. If we see an error, we turn on a disk fault condition, make the disk drive appear to be not ready as far as the 1130 is concerned, and cease operation until the mini cartridge is unloaded. This should not happen. Somehow I am detecting an error, in addition to not producing a sector whose contents matches the data sent from the IBM 1130 during the write operation. 

REDESIGNED BASED ON CAPTURED LOGIC ANALYZER SIGNALS

I had spotted some reasons that my earlier approach wasn't working. Based on that, I redesigned the logic to be more reliable. Simulation suggested it would work, but of course the proof is in the pudding - I have to test with actual hardware to be sure it works as intended. 

At the same time, I implemented the 90 second wait when the disk powers up in the Raspberry Pi Pico code, rather than in the FPGA where it had been previously implemented. Once the mini cartridge image has been read and loaded into RAM, if the drive is in virtual mode, then the system loops for 90 seconds before it continues to consider the cartridge loaded and make the disk drive ready. 

Having this in the FPGA meant that I had to count to 90 seconds, making use of a pulse I emit once each microsecond for timing purposes. That means I had to count to 90 million, requiring 28 D flipflops and an adder with carries wide enough for a 28 bit integer. This is what pushed the count of required logic elements over the capacity of the Lattice FPGA chip I was using. By moving this to the PICO software I freed up those logic elements and had room left for all the functionality I needed in the FPGA. 

OBSERVATIONS WITH THE LOGIC ANALYZER AND OTHER TOOLS

The logic analyzer captured the signals used by the IBM 1130 to write the sector to the disk drive - -Write Clock Phase B and -Write Clock and Data. It also is triggered by the activation signal to the disk drive -Write Gate and records the output of the V2315CF where I emit the bit value detected when I am capturing each bit. Finally I output a diagnostic signal I can use to track how well my logic is accomplishing the goal of grabbing the data sent by the 1130. 

In addition to the logic analyzer, I have other tools. I can read the sector from the mini 2315 cartridge using a utility tool and programs I provide along with V2315CF. When I write from the 1130 to a sector and then unload the mini cartridge, that new data is inside the mini cartridge. Reading it with my utility programs gives some evidence of what was placed into RAM. 

I had read in sector 0 of the mini cartridge then changed the first few words of the sector in 1130 memory before doing a write of the memory back to sector 0. This should cause the mini cartridge, after being unloaded, to have the original data except for the few words I modified which should capture the values I entered.

It is not working correctly. What I see from the logic analyzer trace is that it is not detecting the sync word, so it starts decoding the words much too late. Below is the entire sector, where the last horizontal line is the 1 bit detection output I created for diagnosis purposes. It should start about 435 microseconds into the 10 millisecond sector, but as you can see it waits until almost halfway through the sector before it begins detecting. 

Here is the sync word coming in from the 1130 but not being detected by my logic. With inverted logic, the third signal line has the clock interval when it is low and the data interval when it is high. The second line is the combined clock and data signal from the 1130, where a low means the bit is 1. There is always a 1 bit in the clock interval (the second line is low at that time), but during the data interval we have a 1 bit for data only if the second line is low. 

The circled area is where the sync word is generated by the 1130. The data bit values are listed in yellow below the data intervals. We see data bit values of 1 1 1 1 and 0, which is the pattern that is the sync word. There was no capture of the 1 bit values in the fourth line, but it should be emitting them. 

A CLUE COMES FROM WHEN THE 1 BIT DETECTOR PULSES START

The diagnostic output signal I captured in the fourth row should be produced as soon as the logic considers the sector to have started. It watches the data stream until it sees the sync word pattern, which will show up in the fourth line as well. That triggers the collection of the 321 words of data for the sector. 

I now suspect that the defect is related to the sector marker pulses. The disk drive generates eight such pulses in a rotation of the disk platter, but the disk hardware hides every other pulse so that the 1130 only sees four sector marker pulses, corresponding to four sectors of data held on a rotation of the disk. 

My state machine that handles a disk write waits to see a sector marker pulse to end before it begins the writing logic. The 1130 asserts the -Write Gate signal low, which begins writing the sector. I suspect that when I see that signal asserted, I have missed the edge of the -Sector Mark pulse and therefore my logic waits until the next pulse halfway through the sector before it starts looking for the sync word. 

I will look at this, simulate it and change the logic so that it is not skipping the first half of the sector. I am hopeful that this will resolve the issue, but will have to wait for a couple of days because I am tied up all day tomorrow at Disneyworld and then guiding friends through the Kennedy Space Center Visitor Center on Friday.