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. 

Working hard on making seek shadowing state machine impervious to glitches for Virtual 2315 Cartridge Facility

LOGIC ANALYZER SHOWS SHORT GLITCHES THAT CAN AFFECT STATE MACHINE

When looking at the logic analyzer traces I collected while doing seeks with the Virtual 2315 Cartridge Facility (V2315CF), where the internal 2310 disk drive of the IBM 1130 was used in concert with the virtual disk cartridge contents, I saw brief glitches. These were 10 nanoseconds or less in duration, thus completely ignored by the Solid Logic Technology (SLT) of the IBM 1130 and the disk drive. However, they are enough to cause problems in the FPGA logic due to the high speed electronics.

The 1130 requests a movement of the disk arm to move one or two cylinders at a time either towards the home cylinder 0 or out towards cylinder 203 which is the highest location where data is stored on a 2315 disk cartridge. A seek command issued by a program specifies a relative number of cylinders to move; the disk controller converts this into a set of 1 or 2 cylinder steps until the desired total movement is achieved. 

The -Access Go signal drops low to request a step, with the drive responding with a feedback signal +Access Ready that goes low 5 milliseconds after the seek request and remains low for another 10 milliseconds before returning to high to indicate that the movement is complete. The originating -Access Go line is returned to high when the 1130 sees the +Access Ready line drop low 5 ms into the seek. 

I captured a seek command where the program requested a movement of 40 cylinders, which the 1130 drive controller electronics converts into 20 movements of two cylinders each. The seek shadowing function in the FPGA only counted 38 cylinders while the 2310 disk itself moved the full 40 cylinders. There are two glitches on the -Access Go line that were the cause of the state machine in the FPGA going awry. 

top is -Access Go, next is +Access Ready

When I zoom in on the glitches, they are all shown as 10 nanoseconds long, which is the sampling interval so the actual glitch is likely even shorter. None of the cabling in the 1130 is designed to eliminate very short glitches like this because the logic family, called 30 ns SLT, is impervious to short duration perturbations. If I were to try to eliminate all of that, it would involve considerable work to change parts of the 1130 such as altering the type of cable used in the machine. Instead, making the FPGA ignore these is the better direction to take.

WORKING ON FPGA LOGIC THAT IS IMPERVIOUS TO SHORT DURATION GLITCHES

I worked on the state machine that shadows the seek movement by watching the signals between the 1130 and the 2310 disk drive, working to ensure that it produces the correct results with brief glitches in the signals. In order to test that, I had to develop a good testbench for simulation that would introduce glitches of every type so that I could watch the behavior of my logic. Building the testbench was more work than the state machine itself, but it did help me achieve the performance I need from the seek shadowing. 

I introduced glitches of several types and in different places during a sequence of simulated movements. Glitches of 100 nanoseconds, far longer than I was observing with the V2315CF, were introduced. First was a brief drop of -Access Go when the 1130 was not actually trying to move the arm. Next was a brief return of -Access Go to high before the drive has responded with a low level on +Access Ready. Third was a brief drop of -Access Go during the final 10 ms of a step, when +Access Ready is low. I also sprinkled a short glitch in between successsful step movements. 

This had to work in both modes of the V2315CF - real and virtual. Virtual mode is when the 2310 disk drive is not switched on. The FPGA simulates the sector and index marker pulses that indicate the rotation of the drive and it simulates the feedback signals such as +Access Ready. In real mode, the drive itself generates the marker pulses and responds to the step requests with feedback signals. 

OUT OF ROOM ON FPGA CHIP WAS NEXT SNAG

With the functionality validated using simulation, I moved to the Lattice IceCube2 tool to generate the bitstream to load onto the V2315CF. Unfortunately, the changes I made expanded the required number of elements like Look Up Tables (LUTs) and D Flip Flops (DFFs) beyond the capacity of the chip installed in the V2315CF. 

I have to find ways of trimming this down without impacting the functionality I just tightened up. I suspect that the big issue was the need to add a second 19 bit register to hold the value of a timer so that I could continue a countdown across a glitch - that register and all the comparisons to certain values that will be contained in it require a lot of DFFs and combinatorial LUT logic. 

I looked over the logic to see if I could find clever optimizations that might reduce the count of DFFs and LUTs while maintaining the working logic. I had to go back to simulation to be certain that these changes had no adverse impact. I also had to hope that I could trim it enough to fit. I have had issues trying to fit in the past, requiring me to strip out what I could from the FPGA code. 

SUCCESSFULLY REMOVED NEED FOR SECOND REGISTER AND ALL THE COMPARISONS

The code was tightened further and works just as well. The result fits in the existing FPGA chip! The final counts of parts are:

• 1,209 Look Up Tables
• 622 D Flip Flops
• 181 Carrys
• 1 Global Buffer
• 3 Global Buffer I/O blocks
• 86 Input Output buffers

The chip is an iCE40 HX1K in a quad flat pack TQ144 package. The FPGA runs under a 40MHz clock. It shares the main board of the V2315CF with a Raspberry Pi PICO processor. The two communicate over an SPI link.  A 32Mbit SPI flash ram holds the FPGA bitstream and initializes it on powerup. The FPGA also controls a 256Mbit DRAM that is used to hold the contents of the virtual 2315 disk cartridge when it is being used by the 1130. A 2315 cartridge holds 512K 16 bit words,  far less than the size of the RAM chip. 

IMPLEMENTED THE CARTRIDGE ICON TO DISPLAY ON V2315CF MAIN PANEL

I converted the image of the 2315 cartridge into a pixel array that is written to the LED panel of the V2315CF main box when a virtual cartridge has been loaded into the RAM and is ready to use with the 1130 system. 

The refresh rate of the LED conflicted with the iPhone camera a bit, so the image doesn't look as good as it does in person. 

Switching over to electronic switch version of 2310 Interface Board for Virtual 2315 Cartridge Facility

ELECTRONIC SWITCH ADDED FOR IMPORTANT SIGNALS RELATED TO SEEK

The Virtual 2315 Cartridge Facility (V2315CF) makes use of a PCB that sits between the signals that normally run between the IBM 1130 disk controller logic and the internal disk drive (2310). It routes those through ribbon cables to the main box of the V2315CF, plus it supports functions such as managing the Unlock lamp on the 1130 console and setting real or virtual mode. This is the 2310 Interface Board.

In past incarnations, the 2310 Interface Board would route a signal from the 1130 to the V2315CF main box, the FPGA would pass the signal through a four stage chain of flipflops to avoid metastability issues, then simply drive the same value out on the signal that would run to the internal disk drive. This introduced some delays in signals and added signal quality issues due to the very fast edges driven by the FPGA. 

This caused problems for commands to seek the disk arm to one of the 203 cylinders on the disk platter inside the 2315 disk cartridge. The signals between 1130 and 2310 involved feedback and responses that could fail due to the delay introduced by signals passing through the FPGA. I decided to directly connect the 1130 and 2310 for those signals, eliminating the FPGA's role and cutting out the delays. 

This posed two small challenges. First, when the V2315CF is switched to virtual mode, the 2310 is not powered on and does not generate the feedback signals that go to the 1130. Instead the FPGA produces thos in a pure emulation of the 2310. Secondly, the V2315CF creates the data stream that would have flowed from 2310 to the 1130, but instead comes from the virtual 2315 image inside the main box; it captures writes from the 1130 to update the virtual image as well. To send the data associated with the current cylinder location that the program has moved the disk arm, the main unit must know which cylinder is current. 

To keep track of the cylinder that the disk arm is current flying over (or emulate it in virtual mode), the main unit must see the signals between the 1130 and the 2310 that constitute a seek - moving the arm. Thus, even when I have directly connected those signals between the 1130 and the 2310, they must also be routed into the FPGA so that it can shadow the movement of the 2310 disk arm (or emulate it in virtual mode). 

To accomplish this, I installed electronic switch chips on the 2310 Interface Board which connect the pin for certain signals between the 1130 and the 2310 cable connections, but only when the V2315CF is in real mode. In virtual mode, the switch is turned off so that the signals to the 1130 originate from within the FPGA and not the 2310. These TMUX1112 chips support four signals each. I applied these to the signals related to disk arm movement (seek commands). I also direct connected the sector and index marker pulses that reflect the current position of the disk platter rotating under the heads. 

TERMINATOR CHANGED TO OPTIMIZE SIGNAL QUALITY

The IBM 1130 technology - Solid Logic Technology (SLT) - is a diode-transistor logic type of circuitry with voltages that (mostly) swing between 0 and 3V for logic 0 and 1. The cables in the 1130 are designed around a nominal impedance of 92 ohms. The main box of the V2315CF does the voltage shifting to accomodate the logic levels.

Generally in SLT, a pullup resistor keeps a gate input high unless it is actively pulled down to ground to drive a logic 0. Without a current flow down to ground, the gate input is considered logic high regardless of the voltage or absence of voltage on that pin. The pull-up resistors are in the 1130 or 2310 circuitry depending on the direction of the signal. Thus for the signals that are switched directly together, nothing is needed in the main V2315CF box. 

However, when in virtual mode, there is no 2310 providing the pullup and the source of the signal is the V2315CF. The FPGA drives 0 or 3V on those lines, rather than using a pullup resistor. Thus, for most signals, since the ribbon cables and the V2315CF main box are relatively close to the 1130 nominal 92 ohm impedance, I decided that terminator resistor pairs are not needed for most signals. However, for a few signals I still needed terminator pairs, especially for the ones that will be generated by the FPGA - when in virtual mode or for disk data streams that always flow between FPGA and 1130. 

I made these decisions based on signal quality observed while I tested the V2315CF. I can easily tweak these over time as necessary. I made the changes to both terminator boards since I am building two V2315CF systems, one for the Vintage Computer Federation's InfoAge museum in New Jersey and the System Source Museum in Maryland. 

FPGA LOGIC CHANGES NEEDED TO AVOID DOUBLE DRIVING OF CIRCUITS

Since the FPGA must drive a logic 1 or 0 for signals when in virtual mode, but we want to use the electronic switch to short 2310 to 1130 when in real mode, I needed to change the FPGA so that it emitted a logic 1 on those signals when in real mode. The interface chips in the main unit of the V2315CF are essentially an open collector gate, thus only active when driving a logic zero. 

By setting them to 1, they are not conducting and thus not acting on the line other than through the pullup resistor in the main box. The pullup resistor function is provided by the terminator board resistors - with 179 ohms connected to +5V and 249 ohms connected to ground. This should be overpowered by the open collector interface chip pulling the line to ground, producing a voltage low enough to register as a logic 0 by the SLT circuits to which it connects. 

FIRST TEST WITH NEW BOARD BUT FORGOT TO UPDATE THE FPGA

I fired up the system with the new 2310 Interface Board and the newly modified terminator board installed. The V2315CF reacted to the seek commands but the disk drive did not move. When I looked at the signal levels seek at the 2310 (and at the 1130 for the blue signal below), the logic swing was insufficient to get down below about 1V. That is too high to register as a logic 0 for the SLT gate input, thus the disk controller commanded the first step of the seek (yellow signal dropped to 0) but the feedback signal (green and blue) did not drop far enough to register. 

I realized that I had not updated the FPGA with the version of the logic that would emit a logic 1 to the interface chips for those signals that are switched together on the 2310 Interface Board when in real mode. In addition, I didn't have a good signal ground on the scope thus the noise showing up on the traces. 

I updated the FGPA logic and will install it onto the V2315CF main box when I next get to the shop. If the signal still doesn't get down to 0 adequately, I will remove the resistor pairs for those signals. That will mean that in virtual mode I won't see a logic high on the scope due to lack of a pullup resistor, but the SLT gate should still respond properly. I will add a high resistance pullup to 3V somewhere to make diagnosis easier in the future. 

PRODUCED 2315 CARTRIDGE IMAGE FOR LED PANEL OF MAIN V2315CF BOX

The main box of the V2315CF has an LED panel that displays the four hex character ID of the virtual 2315 disk cartridge along the bottom of the screen and had been showing a larger drive number on the remainder of the area. The RK-05 disk drive that the box was originally designed for supports multiple drives on a cable string, thus it displayed the address of which disk the box was emulating. This has no meaning for the 2310 which does not share an interface cable with other drives. 

I took an image of the top view of a 2315 disk cartridge and converted it to the 80 x 40 pixel footprint of the original drive numbers being displayed on the screen. I modifed the code in the Raspberry Pi PICO that is in the main V2315CF box so that it displays this image when a virtual 2315 disk image is loaded into the system.