Testing my new seek logic for the Virtual 2315 Cartridge Facility - virtual mode

RETEST UNDER VIRTUAL MODE TO BE CERTAIN IT WORKS PROPERLY

I ran the same loop seeking in and out by the same number of cylinders, initially 200 then other values - to be certain that the Virtual 2315 Cartridge Facility (V2315CF) is handling seeks properly in virtual mode where the physical disk drive is not spun up. 

I detected two problems. First, my logic is sending the seek requests to the drive even though it isn't spinning, and to my surprise the solenoids that lock the arm into various positions were buzzing away. Second, when single stepping through the program, the V2315CF tracked the intended disk arm position properly, but when I ran at full speed, it got out of sync. 

BLOCKING SIGNALS TO THE DISK DRIVE WHEN IN VIRTUAL MODE

It was simple enough to fix the first issue. I don't emit the -Access Go, -10/+20 Mil, and -Rev/+Fwd to the disk drive while in virtual mode. The only things I emit concerning seeks are +Access Ready feedback and the state of the +Home signal, sending those to the IBM 1130 disk controller logic. 

LOOKING INTO HOW THE SEEK SHADOWING WORKS DIFFERENTLY IN VIRTUAL MODE

I looked over my logic to see where it performs differently and how that might lead to miscounting. The obvious spot was that in real mode, after I update the cylinder number at the time when +Access Ready goes low, I wait the approximately 10 milliseconds for +Access Ready to return to logic high before deciding that a seek step is complete. In virtual mode, I immediately ended the seek when I updated the cylinder address as +Access Ready went low. 

That opens a window for glitches on the -Access Go line from the 1130 to trigger a spurious seek step. I changed the logic to wait until the seek timer gets to zero - that is when I return +Access Ready to logic high and that is the equivalent wait I do in real mode. The only difference is that +Access Ready comes from the disk drive in real mode and is derived from a 14.5 millisecond seek timer in virtual mode. 

RETESTING WITH CHANGED FPGA LOGIC

I introduced those changes and fired up the V2315CF in virtual mode to run my program that seeks back and forth by 200 cylinders. I was looking for the internal drive to remain quiet - no solenoid activations - and for the cylinder address shadowed by V2315CF to match what the program was doing. I tried this with 200 cylinder seeks and then with a few shorter ones so that I could move between two positions that did not include the home cylinder (0). 

I observed that the +Access Ready signal is not pulled up to 3V, it is sitting down around 1.4V when logically high. This is confusing the logic in the V2315CF trying to shadow the movements. There are no terminator resistors on this line, but if I add the standard pair back, virtual mode works properly. The consequence of that is disabling real mode, because real mode couldn't get the signal down close enough to ground to register with the IBM 1130 disk controller logi as a logic low. 

Rather than use a pair of resistors, pullup to 5V and pulldown to ground, establishing a termination impedance, I just installed a weak (10K) pullup on the board. This appears to have solved the issue for both modes - real and virtual. 

Troubleshooting the logging function of the Virtual 2315 Cartridge Facility

DEBUGGING CAPABILITIES BUILT INTO THE V2315CF

The Virtual 2315 Cartridge Facility (V2315CF), built around an FPGA, a DRAM chip and a Raspberry Pi PICO, has a serial debugging output available that logs both status and error messages as the unit does its work. It has the capability to log each seek, read and write to the same serial port if I type the letter L into the serial terminal to request logging. 

The FPGA logic that processes read, write and seek operations emits a short pulse for each of those events. These are ORed together and output on an FPGA pin as CMD_INTERRUPT. That pin is routed to pin 6 of the PICO, which is general purpose IO (GPIO) 4. The FPGA is communicating with the PICO over an SPI link, driven by the PICO. 

The PICO is configured to call a routine when there is a rising edge on GPIO pin 4. That routine requests data from the FPGA over SPI and then issues a message on the serial port that indicates whether it was called due to a seek, a read, or a write, accompanied by the current cylinder, head and sector. 

LOGGING IS FAILING TO WORK

All the software in the PICO and the logic in the FPGA appears correct. It used to work a few months ago, but recently it does not. I put a oscilloscope on GPIO pin 4 (CMD_INTERRUPT). The line is steadily high, which is not correct. Without a rising edge, there will be not interrupt and the callback routine won't execute to log the status. 

The same logic that emits the pulses for seek, read and write also drives the indicator lamps RD, WT and SEEK on the V2315CF front panel. Those indicator lights work correctly! I don't know why the signal isn't working correctly into the PICO.

There are a few possibilities. I have already replaced the PICO so it is not that bit of hardware. There could be a short somewhere on the PCB that is driving CMD_INTERRUPT high in spite of it being logically low in the FPGA code. There could be a failure in the FPGA chip itself that is producing a high output incorrectly. There could be some weird Lattice toolchain issue causing the FPGA to not do what I coded. Or, there could be some other kind of unexpected gremlin.

QUICK MODIFICATION TO SEE WHICH OF THE THREE OPERATIONS ARE HIGH

If there is some flaw in the FPGA logic such that one of the lines - seek, read or write - that should be pulsed high temporarily is instead permanently high, I can at least narrow things down to which line is bad. I modified the FPGA and the PICO to add a new SPI transaction type which will return the seek, the read and the write status lines separately. The PICO will output that information periodically with its normal status message over the debugging serial link. 

What I observed was that my output indicated that all the signals were low inside the FPGA, thus the output from the FPGA should be low, however it was logic high continually. 

TRYING THE OTHER V2315CF UNIT

I am building two V2315CF units, one for the Infoage/Vintage Computer Federation museum and one for the System Source Museum. I therefore have two main units constructed. If I swap them on the 1130 I am debugging with, I can rule out FPGA hardware and motherboard trace issues, as the problem will only remain if it is a defect in the logic in the FPGA or the code in the PICO or the toolchain. If the problem disappears, I then need to do some detective work to identify the actual failing part. 

When I ran with the other V2315CF unit, logging worked perfectly. It is therefore an issue with the FPGA or the board traces. As this works well other than the logging, I wouldn't replace the FPGA to cure this, but if I spot something on the board that can be remedied I will.