Adjusting my Virtual 2315 Cartridge Facility design to increase signal integrity between 1130 and disk drive

LOGICALLY THE V2315CF SITS BETWEEN THE DISK AND THE 1130 COMPUTER

The cable that ran from the disk controller logic cards in gate A compartment C1 of the 1130 originally plugged into the internal 13SD disk drive, but we inserted the 2310 Interface Card between the two. The original cable plugs into that card and a new cable from the card plugs into the disk drive. Two ribbon cables connect the 2310 Interface Card with the Virtual 2315 Cartridge Facility (V2315CF) main box where the signals are processed.

The V2315CF operates in one of two modes - real or virtual. A switch on the 2310 Interface Card selects the mode of operation. 

In real mode, the 13SD disk drive is operating and performing all of its functions except for the data streams to and from the read/write heads. The V2315CF uses a virtual cartridge file in a mini cartridge to generate the bit stream that the drive should have produced, if that virtual cartridge were a real 2315 disk cartridge inserted in the drive. It also captures data that the 1130 intends to write on the disk drive, instead updating the virtual image file in the V2315CF. 

The disk drive spins a 2315 cartridge, although what is on the cartridge doesn't matter since the read/write heads are never lowered onto the disk surface. The cartridge generates sector and index pulses that identify which sector the disk head is flying over at any instant. The disk drive indicates when the cartridge is spinning at the proper speed and it has completed the load sequence, so that a File Ready light illuminates and the 1130 is allowed to command the disk drive. 

The 1130 commands the disk drive to move the arm with the read/write heads inward toward the hub or outwards to one of 203 circular paths on the surface of the disk, called tracks or cylinders. The control signals and feedback signals flow between the 1130 and the disk drive by entering the V2315CF and being passed out to the other side. 

The V2315CF must snoop on the movement of the arm, in order to understand which track the 1130 believes it will be reading from or writing to. The data being read or written is to that track's position with the virtual cartridge file. 

In virtual mode, the V2315CF produces the sector and index pulses and indicates when to turn on the File Ready lamp and allow access. The disk drive is not powered up, does not spin and the arm does not move in and out. Everything that the disk drive did is now generated in the V2315CF and all interactions are between the 1130 and the V2315CF. 

REAL MODE SIGNAL INTEGRITY AND DELAY ISSUES ARE POSSIBLE

Signals from the disk drive must flow into the V2315CF so that the FPGA inside can direct a copy out to the 1130, and conversely signals from the 1130 must first be detected in the FPGA so that the FPGA can generate the same signal out to the disk drive. This adds delays of 80 nanoseconds or more to the passage of the signal. It may also result in the signal developing glitches that cause incorrect behavior. We are troubleshooting issues with seek - moving the arm to a different track - which might be caused in part by these signal integrity issues.

REDESIGN TO CONNECT THE 1130 AND DISK WIRES TOGETHER

I came up with a redesign of the 2310 Interface Card that will connect together the corresponding wires when we are in real mode, so that the signal produced by the 1130 is directly received by the disk drive, and vice versa for signals in the other direction. We can still snoop on those signals, in order to keep track of the arm position on the real drive, but we don't detect them and the generate a copy. 

This is possible because the V2315CF main box, derived from George Wiley's RK-05 Emulator, uses specific interface chips for incoming and outgoing signals. Most importantly, it uses open collector output drivers for signals generated by the FPGA. Thus, if we set that driver signal so that the transistor is not conducting, then it is electrically isolated. 

I added electronic switch chips - TMUX1112 - that connect the input and output sides just like a physical on-off switch. The switch that determines whether we are in real or virtual mode is used to activate those electronic switch chips when the switch is set to real mode. Thus, the -Access Go signal from the 1130 disk controller is connected to the -Access Go wire to the disk drive, allowing the signal to flow without any reshaping or delays.

In real mode, we control the output drivers for those signals so the transistors are off. We connect the two sides using the electronic switches. The input buffers that allow the FPGA to read the signals coming from the 1130 or the disk drive are still operational, thus the FPGA can see what is happening on the 'wire' we connected between the two sides. This supports the shadowing of arm movements and other needs of the logic inside the V2315CF. 

In virtual mode, the switches are turned off and the signals going to the 1130 are produced by the open collector output drivers in the V2315CF. Signals from the 1130 are detected by the buffer chips. Nothing is generated on the output drivers going to the disk drive, since it is turned off. We don't pay any attention to signals that would come from the disk drive since it is not operating. 

NEW VERSION OF 2310 INTERFACE CARD PCB DESIGNED AND PARTS ORDERED

I added a couple of the TMUX1112 electronic switch chips into the schematic, wired them up to bridge pairs of signals that should flow directly between 1130 and disk drive while in real mode, and controlled those switches by the real/virtual mode switch on the board. I placed the parts, routed the connections and prepared the files to send to a PCB fab.

I ordered the two electronic switch chips and changed the logic in the V2315CF to keep the transistors of the output drivers turned off in real mode. Once the new PCB arrives and is assembled, I will place the new version of the logic into the FPGA and test the V2315CF. 

I will finish debugging the seek behavior of the V2315CF and if it turns out that signal integrity or delay plays any role in the issues, I will send the board out for manufacture and buy the electronic switch chips. If everything works solidly after any defect resolution of my logic or disk/computer hardware, I won't spend the money nor invest the time to implement this change.