Further research into the issue logging commands in one of the Virtual 2315 Cartridge Facility boxes

HAD NARROWED THE PROBLEM DOWN IN PRIOR SESSION

In the last session, I determined that the problem in the main box of the Virtual 2315 Cartridge Facility (V2315CF) was either in the Lattice FPGA chip on the board or in the path on the PCB between that chip and the Raspberry Pi PICO that receives the signal. It was always high, but should only blip high when a seek, read or write is being processed by the FPGA. The PICO chips are new and only one of the two boxes misbehaves like this.

I couldn't find any issue on the PCB thus my working theory is that a protective diode on the IO pin of the FPGA had shorted due to some overvoltage incident early in my testing and converted this pin to the equivalent of the 3.3V rail. I had decided earlier that it was not worth replacing the FPGA if that IO pin was damaged, since the remainder of the unit is working fine. 

WORKAROUND DESIGNED AND TESTED

There are a few IO pins on the FPGA that are not used in the V2315CF implementation. One of them is routed to a pad on the PCB, offering an option for some debugging output but not currently used. The PICO has a spare input pin (pin 5) that is connected only to a pad, again probably used in the past for diagnostic output. I added a wire between the two pads, so that the spare pin of the FPGA can drive the spare pin of the PICO. 

The FPGA logic was updated to mirror the signal that comes out of the damaged FPGA IO pin, delivering the same signal on the spare pin. I can use the spare pin of the PICO rather than the normally assigned pin to detect when a command is executed in the FPGA. The code that watches for rising edges to make a callback to log the commands needed to be watching pin 5, the previous spare, instead of pin 4 that is the normal command input from the FPGA.

During the startup code in the PICO, I read the normally assigned pin (4). If it reads as high, but we have not yet begun processing any commands for the 1130, then this is the unit with the bad FPGA pin. When requesting the PICO to trigger on rising edges, I set it to pin 5 instead of pin 4 and the box with the bad FPGA pin has logging restored. 

LOGGING SEEKS IS COMPLICATED COMPARED TO THE ORIGINAL RK05 DISK EMULATION

The DEC RK-05 disk drive handles seeks differently than the internal disk drive (2310) inside the IBM 1130. On the RK-05, the disk driver controller logic specifies a cylinder number as the destination, invokes the drive just once and receives confirmation once the arm has stopped at the target location. The 1130 system disk controller has to step the 2310 disk drive iteratively in 1 or 2 cylinder increments until it has achieved some relative cylinder count target. 

This means that the PICO sees just one interrupt for an RK-05 and can immediately report the new cylinder location, but the PICO gets interrupted for each 1-2 cylinder step, could be as many as 100 times, before the arm reaches its final position. Thus the logging routine gets a callback while the controller is somewhere in the midst of a number of steps, reporting the cylinder value at that instant. It is often somewhere in between the starting and the final location, thus not very useful to read. 

Nothing passing between the 1130 disk controller logic and the drive indicates when a seek instruction begins nor which step constitutes the last one of a seek movement. However, I believe that I can use timing to break sequences of steps into the equivalent of the seek command issued in the 1130. I can delay triggering the seek command pulse until the entire sequence has finished, thus the callback routine can fetch the final cylinder address. 

Each step of 1 or 2 cylinders takes approximately 15 milliseconds to complete. When the controller begins a seek, it will issue a 1 cylinder step if the movement count is odd, otherwise all steps are 2 cylinders. The steps are contiguous - as soon as the drive indicates completion of one step with +Access Ready it fires off the next step request with -Access Go. When the last step has been achieved to fulfill the relative movement count in the seek instruction executed by the CPU, the disk controller raises an interrupt request to the CPU. 

At the completion of any instruction that is in progress, the CPU branches into the interrupt handler routine. Typically the interrupt handler routine will sense the status of the disk drive to be certain that it worked as intended. It exits the interrupt handler and allows the program to do something now that the seek is done. 

My hand loop is nothing but a seek forward and then a seek backward, repeated forever. It is going to require some time for the instructions to execute, prior to the next seek command starting its steps with -Access Go.  This delay is how I might identify that the last set of steps, part of the prior seek, completed and that this new step is part of a new seek. 

Ignoring any time that the CPU needs to finish its current instruction, this loop invokes a Branch and Store IAR indirect to jump into the interrupt handler for level 2, an XIO to sense the device status and reset the interrupt request, a Branch Out and Skip on Condition to exit the interrupt handler, and then loop executes the next XIO for the next seek. This sequence takes 50.4 microseconds on the 3.6 uS models of the 1130. On the faster 2.2 uS models it would take 30.8 microseconds to begin the next seek. 

This hand loop is about as fast as one might ever issue seeks in a row. In real life, there will be other operations like reading or writing a sector (those take over 1.15 milliseconds to finish) as well as other kinds of processing not related to the disk drive. 

The timing is short compared to the disk movement steps - about 50 microseconds for the processor time in the very short case using my hand loop - while each step is 15,000 microseconds long. However, the gap between one step and the next within a sequence is zero. That is the key to identifying when an XIO Seek has completed.  

If I start a timer when +Access Ready goes high and stop it when -Access Go goes low for the next step, I can have the timer count on each microsecond. If it reaches 30 (or beyond), we can consider this to be the end of a 1130 seek instruction. Pulsing the seek command line at this time means that the PICO will only log the seek after it finished. 

Checking signals and termination resistors on the Virtual 2315 Cartridge Facility - part 2

SIGNALS BEING OBSERVED AND THEIR PURPOSE

The cable that connects the 1130 to the 2310 can carry up to 20 signals on the 24 connector pins, although in the implementation used in the 1130 only 17 are defined, with one of them connected to two pins on the connector thus 18 pins are wired. 

1. Write Data and Clock - sent by the 1130 when writing data to the disk drive. not connected to the 2310 since the V2315CF box intercepts all data streams to and from the disk
2. Access Ready - a feedback signal from the disk that informs the 1130 when a seek (movement) of the disk arm takes place
3. -10/+20 Mil Step Size - 1130 sets this to move the disk arm one or two cylinders in a step
4. Home Cylinder - 2310 sets this when the disk arm is at cylinder 0
5. 90 Second Relay - the 2310 waits 90 seconds after beginning to spin before it will load the heads down onto the platter and be ready for access. 1130 won't allow write attempt until this is active.
6. Write Clock Phase B - sent by 2310 to the 1130 to have it alternate clock and data pulses on signal (1) above. Sent by V2315CF in this implementation.
7. -Reverse/+Forward Step Direction - requests 2310 to move arm towards home cylinder or forward towards cylinder 202. 
8. Access Go - request from 1130 to move the arm based on step size and step direction signal states. Passed directly to 2310 but monitored by V2315CF to shadow the location of the disk arm. 
9. Write Select Error - status from 2310 that an error occured during a write. Emitted by V2315CF to signal an error in real mode by passing state of 2310 signal.
10. Write Gate (and Erase Gate) - set to turn on the erase coil and activate the write electronics of the 2310 disk drive. Both pins connected to same wire on cable. V2315CF reads these and based on them, will capture data streaming in on signal (1). 
11. Index Marker - pulse emitted once per revolution of the disk platter in the 2310 to reset sector counter to that 1130 always knew which of the four sectors was approaching next. 
12. Head Select - picks whether the read or write occurs for the data from the top or the bottom of the platter in the 2315 cartridge in the disk drive. Used by V2315CF to decide which data to stream or where to put data sent from the 1130 during a write. 
13. File Ready - indicates that the drive is up to speed, 90 seconds has elapsed to allow time to clear out particles in the air inside the 2310, and the circuits are ready to read, write and seek on command from the 1130. Sent by V2315CF to 1130 in real mode when the 2310 sends this signal and we have a valid virtual cartridge image loaded into the V2315CF. 
14. Sector Marker - pulses that indicate where the disk platter is in its rotation. Passed from 2310 to 1130 while in real mode, but also monitored by V2315CF to understand which sector of data to send during a read or update during a write. 
15. Read Gate - sent by 1130 to 2310, but in this implementation only watched by V2315CF. When on, it causes the data for the sector being requested to be streamed out over the Read Data and Read Clock lines at the time it would occur with the real platter on the 2310 based on its rotational position.
16. Read Clock - a pulse emitted once per bit cell that causes the 1130 disk controller logic to watch the Read Data line to see if a pulse arrives before the next Read Clock pulse. Presence of a pulse makes this bit value a 1, while absence on Read Data means the bit value was 0. Produced by V2315CF. 
17. Read Data - emitted in between clock pulses on Read Clock, when the value of the bit is a 1. If the bit is a zero, no pulse is emitted on Read Data until the next Read Clock introduces the next bit cell. Produced by V2315CF. 

SIGNAL RINGING, DISTORTION OR SWING LIMITING IDENTIFIED

For each of the 17 signals, the oscilloscope captured a change in the signal at the receiving end. Thus, for a signal like Read Gate that is sent from the 1130 only to the V2315CF, the signal is probed on the V2315CF. For a signal like Access Go that is produced in the 1130 and passed directly to the 2310, it also is sent to the V2315CF. Thus I monitor at both the 2310 and the V2315CF. A signal like Read Data that comes from the V2315CF to the 1130 is probed at the 1130. 

For some signals, having the terminator resistors in place may cause the signal to fail to be driven fully to logic low, thus they must be removed. This is because the pair of resistors used to establish the impedance matching have low values, fighting against the pull-down of the source particularly due to cumulative voltage drop over the long signal path. 

Other signals didn't rises high enough to provide a clean signal for the V2315CF to monitor correctly. The logic chips in the V2315CF and the FPGA watching the signals define a forbidden zone of signal voltages that sits above the highest voltage that can be considered logic low and sits below the lowest voltage that can be considered a legitimate logic high. If the signal is in the forbidden zone, the behavior in the V2315CF is going to be flakey. 

The IBM Solid Logic Technology (SLT) used in the 1130 and disk drive electronics is a form of Diode-Transistor Logic where the only thing that counts is whether the driver pulls the receiver down close enough to ground to cause the inverting transistor to conduct. It is actually the flow of current into the driver that produces the action of the receiving gate, while a logic high is simply the absence of that current flow to ground. Thus, the voltage for a logic high is irrelevant. It can be 1V, for example, right in the forbidden zone of modern logic chips, or even much higher than the 3V that is nominally a logic high for SLT. 

In some cases, leaving the termination resistors off for a given signal will allow it to pull down near enough to ground to activate the SLT circuits, swing high enough when logic high to be safely out of the forbidden zone of the V2315CF, and not have too much ringing or distortion due to impedance discontinuities. 

In some cases, weaker termination resistors will be needed to guarantee a high enough voltage for logic high and still permit the driver to pull the signal low enough to qualify for SLT and V2315CF logic low. These resistors pull up the logic high level to an appropriate voltage for good V2315CF detection. This goes mean that we don't have good impedance matching for that end of the signal, but if the ringing and distortion aren't causing problems this is acceptable. 

The challenge is that we have two modes of operation - virtual and real. For some signals, the driver is in the disk drive in real mode and in V2315CF in virtual mode; for example, the -Sector Marker pulses. Some signals between the 1130 and the internal disk drive are directly connected by electronic switch chips when in real mode, but opened so that the V2315CF can drive the signal in virtual mode. This means that those signals work correctly with a termination resistor choice in one mode but fail in the other. 

DECISION ON TERMINATION FOR EACH SIGNAL

-Sector Mark and -Index Marker pulses come from the 2310 in real mode and from the V2315CF in virtual mode, thus they involve shorting and may need a different termination strategy based on mode. The cylinder zero detection signal -Home is also shorted or not based on mode. 

The +Access Ready signal cannot have terminator resistors installed, while the -Access Go works well with them in place while in real mode. Signals that are not timing critical, such as -10 Mil/+20 Mil Step can work without termination resistors because any ringing or bounce will be resolved before they are utilized in the 2310 or V2315CF. 

I can compensate for ringing in the FPGA of the V2315CF if those glitches are short enough that they are invisible to SLT circuits but observable with the much faster technology in the V2315CF. I did this, for example, with -Access Go and +Access Ready. 

Slow changing signals that do not trigger state machines, such as -Head Select or -10/+20 Mil should not have any glitch or ringing risk but they do need to meet the logic low and logic high requirements of V2315CF if they are monitored and used inside the FPGA and they also must allow the signal to pull down low enough to be valid for SLT gate operation. Interestingly, I observed some bizarre glitches in the -Reverse/+Forward signal, which didn't impact either the V2315CF shadowing nor the operation of the internal disk drive. 

The data streams that would have come from the disk heads and the new data that would have been written through the disk heads of the 2310 are always routed between V2315CF and 1130, ignoring the 2310. I can set high value termination resistors for those signals without any difficulties because they don't differ between real and virtual mode of operation. These are -Read Clock, -Read Data, and -Write Data and Clock.The control signals -Read Gate and -Write Gate are similar - they never involve the 2310 thus don't change based on mode.

Having watched each signal and validated how it operated in both real and virtual mode, I was confident that I knew how to manage the termination board resistors. I installed the new resistor values and had very solid results doing seeks. I then attempted reads and writes, discovering anomalous signals coming from the 1130 at the root of the issues, and eventually discovered that somehow a cable that plugs into gate A, Compartment C1 on the bottom row - T6 and T7 to use the IBM numbering scheme - had come loose. Fixing this involved removing many of the SLT cards from the compartment and reseating the cables. I ran out of shop time as I finished up this task. 

Loose connectors

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. 

Testing my new seek logic for the Virtual 2315 Cartridge Facility - 16 and now works correctly in real mode

TESTED LOGIC REFINEMENT FOR SEEK SHADOWING IN REAL MODE

The Virtual 2315 Cartridge Facility (V2315CF) monitors the seek commands sent from the IBM 1130 system to the 2310 internal disk drive. It has to shadow the position of the disk arm on the 2310 so that it always knows where the heads are positioned. This allows the V2315CF to emit the proper data stream when the 1130 reads from the disk. 

The 2310 records four sectors on the top read/write head at each cylinder, with another four sectors on the bottom head. With 203 cylinders available on the 2315 disk cartridge that is inserted in the drive, it holds 1,624 sectors in total. Each sector holds up to 321 words of data - a word being 16 bits in the 1130. Thus the capacity is about 512K words (1 Mbyte) for each 2315 cartridge. 

The V2315CF has to know which cylinder is under the 2310 disk heads, so that when the 1130 selects the top or bottom head and turns on a read as it reaches one of the four sectors on a cylinder, the appropriate data from the virtual 2315 cartridge image is delivered to the 1130. The V2315CF sees which head by receiving the -Head 1/+Head 2 signal plus keeps track of the -Sector Marker and -Index Marker pulses to know when it is beginning a given sector. Combining this with the shadowed cylinder number allows the V2315CF to retrieve the appropriate sector data from the RAM inside the V2315CF and deliver it to the 1130. 

I made a number of changes to the logic in the V2315CF which monitors the seek commands that flow between the 1130 system and the 2310 disk. Because we see what is sent to the disk drive, as long as the drive correctly moves the arm we should be able to keep our shadow cylinder number in sync. Various glitches were causing the shadow and real cylinder locations to diverge. My changes were intended to eliminate these situations so that the shadow cylinder always matches the actual cylinder of the disk arm. 

SHORT PROGRAM CYCLES THE ARM BETWEEN TWO CYLINDERS

A program will move the disk arm forward by some number of cylinders, then when the drive reports successful completion, it will move the disk arm in reverse by the same number. It then repeats, so the arm should be zooming back and forth between two set cylinder locations. At any time, stopping the program should leave the arm at one of the two positions. 

The IBM 1130 allows the program to request a forward or reverse seek of any number of cylinders up to the maximum  possible movement of 202. The 2310 disk drive only supports moving one or two cylinders in a step. Thus, the 1130 iterates stepping the arm until the full count requested by the program has been accomplished. Moving one cylinder is only done as the first step of a seek and only when the count from the program is an odd number; all other steps are two cylinders at a time. 

The direction and size of each step is controlled by -Rev/+Fwd Direction and -10 Mil/+20 Mil Step signals. The actual request to take a step is sent with -Access Go from the 1130 with the 2310 providing feedback using the +Access Ready signal. Our shadowing of the arm movements will observe each falling edge of -Access Go to begin, change the shadow cylinder number based on direction and step size, then end the step after a complete down and up cycle of +Access Ready. 

Short glitches on these signals are ignored by the 1130 and the 2310 logic circuits, but have tricked the FPGA logic into falsely triggering a step or ending one prematurely. I improved the debouncing functions and added safeguards that should eliminate the impact of short term glitches. 

OBSERVING THE PROGRAM CYCLING BETWEEN CYLINDERS

The V2315CF and the disk arm agreed perfectly. I ran fast and slow patterns, always getting agreement between V2315CF and the disk arm. I seem to have developed a solid approach now. I will do a check for virtual mode when I next get to the shop, followed by running the IBM disk diagnostic program (309) which will validate every aspect of the disk drive. When that runs clean in both real and virtual mode, I move on to wrapping up the project.

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

FPGA IN V2315CF UPDATED TO WORK WITH ELECTRONIC SWITCH VERSION

The FPGA inside the main box of the Virtual 2315 Cartridge Facility (V2315CF) was loaded with the updated logic that renders the output drivers of the box inert for signals that are directly connected in real mode between the 1130 and the 2310. This resolved a problem seen in the last test session, where I two sources were driving signals in opposite directions. I also added in the version of the seek shadowing logic that was hoped would be impervious to glitches. The terminator resistors were installed only on the signals that require them. 

TESTING WITH HAND ENTERED ACCESS PROGRAM

I ran the hand entered code that will repeatedly drive the arm between cylinder 0 and cylinder 200 as long as the 1130 is in run mode. The disk performed exactly as requested, stopping each time at 0 or 200, but the V2315CF got out of sync a bit. It recorded the lowest cylinder location as 2 and the top location as 202. Once it was out of position, it never locked in to cylinder 0. 

OBSERVATIONS OF SHADOWING IN THE V2315CF AS THE ARM MOVES

The logic in the V2315CF can observe the microswitch that turns on the -Home signal to logic low when the arm is at cylinder 0. Based on that, I can reset the current cylinder to 0 when we are beginning a seek when -Home is asserted low. That would have solved this particular issue, but if I had a program that zoomed back and forth between two cylinders that did not include 0 - say cylinder 10 and cylinder 190 - then if it got out of sync the microswitch fix won't help. 

DEVELOPED MODIFICATIONS TO SEEK SHADOWING LOGIC IN FPGA

I put in the logic to reset the cylinder whenever the arm is sitting at cylinder zero. I also made changes to hopefully address whatever issue caused it to get out of sync with the actual disk arm. When I get back to the shop I can test this to see if I resolved the vulnerability or not. I will also have the logic analyzer collecting data as I test this out, to see if I can spot any other situations that cause the FPGA logic to misbehave. 

Checking signals and termination resistors on the Virtual 2315 Cartridge Facility - part 1

REVIEWING TERMINATOR CARD FOR SIGNALS ENTERING THE V2315CF MAIN BOX

The Virtual 2315 Cartridge Facility (V2315CF) sits in between the IBM 1130 disk controller logic and the internal 2310 disk drive inside the 1130, routing signals into the main box of the V2315CF. Some signals are directly connected between disk and 1130, but a tap sends the same data into the V2315CF, while others are either generated in the main box or received there and then rebroadcast on another line.

The main box has a plug-in board with terminator resistors. One pulls the signal line up to +5V while the other pulls it down to ground. This sets the signal, when no other element drives it, at about 3V and yields an impedance of 104 ohms which is close to the ribbon cables that carry the signals between the main box and the 2310 Interface Board that routes signals to the 1130 and 2310 cables. 

The 1130 or 2310, depending on the direction of the signal, also provide a pullup resistor to +3V for most signals. This can interfere with the impedance and voltage levels of signals. I wanted to observe each signal to see what when they need the termination resistors installed and when they are better off without them. 

WORKING ON SEEK SIGNALS FIRST

The signals involved in a disk arm movement (seek) are -Access Go, emitted by the 1130 disk controller logic to request a movement, along with -10/+20 Mil Step and -Rev/Fwd Direction  signals that the 1130 sets prior to the falling edge of the first signal. The 2310 disk controls the +Access Ready feedback signal, which provides a handshake to the 1130 indicating when the arm has finished moving. 

+Access Ready will drop low about 5 milliseconds after the 2310 has seen a falling edge on -Access Go. The 1130 will respond to the drop of +Access Ready by returning -Access Go to logic high. After a further 10 milliseconds, +Access Ready returns to logic high indicating that the arm movement has completed. All four signals involved in the seek are directly connected by the electronic switch chips while the V2315CF is in real mode, so the output of the 1130 is directly connected to the 2310 and the output of the feedback from the 2310 is directly conneccted to the 1130. 

The FPGA in the V2315CF snoops on those signals so that it can shadow the position of the disk arm, knowing exactly where the drive arm is sitting at any time. I had hammered out some logic that I believed would be unaffected by the kinds of glitches I saw on the signal lines when I observed them using my logic analyzer. 

TRYING TO MOVE THE ARM RESULTED IN HARD SWING TO 202 OR 0

Initially, even when I tried to move just one cylinder, the arm shot all the way to the extreme and kept trying to move. The oscilloscope showed me that the +Access Ready signal was not dropping close enough to ground to be reliably detected by the 1130 controller logic, so it kept asserting -Access Go causing incorrect movement. 

I removed the termination resistors for that signal line and the system cooperated. The arm moved correctly and the signal didn't look too bad. No significant ringing on the timescale that can cause problems for the Solid Logic Technology (SLT) circuitry in the 1130 and 2310. 

CHECKING THE SHADOWING LOGIC OF V2315CF

I ran a program that repeatedly moved the arm from cylinder 0 (home cylinder) to cylinder 200 and back to 0. The disk arm faithfully moved between the two positions, however after a minute of operation, when I stopped the program, I found that the V2315CF shadowing was off by a few cylinders, showing the arm at a low non-zero cylinder when the actual arm was at 0. 

Drat - I am going to need to do even more to ensure that the glitches don't get my logic out of sync. I will work on that over the next day or two. I really want to see the shadowing fully working before I move on to checking the other signals and their need for termination. 

ADDED ERROR MESSAGE ON V2315CF FOR WHAT I EXPECT IS A COMMON ERROR

The physical 2310 disk locks the handle so that a cartridge cannot be inserted or removed until the UNLOCK lamp is lit on the 1130 main console. As soon as the motor begins spinning a cartridge in the 2310, the UNLOCK lamp is turned off and will not turn back on until the platter is stationary again. 

When the user tries to load a virtual 2315 cartridge, they insert it into the V2315CF and flip the switch on that box to LOAD. However, if the UNLOCK lamp is not on, then it silently ignored the attempt to load the virtual cartridge. This reflects real life behavior of the 2310, but the user may not realize what is happening if they start spinning up the 2310 then try to load the virtual cartridge. 

To make this clear, I now display an error message on the LED screen of the V2315CF "Must be unlocked". This is a reminder of the correct operational sequence - load virtual cartridge first, then start up the 2310 drive. 

ISSUE WITH THE CE SWITCHES ON THE BACK OF THE 2310 DRIVE

The 2310 disk drive has four switches on the back that are used by the Customer Engineer (CE) to test the drive. The let the CE move the arm forward or backward in steps of 10 or 20 mils, either one time per press or continuously while the switch is held. These are supposed to be inactive when the 2310 is cabled to the 1130 system, but work if the cable is disconnected from the disk drive. 

The ciruitry for these is hidden across five pages of logic diagrams in two different binders (1130 and 2310) but not completely. The rest of the diagram is shown in the manual Field Engineering Theory Of Operations for the 2310 drive. 

The 1130 side of the cable is connected to the +3V power rail. Inside the 2310, a pulldown resistor to the -3V rail keeps the switches negative unless the cable is connected so that the +3V is present instead on the line +CE Interlock. I previously identified a defect in my design, where I was grounding +CE Interlock which still permitted the CE swtiches to operate. I modified the 2310 Interface Board to connect the incoming +CE Interlock line from the 1130 to the 2310, which should deliver +3V and inactivate the switches. 

I measured the voltage at the 2310 and +CE Interlock was negative. I pulled the cable from the 1130 and checked the signal coming in, which was about 2.4V not 3V. I moved back into the 1130 where the wire originates. The voltage on pin D07 of A-C1 slot N7, the connector end inside the 1130 logic gate, was 2.4V. That pin should be directly connected to the adjacent slot (A-C1 M7) pin D03 which is the pin where the +3V rail enters SLT cards. The pin on M7 D03 was 3V. 

The issue was a failure in a trace that should connect A-C1 M7 D03 to A-C1 N7 D07. I added a wire wrap connection and did have +3V delivered on the 1130 cable where +CE Interlock enters the 2310 Interface Board. That restored the intended lockout of the CE switches. 

REWORKED THE POWER WIRING OF V2315CF

The power to the V2315CF is connected through a power PCB but with wiring to external parts - a timer module, a smart trickle charger, a 12V motorcycle battery, the incoming +12V rail of the 1130 and the power supply board that comes with the RK-05 Emulator kit upon which the V2315CF is built. 

It had included diodes to isolate the battery and +12V inputs, a circuit to detect when the 1130 12V supply dropped, and connections among the other external parts. The diodes caused an unacceptable voltage drop in the supply to the emulator power supply, so I redesigned to eliminate them.

The timer is always powered by the 12V battery now. Its sense line to turn it on for 40 seconds is connected to the incoming 1130 +12V rail. Its SPDT switch is connected with the emulator power supply + input hooked to the armature, the 1130's 12V rail connected to the N/C terminal and the 12V battery + terminal connected to the N/O terminal. This switches the emulator power supply from the 1130 system over to the battery for 40 seconds when the 1130's power drops.

A smart trickle charger maintains the voltage of the 12V motorcycle battery as long as the 1130 system is plugged into the building power, even when the 1130 system is otherwise powered down. Thus the battery is topped off and always ready to support the 40 seconds of power necessary to rewrite the current cartridge contents back to the microSD card in the mini 2315 cartridge. 

I can pull the diodes from the existing PCB and make a few minor changes to utilize it under the new design. I rewired everything and gave it a test on the bench to be sure that it works as intended.