UPDATES MADE TO LOGIC OF THE V2315CF
I made a few updates to the C code for the PICO and the Verilog for the FPGA of the Virtual 2315 Cartridge Facility (V2315CF) based on the prior day's testing. I had noticed that a completely valid sequence of steps did not perform in a way that makes sense. The state machine was changed to handle this in a more reasonable way.
The user inserts a mini cartridge containing an image of a 2315 disk cartridge on a microSD card inside the holder, plugging it into the V2315CF main box. The switch is set to Load which causes the V2315CF to read the contents into memory so that the 1130 can read and write to that just as if a physical 2315 disk cartridge had been inserted into the 1130's internal disk drive in an unmodified system.
A placeholder 2315 cartridge is inserted into the disk drive in the 1130, one which is only used to generate timing signals and provide realism. The run switch is turned on for the disk drive and it spins up. After about 90 seconds the disk drive believes it has loaded the read/write heads down to fly atop the surface of the disk platter inside the cartridge. The File Ready lamp lights on the 1130 console and on the V2315CF main box.
After accessing the disk by software instructions run on the 1130, the run switch of the drive is turned off. The File Ready lamp goes out and the drive slows to a stop. The Unlock lamp on the 1130 console lights, indicating that the 2315 cartridge could be removed and another inserted. If, however, we just turn the run switch back on, we should be able to continue using the virtual cartridge we loaded into the V2315CF just as we would continue to use a physical 2315 cartridge in an unmodified drive.
After the drive spins up and waits 90 seconds, the drive thinks it loads the heads and wants to turn on the File Ready lamp. However, it does not light, nor can we access the virtual disk from software. This does not make correspond to what happens with an unmodified 1130 and disk drive, where we could turn it on again and it would be ready for access. I had to unload the mini cartridge and reload it to get the V2315CF to start up the drive and make it ready.
When we load a mini cartridge into the V2315CF, the state machine sits (lets call this state W) waiting for the File Ready signal from the disk drive before it advances to turn on the File Ready lamp (call this state R) and allow access. My change was that when we had been in this second (R) state, but turned off the drive, the state machine returns to that first state (W) where it is only waiting for the drive to turn on File Ready.
I also removed the Schmitt trigger filter I used with the +Access Ready incoming signal, because that adds additional delay which may have been causing the 1130 disk controller logic to malfunction. That was one possible cause of the seek errors I was seeing - a seek of N cylinders sometimes moved only L cylinders instead, plus the V2315CF believed it had moved to cylinder L-1 instead of L where the arm actually stopped.
INSTALLED THE LOGIC ANALYZER ON THE DISK CONTROLLER LOGIC
I hooked up the 16 channel logic analyzer to key signals in the disk controller logic that might point me toward the cause of the seek anomalies. I watched the nine bits of the count register, as well as the signal to move the arm (-Access Go) and the feedback signals from the drive (+Access Ready and +Home). I also hooked the analyzer to the signal +Access Control generated during an XIO Seek instruction and the internal control signal -full_word_count that indicates the count register contains all ones.
When an XIO instruction requests a seek of N tracks from the current location, the value N is inverted and loaded into the count register. That is, every bit is inverted to form the ones-complement of the count from the XIO. The disk controller logic then sends -Access Go signals and bumps up the count register, taking steps of 1 or 2 tracks, until the count is complete because all nine bits of the count register are 1.
When the count N from the XIO instruction is an odd number, the low order bit of the count register has a 0 in it. This causes the disk drive to move only 1 track in the step (-10 Mil Step signal). As soon as the drive responds to the -Access Go about 5 milliseconds later with a drop of +Access Ready, the low bit is forced to 1. When +Access Ready returns to high, the count register has 2 added to it and -Access Go is again asserted to take the next step. This will always be a 2 track step. Only the first is 1 track and only when the count N is odd.
This restart of -Access Go is blocked when the count register is all 1s, causing the seek operation to complete. I will look at the interaction between -Access Go, +Access Ready, the 9 bits of the count register and the -full_word_count condition, which should proceed according to the rough timing of 5 ms for +Access Ready dropping and 10 ms after this, +Access Ready returning to high. -Access Go should go off when +Access Ready drops. The seek operation should not end until we have moved the full count N tracks.
A challenge with the logic analyzer is having enough recorded information to find the defect. The logic analyzer runs fast, but the timescale for a seek is glacial by comparison. Each step takes around 15 milliseconds so a seek of 200 tracks would span 1.5 seconds. The practical limit for recording in the 256MB buffer depends on the sampling rate and number of channels being recorded. For 16 channels being captured, at a sampling frequency F we will have 16/F seconds recorded.
To watch the signals based on nominal behavior, we have to catch signals that change in the neighborhood of once each 5 to 10 milliseconds. If I set the sampling frequency at 5MHz, then we record about 80 Mbits in a second; with a memory of 256Mbit to hold them I can capture about 3.2 seconds worth. PPPp
Using the rule of thumb that we should sample 10X the rate we expect signals to change, I should be able to see signals changing on the scale of 500KHz with a 5MHz rate. That corresponds to about 2 microseconds. I can't be certain to capture glitches that occur on a shorter timeframe with this recording rate, but I can certainly count the steps and validate the change of the count register.
If I see that weird things sometimes happen, with counts advancing too rapidly or the hint that the dance between -Access Go and +Access Ready is sometimes happening faster than the 15 ms we expect, I can increase the sampling rate and try some short seeks that still fit in memory until I have visibility of whatever is triggering the malfunction.
FIRST OBSERVATION FOR A SEEK OF 193 CYLINDERS
I set up the XIO with a seek count of 0xC1 which is 193 in decimal. It is an odd number as well as very long, where previously we had very repeatable failures to seek the entire distance. The logic analyzer set to 5MHz sampling can easily record the entire operation, triggered by the +Access Control signal that is generated as the XIO Seek instruction executes. I can store the contents of the data and use the DSView software to look at it.
The V2315CF agrees with the disk arm position, which is a significant improvement from last time. Unfortunately, the saved file from the logic analyzer didn't save enough to capture the end, so I couldn't count the seek steps to verify that it matched the seek count.
ZOOMING IN ON A SEEK OF 3 CYLINDERS
If I set the analyzer to the max rate for 16 channel recording of 100 MHz I can capture about 167 milliseconds of signals, good enough for a seek that should last a bit of 30 ms. If I want to just zoom in on the -Access Go and +Access Ready signal waveforms, plus the +Access Control trigger and the -full_word_count end signal, the analyzer can capture at 400MHz for the same 167 ms. That lets me see signals with good accuracy down to about 20 nanoseconds or two ticks of the FPGA main clock.
Again, due to my low familiarity with the DSView software that captured the trace, I didn't save enough duration to see the end of any of the small seeks. The only one that I was able to see in its entirety was a seek of 40 tracks, which the trace confirms that it issued -Access Go 20 times and I did verify that the disk arm was moved exactly 40 tracks.
I also don't have good traces for two signals, which I suspect means that I misconnected the two leads from the logic analyzer since the two missing ones are both on the same SLT card slot.
However, I did do some individual 1, 2 and 3 track seeks which did move both the disk arm and the V2315CF cylinder variable the correct amount.
ANALYSIS OF RESULTS
It appears that most of the issue I was experiencing was due to the Schmitt trigger filter which I removed from the FPGA logic. However, it was my impression that the disk arm stopped at around cylinder 161 when it should have ended at 193, but I am not certain.
I plan to go back to the workshop and more carefully record the signals including ensuring that the traces fully capture the entire duration of the seek command. I was triggering on the wrong signal to start as well. Stay tuned for the update, which will either confirm that the seek is fully corrected or help identify a remaining issue with long seeks.
DISK DRIVE ISSUE WHEN ATTEMPTING TO SEEK PAST CYLINDER 202
When I do a seek that attempts to move the arm past cylinder 202, the drive should keep the arm at the proper location and report completion. What I am experiencing is a steady buzz with the drive continually attempting to move the arm past 202. Even doing a system reset of the 1130 system does not stop that error. Since the reset will ensure that -Access Go is not asserted, it is an issue entirely inside the disk drive.
The drive has 'crash stops' fixed to block the arm from moving outward past cylinder 0 (Home) and from moving inward past cylinder 202. These are mechanical stops that are adjustable.
The electronics that moves the arm makes use of an integrator to add up the speed pulses from a tachometer on the arm. When the integrator gets to the preset trigger level, it shuts off the access go latch, turns off +Access Ready, which in turn causes the 1130 disk controller logic to return -Access Go to high.
In one document, it makes mention of a resistor that will charge the integrator if the arm is not able to move, due to the mechanical stops. It claims this takes about 40 milliseconds to turn off, longer than the 2.4 to 3.8 ms during movement that reaches the integrator trigger level. I don't see that 'resistor' in any of the other documents for the disk drive, but I will have to study the circuitry in detail to see if this is actually implemented. If it is implemented, then that charging path is defective, probably due to an open resistor.
I should do a test where I attempt to seek 2 tracks in reverse, starting at track 1, to see if the drive malfunctions in the same way. It may not, because the access go latch is turned off my reaching the home cylinder which turns on a microswitch. There is no such microswitch nor turnoff path for reaching cylinder 202.
The issue may be due to the crash stop being set incorrectly. There is a minimum gap between the stop and the arm when it is at cylinder 202, which might be far enough to let the integrator level reach the trigger point. If the space is too small or non-existent, the tachometer won't record enough pulses.
I can quickly check the spacing of the crash stop, but if that value is acceptable then I have to dive deeper. I suspect that the paths that charge the integrator are represented in the schematic below, as I have colored the paths to show my speculation.
When the forward direction is active, transistors Q19 and Q22 apply +48V (green) and ground (blue) across the voice coil in the proper direction. The resistor at the start of the red path has a voltage drop proportional to the current flowing in the voice coil. If the coil is stalled it should increase the current and therefore increase the voltage of the red line relative to ground. This voltage flows through a diode D1 thus it only acts to effect things if the voltage is above the voltage drop (about .3V for germanium) of the diode.
The red line is injected into the yellow path that runs to both transistors Q5 and Q6 of the integrator. Normally, the pulses from the tachometer will cause Q3 or Q4 to pulse the either Q5 or Q6 to drain energy from the capacitor C1 which is initially charged to +6V and pulled down by Q5 or Q6 towards -3V until the comparator triggers the reset of the accelerator go latch.
However, with no movement to pulse the tachometer, the voltage from the red line flows through the balanced resistors connected to transistors Q5 and Q6. If the balance of the yellow line is offset by current from transistor Q9 (pink) which is active when the -Access Forward line is low (asserted). This causes some current flow to discharge C1 albeit more slowly than if the tachometer pulses were driving Q5/Q6 actively.
I struggled to find a component that is not working properly for the injection from the red path, but works properly for normal forward and backward movements of the voice coil, other than diode D1. It would have to be a short circuit to stop the red voltage entering the yellow path. If the gap at the mechanical stop for cylinder 202 is too small to allow the tachometers to drain C1 far enough, then I will try to find diode D1 on the circuit board and test it.
