Bringing out the signal sledgehammer - dealing with the signal quality issues for the Virtual 2315 Cartridge Facility

GLITCHES CAUSING PROBLEMS IN SOME FUNCTIONS

Virtual 2315 Cartridge Facility (V2315CF) attaches to an IBM 1130 computer system, working with the internal 2310 disk drive, to allow mini versions of the disk cartridges (2315) to be used rather than having the data stored on the 14" platters in a 2315 cartridge. Part of the function of the V2315CF is to generate signals that are delivered to the IBM 1130 disk controller logic, substituting for signals that are generated by the 2310 disk drive in an unenhanced 1130 system.

The electrical path from the V2315CF to the 1130 logic is complex and results in ugly signals at the input pins of the logic gates in the 1130. There is quite a bit of capacitance, multiple segments with differing impedances, and very fast signals produced by the Lattice FPGA in the V2315CF whose sharp edges create issues that don't exist for signals created by IBM's Solid Logic Technology (SLT) which is much slower and non-standard compared to modern digital technology. 

There are many places in the 1130 disk controller logic where glitches or ringing don't cause a problem, because the state of the signal is employed over a relatively long timeframe. However, there are circuits that respond to the edge of a signal and advance counters; these circuits can see a glitchy signal as multiple valid edges, leading to defects in the operation of the input-output operation to the disk drive. 

The traces above are the falling edge of the -Sector Marker signal that is generated by the V2315CF when it is fully simulating the 2310 disk drive. In a different mode (real), the V2315CF passes the signal from the 2310 disk drive to the 1130 but in this mode (virtual) the V2315CF has to create the signals. The yellow signal is the output of the main V2315CF box where it generates the falling edge of the signal. Purple shows the signal as it arrives at the input pins of the 1130 logic, at logic gate A, compartment C1. The blue signal at the bottom is what the purple input looks like after it has passed through an inverter gate inside the 1130. 

The signal exhibits a major undershoot as well as ringing. The SLT nominal voltage levels are +3V for logic high and 0V for logic low, but the reality of SLT gates is different than one would expect. It does not care about the undershoot, something that would devastate a TTL or CMOS logic device of modern times. 

Further, the actual mechanism of operation of the input is having current sink from the SLT input to the driver, somethat that occurs when the voltage at the input is at 0.7V or lower which causes a current to flow through a diode of the SLT input because of the voltage differential, sufficient to switch off a transistor in the SLT gate to produce the inverted output. Only that current flow causes the SLT gate to see the input as logic low. It must be a large enough current, e.g. 1.5 or 2ma, to activate the SLT gate. 

Equivalent of SLT inverter gate

If there is an open circuit to the input pin, the SLT gate treats it like a logic high. If the voltage is 2V or 10V, the SLT gate treats it like a valid logic high. There are input voltages that may be in a forbidden, zone, not clearly switching the SLT transistor on or off - 1.2V is not enough of a differential to achieve the 1.5ma necessary to completely shut off the transistor and let the output pull up to the 3V logic high level. 

In the purple trace above, the signal at the V2315CF has a pullup resistor to +5V and an open collector gate that turns on to create that falling edge. The signal only pulls up to 4V on the scope because of an effective voltage divider which absorbs 1V. By the time we see the signal at the far end of the cabling, at the 1130 input pin, it is fully at 5V when in logic high state, but drops way below 0V because of the impedance of the pathway, including capacitance as well as resistance. The signal drops down to -4V at the bottom of the undershoot before returning to the zero volt level where we see it ringing or oscillating at that level. 

The swings above zero during the ringing bring the SLT gate input into the forbidden zone, not fully cutting off the SLT gate transistor. We see the output of that SLT gate in the blue trace climbing up to the 3V nominal logic high voltage, but doing so in a see-saw climb because the transistor in the gate is not fully cut off. I believe this particular trace did NOT cause the 1130 to see two different edges, errors that occur sporadically and not on every activation of -Sector Marker from the V2315CF. 

IMPEDANCE IS VERY CHALLENGING

Unlike connections that run over a single cable with a uniform construction, the signals coming from the V2315CF have a complicated routing where each segment can have its own impedance. The signals run over PCB traces to a ribbon cable, very similar to those used with IDE disk drives in more modern computers. This section is going to have an impedance somewhere just over 100 ohms. The signal is connected to my 2310 Interface Board where it is routed to a pin on a 12x2 pin connector. That is, it is routed that way when we are in the virtual mode we are debugging here. 

12 twisted wire pairs form a long cable bringing the signals from this board to the logic gate A of the 1130. In an unenhanced 1130 system, this cable plugs directly into the 2310 disk drive. These are single ended signals on the wire bundle, perhaps 4-5 feet long. IBM tends to design these cables for a characteristic impedance of around 92 ohms when using their flat ribbon cable connections. These loosely twisted wire cables have an unknown impedance. With the V2315CF, the wire bundle from the 1130 logic gate plugs into my 2310 Interface Board. Another cable that I produced runs from a second 12x2 connector and plugs into the 2310 disk drive. My board allows the V2315CF to sit in between the disk drive and the 1130, controlling some signals while passing others through unmodified. 

If we run in real mode, an analog switch chip connects the pin for out signal on the 12x2 pin connector for the 1130 logic wire bundle, routing it to the 24 wires coming in from the disk drive to the second 12x2 connector, so that the disk drive electronics are directly producing the -Sector Marker pulses. Our open collector gate is left at logic high, so it has no effect on the signal. This pass through does see the pullup resistor on the terminator board in the V2315CF, part of the reason that we don't see the full 5V at that point. 

However, the circuit card in the disk drive that produces the signal is not one for which I have the schematics. I don't know the circuit structure nor the resistors used for pullup on that driver gate. All I know is that when the disk drive is connected directly to the 1130, those pulses are correctly handled by the 1130 logic without undershoot or ringing. 

In virtual mode, the terminator board at the V2315CF attempted to manage impedance matching for the signal going from V2315CF to 1130. Some I had tuned to 110 ohms for correct operation, some only worked with much higher value pullup and pulldown resistors so that there was a big impedance mismatch but the voltage swings were correct as seen by the 1130 logic.

The most direct method to handle issues like this is to change termination at the 1130 end, but that is mechanically difficult. The cable connector of the wire bundle from the V2315CF plugs into one slot of the backplane of compartment C1 of logic gate A. The backplane has an array of 7 rows by 11 columns into which SLT cards are plugged. Each slot is 12 rows by 2 columns of pins. The rows are numbered 2 to 7 and the columns are labeled B through M. In addition, slots in the leftmost and rightmost columns (A and N) are used for cables that run between backplanes (compartments) or to other devices. As well, slots for connectors are implemented in rows 1 and 8 for top and bottom cable connections. 

The wire bundle for the disk drive is plugged into column N, row 7 (slot N7). The signals are routed as PCB traces over the backplane to various slots where the connect to a pin of an SLT card when it is plugged in there. For the -Sector Marker signal, it is connected to pin D12 (left column and next to bottom row when viewed from the wirewrap side) of slot L4 which is the input to the SLT inverter on the card plugged in there. In many cases, a signal goes to multiple pins at different slots, but this one signal is the simple case. The signal than flows through the connector and onto the SLT card plugged into L4, where is makes its way to the diode for the input. 

Each discontinuity - wire bundle to connector pins to backplane traces to SLT card slot pin to card trace - plus any wirewrap connections that augment the connections on the backplane - are spots where the signal can reflect, the impedance can change, and of course all that metal generates a significant capacitance. There is no clean way to calculate the effective impedance; all I can do is observe signals and adjust things where I can to reduce artifacts and issues. 

CHALLENGES ADDING TERMINATION OR OTHER SIGNAL CONDITIONING AT GATE A

Unless I cut the wire bundles or cut traces on the backplane, I can't intercept the signal coming in. I have access to the pins of the backplane but they are pretty close together and many have wirewrap connections added. The backplane has 6, 370 holes spaced .125" apart, many with pins that form the slots for SLT card and cable connections. Adding discrete resistors for termination takes up too much space and blocks access for probing signals during debugging. Because of the wirewrap, a teeny PCB to slide over pins would sit at an uneven height. It would also restrict the ability to push probes for logic analyzers or scopes onto pins that go through that PCB.

FINALLY PULLED OUT THE SLEDGEHAMMER TO STOMP OUT THE SIGNAL ISSUES

All the issues above are why I was loathe to try to resolve the signals where the entered into logic gate A. However, the dual modes of the -Sector Marker where it either comes from the V2315CF or the 2310 disk drive, made if very hard for me to produce a termination scheme at the V2315CF which works properly in both modes. 

Therefore, it is time to add some circuitry of my own that will take the signal as it arrives to the connector N7 of the backplane, intercept those that are susceptible to errors due to the signal quality, and transform the signal into something that cannot be seen as multiple edges or push SLT gates into the forbidden zone where their output is not well behaved.

I am going to depend on hysteresis to resolve the problems. I know that when the signal transition starts, the voltage is up at about 5V and when it finally stabilizes it is at 0V, but with all the undershoot and ringing occuring. If I can introduce rules for detecting the transition that block all the effects of the signal issues, I can then generate a SLT style signal into the SLT logic gate that is clean and well behaved. 

The Schmitt Trigger is a device that applies hysteresis to signals. A Schmitt trigger changes from logic high to logic low when the voltage coming it drops to trigger voltage A, but won't switch back to logic high until the voltage climbs up to trigger voltage B. Modern ICs can have Schmitt Trigger inputs to remove short bounces in the signal state as a signal transitions from one state to another, but these devices don't have a wide enough span between trigger voltages A and B to clean up the signals I am seeing. Further, modern chips won't do well with a large negative undershoot.

I therefore created a design that uses an operational amplifier (op amp) as a Schmitt trigger so that I could select the trigger voltages. I choose 1V as trigger voltage A and 4V as trigger voltage B. The op amp will swing hard over from one output state to another as the input voltage crosses these trigger levels. When the input voltage first drops down to 1V or lower, the op amp will swing hard over to the low state and will not react until the input voltage climbs up to at least 4V. It also doesn't care if the input voltage goes negative. Once an input climbs up to 4V, the op amp swings hard over to the logic high state and won't leave that until the input gets below 1V.

I then had to deal with the reality that SLT gates are activated by a 1.5 to 2ma current being pulled out of the input pin, not by a voltage level. To deal with that I put an NMOS MOSFET transistor on the output of the op amp. The rail voltages of the op amp are big enough that when it is in the logic high state, the MOSFET is fully switched on and when it is in logic low state, the MOSFET is fully off. The op amp slams almost instantly to one state or the other based on the trigger levels and the input signal. 

When the MOSFET conducts, it pulls the base junction of an NPN transistor down to effectively 0V, cutting off the transistor. A pullup resistor on the NPN transistor makes the output of my sledgehammer high when the transistor is cut off, but for SLT that really isn't a factor, It is helpful for debugging to see a logic high voltage on a scope or logic analyzer, but only effect that matters to the SLT inverter gate is when the transistor is conducting, because it sinks enough current from the SLT gate input to trigger it on. 

One of five channels

Dealing with the signal realities coming into logic gate A compartment C1 and the electrical realities of IBM SLT gates thus involves an op amp to implement the two widely spaced voltage thresholds, a MOSFET to react to the voltage levels of the op amp without loading it down, an NPN transistor to sink 2ma from the SLT gate, and a 2.5V voltage reference that is a key part of the op amp circuit. Three chips and five resistors, plus the voltage reference and a clean power supply for the components, all simulated on LTSpice and behaving just as I want. 

5V supply from 1130 +12VDC

2.5V reference generator

Due to realities of the MOSFET and NPN, the final voltage thresholds work out to be 4V going up for the signal to be logic high and 0.85V going down for the signal to switch to logic low. Based on the signals coming in from the V2315CF, those thresholds work out perfectly to hammer the ugly input signal into a clean and and off signal local to the logic gate that I can route to the SLT card input. 

To intercept the signal, I have to cut the wire bundle near where it enters the logic gate so that I can route it through my sledgehammer fix. It is cumbersome to do this at that point because the logic gate swings on a hinge right where the wire bundle is passed through a railing into the compartment. I will have to figure out a way to mount my new PCB with the circuits as close to where the bundle enters compartment C1 as I can get it to minimize any load on the signal going from my board to the SLT card input pin. 

I chose to design a card with five channels of sledgehammer on it. I know that the -Sector Marker signal is a problem and I had just barely gotten the -Write Clock Phase B signal to behave by juggling terminator resistor values at the V2315CF, so those two are certainly going to need help. I can imagine two or three others that might benefit from the cleanup. 

The way that the 1130 deals with data is is reading from disk, e.g. data that the V2315CF is generating from the contents of the mini 2315 cartridge, makes it insensitive to glitches and double edges because there is a strict alternation of pulses from the -Read Clock signal and either a pulse or no pulse on the -Read Data signal line. All the logic cares about is whether it saw an pulse at all during the time when a data bit will arrive - two or more edges are still seen as the presence of a pulse. 

The value of the -Read Clock signal is used to shift in a bit and later listen for a data pulse, so the clock signal might need the assist. That would bring the total to three, so I have a few spare channels for anything else I discover in the future. 

ORDERED COMPONENTS AND SENT THE PCB OUT TO JLCPCB FOR FABRICATION

I should have a finished PCB to test with in a couple of weeks or less. I will look around to see if I can breadboard up a circuit in the lab for some early testing of the effect it has on the signal. I think I have suitable op amp and NMOS devices on hand. 

Results of latest logic analyzer capture of write on Virtual 2315 Cartridge Facility

CAPTURE SET UP TO UNDERSTAND WHY WE ARE BUMPING ADDRESSES WEIRDLY

The observed symptom was that when I did an XIO Write command with a buffer filled with 321 words whose values were essentially the same as their word number, thus easily identifiable, the Virtual 2315 Cartridge Facility received the first 111 words of the buffer correctly but then had a strange pattern seemed to be captured for the rest of the sector. We jumped up to word 225 and then were sent every OTHER word in the buffer from that point, meaning the memory address the 1130 was using to fetch memory from the buffer was advancing by 2 instead of by 1.

The logic analyzer produced a spreadsheet that I analyzed with a quick Python program to find the clock transitions and capture the data bit values, assembling them into 1130 words and validating the error checking code bits. Below is the beginning of the capture, which matches the pattern I wrote into the memory buffer for the XIO Write instruction. It shows the relative timing in microseconds from the start of the write operation as well as the extracted word. It would flag any error checking violation to the right of the word. 

Below is the area in the data capture where we see the jump in core memory addresses and the stride of memory addresses increasing to 2. We should be fetching 0x0071 next but instead grab 0x00E2 and then step by twos through the remaining words. 

I realized after a long while that in fact the value I believed to be 0x00E2 was actually 0x0071, the bits apparently shifted left, with the ECC check passing because the word had four bits that were 1, so the ECC value would be 0000. I looked closely at the graphical logic analyzer trace and confirmed that I was seeing the data fetched correctly from memory but shifted a tad due to a glitch on the -Write Clock Phase B line. 

The hardware that requests the memory fetching is designed with only one function - increment by 1 - which occurs at the end of the memory fetch of a word so that the address is bumped to the next position. In modern logic, this is a ripple counter.

I don't see any mechanism that would explain the big leap somewhere in the middle of correct operation nor the double stride used for the rest of the write. I put the logic analyzer on all the address bits coming from this ripple counter and saw it perform perfectly. 

RESULTS OF THE DATA CAPTURE INSTEAD POINTED AT GLITCHES IN SECTOR MARK

What I saw in the traces, particularly the fact that the trailing words of the sector were all zero values, were the expected behavior if a write operation stops too early. The design of the 1130 keeps sending zero words until the actual end of the sector even if the word count for the write command has reached zero earlier. Assuming that bad addresses were fetching words from 1130 memory that all were coincidentally zero was a leap of faith, and unwarranted. 

Looking at traces I captured, I found that -Write Gate was turned off at the 5 millisecond point instead of remaining on for the entire 10 ms duration of a sector. This turned my suspicion back to the physical sector mark pulse that was arriving around the point we stopped grabbing data from the 1130. 

The drive produces eight 160 microsecond pulses spaced evenly around the perimeter of the disk platter, one each 5 ms given the 40 milliseconds it takes for the disk to spin once at its 1500 RPM nominal speed. IBM chose to divide the perimeter into four sectors rather than the eight defined by the hardware pulses. This allowed enough space on the logical sector to write 321 data words. 

To accomplish this, the 1130 disk controller logic implements a simple divide by two circuit using a flipflop that is toggled by the physical -Sector Marker pulse coming from the disk. IBM's Solid Logic Technology (SLT) circuitry in the 1130 uses flipflops that are triggered by a falling edge of a signal. 

They also produce a parasitic false output pulse if the set or reset input is pulsed when the flipflop is already in the requested state. IBM designs around this by adding gates in front of the set and the reset inputs that only allow a pulse if the flipflop is not already in that condition. 

The gates in front of the flipflop are also edge triggered - IBM calls these AC triggered gates. When the trigger signal, marked with the letter N on the input of the gate symbol, has a falling edge, the gate produces a short negative going pulse on the output pin on the right of the gate symbol. However, it is only sensitive to the input falling edge if the other inputs, marked with a right triangle symbol, are at logic low (0V). If any other input is high, the gate ignores the falling edge on its trigger input and does nothing.

Thus, in the logic diagram excerpt below, when the trigger input goes low, the non-inverted output of the flipflop is connected to the gate in front of the flipflop set input. When the flipflop is on, the non-inverted output is high and that prevents the gate from sending a set pulse to the fliplop. When the flipflop is off, the non-inverted output is low and the gate can send a pulse to set the flipflop on.

However, the gate connected to the reset input of the flipflop is conditioned by the inverted output of the flipflop. If the flipflop is already set, the inverted output is low and that allows the gate to send a pulse to reset the flipfop. When the flipflop is not set, the inverted output is high and the gate blocks a reset pulse from being applied. 

The -Sector Marker pulse from the disk drive sits at logic high except for 160 microseconds, once every 5 milliseconds while the disk is rotating. The inverter gate at the top left changes the signal so that it is low most of the time and goes high for 160 microseconds. When the 160 microseconds ends, the falling edge of that signal is passed to the two gates that drive the flipflop set and reset inputs. The action of the two gates means that it toggles the flipflop to its opposite state by routing a pulse to either the set or reset input depending on the current state of the flipflop.

Thus the flipflop goes on and off based on the end of the -Sector Marker pulse. The gate at the top right of the diagram is a simple combinatorial NAND gate. When the inverted -Sector Marker pulse, now high during the 160 uS interval, occurs while the flipflop was set, the 160 uS signal passes through as a negative going 160 uS pulse once every other sector marker. In essence, the top right gate blocks every other sector marker pulse. 

In addition to the eight sector marker pulses that arrive as the disk platter rotates, there is one -Index Marker pulse of 160 uS per rotation that marks which sector is number 0 out of the four logical sectors that pass by the read/write heads during a spin. At the bottom, the -Index Marker pulse negative edge, when it begins its 160 microsecond duration, will force the flipflop to reset so that we are set up to block the next sector marker. 

The index marker occurs just after one of the eight sector marker pulses, so that this position on the disk marks the start of a logical sector, blocking the next sector marker and passing the one 10 milliseconds later. This keeps the disk controller in sync with which sector is arriving next for when a read or write operation must start. 

Astute readers might wonder at the risk of the parasitic output pulse since the index marker pulse might reset a flipflop that is already in the reset state. Indeed that blip might be emitted on the non-inverted output of the flipflop if it was already reset when the index marker arrives. That does cause the top right gate to have a short term high on one of its inputs, but this does align with when the sector marker pulse is active so nothing comes out of the final gate. The timing diagram below shows how this works out:

With this background, you can see how my next logic analyzer trace captured the cause of the short write duration. We were watching the signals involved in switching off a write operation, The important signals to look at are the -Write Gate, -Four Sector Pulses, +Sector Marker (the inverted output of -Eight Sector Pulse from the logic diagram above), +Alternate sector (non-inverting output of the flipflop), and -Alternate Sector (inverting output of the flipflop). 

On the left of the trace, we have the first sector marker, the one that defines the start of the sector we are writing to. The inverted sector marker pulse goes high for 160 uS. The falling edge of -Sector Marker, rising on the inverted signal, turns on -Write Gate to begin the sector. The flipflop resets at the trailing edge of the inverted signal +Sector Marker which would block the next sector marker pulse from passing through to the output of the logic diagram as signal -Four Sector Pulse. 

However, when that next sector marker pulse arrives, we get a glitch that appears as a short sector marker immediately followed by the normal sector marker. The falling edge of +sector marker causes the flipflop to be toggled, then the remainder of +Sector marker passes through as -Four sector pulse and turns off our write. We end prematurely because of the glitch - had the pulse not had the brief blip down, we would have blocked the -Sector Marker and not reacted.

The flipflop is reset at the start of the true sector, but sets briefly before resetting again when the second -Sector Marker ends. The signal line where I produce the -Sector Marker pulse is kind of unique, as it is generated by the V2315CF when in virtual mode, but we pass along the real disk drive pulses when we are running the real (hybrid) mode. 

COMPLICATIONS OF REAL AND VIRTUAL MODE

Some signals between the disk drive and the 1130 disk controller logic are always coming from the V2315CF, such as the -Write Clock Phase B, while others may come from the disk drive OR the V2315CF depending on our mode of operation. The normal mode for the V2315CF is called real, where we spin up the internal 2310 disk drive inside the 1130 and let is generate signals such as sector mark, index mark, file ready, access ready (for seek operations moving the disk arm) and home cylinder. The V2315CF watches those signals and keeps track of what the real disk drive is doing. In virtual mode, we leave the 2310 switched off and simulate all the signals from inside the V2315CF.

Electrically, we bridge the signals from the disk drive to the 1130 controller logic using electronic analog switches on the 2310 Interface Board, a component of the V2315CF. When the switch is set to real mode, the analog switches are closed and they route the signal coming in from the 2310 to the wires going out to the 1130 disk controller. The FPGA logic in the V2315CF does not emit anything on those signal lines while in real mode; since the outputs are open collector gates, we emit a logic 1 to leave the output line undisturbed. The 2310 disk drive provides a pullup resistor to logic high (3V for SLT) and grounds the signal line to send a logic 0. 

In virtual mode, the switches are disconnected and the signal is produced by sending logic 1 and 0 values to the open collector output gate. To provide a pullup because the 2310 is no longer operating,  we depend on two things. The termination resistors on the V2315CF have both a pullup to +5V and a pulldown to ground, with the resistor values creating an impedance match to the ribbon cable and other wiring. They are set to give a logic high value of 3V at the signal line when our open collector driver is at logic 1 and pull down to ground when the driver is emittiing logic 0. 

The challenge is how to handle pullup resistors and termination resistors for when we are in real mode, where these can interfere with the pullup resistors in the 2310 disk drive circuit. I changed these to a much higher set of values that will still set 3V when in virtual mode but have light impact on the levels produced by the 2310 circuit when we are in real mode. 

Because the electronic switch is shorting the 2310 signal to the 1130 disk controller input, our terminators are mid stream and don't do much for real mode, but work adequately when in virtual mode. They have the downside that they don't match the impedance well in virtual mode, acting as a 6K ohm termination for a 100+ ohm line. 

This can give us ringing and glitches, something plaguing the sector marker signal right now. When I had the sector marker terminator resistors at the correct impedance matching - 169 and 249 ohm values - the glitches showed up in the operation. That matched the traces I just showed.

When I pulled the terminator resistors off entirely, the write failed in a different way due to glitches.

Here the glitch occurs on the sector marker pulse at the start of the logical sector. There is a glitch on the falling edge of -Sector Marker (inverted -8 sector pulse is a rising edge in the trace). This toggles the flipflop twice, thus it is set up to incorrectly pass the next -Sector Marker pulse through and stop the write prematurely. 

The issue with the first trace was a glitch during a rising edge of the generated -Sector Marker from the V2315CF in virtual mode, while the second trace shows a glitch on the falling edge. The input gate that accepts the -Sector Marker signal and inverts it for the logic diagram excerpt above has the following actual circuit values (using germanium diodes and transistors with .3V drops):

SLT logic is a form of Diode-Transistor Logic (DTL), which actually switches based on the current that sinks through the input pulling down the junction of the two diodes to cut off the conduction of the transistor. The current creates a voltage drop across the 2K resistor. 

In the absence of any connection to the input pin, the transistor base is seeing a voltage well above its .3V activation level, The transistor conducts to pull the output pin down to essentially 0V. With a current flowing out of the input, the voltage drops at the junction and when it gets down to about 3.3V the transistor will be cut off entirely, letting the output pull up to nearly 3V. A 3V drop on the 2K resistor comes from an input current of 1.5 milliampere. 

The nominal logic high value for the input is +3V, which means that the gate could deliver current into the input from the 2K resistor based on the voltage difference between the input pin voltage and the +6V pullup. It is possible to drive current into the power supply of the gate up through the pullup resistor. With the V2315CF, that is the terminator resistor pair dividing up the current sink between the pullup to 5V and the pulldown to ground. Since that looks like about 100 ohms, the current would be around 1.28ma. 

With SLT, it is simply the pullup resistor which is often 750 ohms, reducing the current being sunk to less than 1 ma. Interestingly, the input does not have to provide a voltage at all in order for the SLT gate to see this as a logic 1 input. Unless then input pulls at least 1.5ma of current down through the input, it appears to be logic high. An open pin is the same as a logic 1 pin, other than the lack of any current backflow into the input. 

While I know the exact circuit values for the components in that inverter gate above, other circuits that take signals from the V2315CF, such as -Write Clock Phase B and -Sector Marker used in different places go to SLT cards for which I do NOT have schematics. I can model the behavior of the connection from the V2315CF to the inverter for generating the -Four sector pulse output, working out termination resistor values that give proper results, I can't do that with the other gates accepting signals from the V2315CF. 

Some signals are used in ways that make glitches or ringing a non-issue. -Index Marker is one where we don't care if we reset the flipflop a couple of times due to ringing. However some like -Write Clock Phase B or -Sector Marker are going to be a problem if we see false transitions. 

I want the signals that arrive at the SLT input pins to be far enough from transition points or invalid voltage levels that I minimize the chance that ringing yields a transition glitch. A voltage produced by the terminator that is too low for logic high input lowers the junction voltage of the SLT inverter gate above too close to the cutoff for the transistor. A voltage that is too high above 0 for logic low input or sinks too close to 1.5ma current is susceptible to partial conduction of the SLT transistor, creating downstream glitches such as I see in the logic analyzer trace. 

The V2315CF drive chip sinks the signal line to ground when the signal is logic low. The terminator resistors pull it up when it is logic high, but the SLT input gate interacts with that. There is current flow into the terminator from the SLT gate because of the +6V pullup inside the gate. 

POSSIBLE SIGNAL QUALITY FIXES

I realized that I could raise the voltage of logic high input even up to 5V, having no effect on the SLT gate detection of a logic high but reducing the current sinking into the terminator. There is no cap for SLT at the nominal +3V since current does not flow into the gate from +3V, it actually flows out at the delta voltage from the input pin and 5.7V. 

This leads to a choice to try a 110 ohm pullup resistor to the +5V rail of the V2315CF, no pulldown resistor at the terminator board, and observe the signals at both the input and output of the SLT gate producing the inverted -Sector Marker pulses. I will experiment with this.

The other design problem I have is the sharpness of the falling edge when the driver gate in the V2315CF switches to logic 0. The Lattice FPGA used in the V2315CF does not have the capability to lower drive current and slow down edges, so the edge going into the SN75451 driver chip is very sharp. Some ringing is caused by the very sharp edge. I can minimize it by adding a series resistor to the output line to lower the current flow, however that quickly interfees with the strategy of using a 110ohm pullup, as any resistance much above 10 ohms will cause the SLT gate to fail to see logic low because of the voltage divider between the 110 pullup and the series resistor. 

I would need to slow down the signal elsewhere, perhaps in the path between the FPGA and the 75451 chip input pin. However, clean options don't exist to do that as rework on an existing board. The gerbers show that the signal line runs under the chip on the top layer and then runs in a tight group with very little spacing on the bottom layer. I highlighted the traces and circled the input pins on the 75451.

I am hoping that good impedance matching and the 110 ohm pullup will clean up the signal suitably to avoid any false transitions. I believe this will generate about 1ma of current between the +5V supply of the V2315CF and the 1130's +3V rail, assuming that the circuitry in the 2310 disk drive uses a 750 ohm pullup resistor on its output, when we are in real mode. In virtual mode, the disk drive circuit is isolated from the V2315CF. 

Debugging the double increment of addresses during a write by the Virtual 2315 Cartridge Facility

MISSING DATA DURING A WRITE APPEARS TO BE A MEMORY ADDRESSING ISSUE

When writing a sector of 321 words to the Virtual 2315 Cartridge Facility (V2315CF), the first portion of the sector is captured correctly but by the middle of the sector, I see the data values being captured are every other word from the 1130 memory buffer. This means we are fetching every other word from memory using the File Address Register (FAR) of the disk controller logic in the 1130. 

The FAR should step by 1 after each memory fetch. The logic requests a cycle steal, a fetch from 1130 memory, with the address set in the FAR. The request signal -CS Req 0 drops low to request the fetch and once it is underway during a 3.6 microsecond 1130 memory cycle, we see +CS Level 0 go high for the duration of the fetch. The data is grabbed during the cycle steal and then when +CS Level 0 drops back to low, the falling edge should cause the FAR to increase by 1. 

Instead, the data returned from the cycle steal is two words past the last one. This suggests that the FAR is double stepping. However, it doesn't do the double stepping until well into the sector. I recorded signals with the logic analyzer to determine if this is what is happening and give clues as to what circuits might be causing the error. 

• -Write Gate
• -Req CS 0
• +CS Level 0
• +FAR 15
• +FAR 14
• -Load File Address
• -Reset File Address
• -B Bit 15
• -Write Clock Phase B
• -Write Clock and Data
• -File Load Gate
• -T6

DEEP DIVE INTO PREVIOUSLY RECORDED LOGIC ANALYZER CAPTURES

I slogged through all the detail of the trace that the logic analyzer captured, recreating the data being written to RAM by my logic and the correspondence with what I was intending to write. I spotted the point where the 1130 went off track. It occured during the 112th word, which should have been 0xC070 but was instead captured as 0x8070. 

The next word, which should have been 0x0071, was instead 0x00E2 and the machine began to step by two addresses at a time from this point until it exhausted the buffer I set up.  The word with 0x00E2 was the 226th word. The address register value while we were processing the 112th word was b0001001101111 (in hex, x26F) and the next word came from address b0001011100010 (in hex, x2E2) which is a huge jump. Further, from that point onward the memory addresses jumped up by two each time instead of one, meaning the data being shifted out by the 1130 to write on the disk was every other word in the buffer from that point. 

The signal that toggles the FAR to add 1 is the falling edge of the +CS Level 0 indicating the end of the fetch and I do NOT see double memory fetch requests on the line -CS Req 0 in the logic analyzer data I have. My next logic analyzer run will capture that signal, thus I can see if we are somehow fetching twice and bumping the FAR twice as a result. Once again, nothing seems to match the pattern and explain why we would work find for 111 words, then have a huge jump and start double fetching or at least double incrementing the FAR. 

Investigating the early end of a write on the Virtual 2315 Cartridge Facility

THE ISSUE I AM INVESTIGATING

As I was finishing testing of the Virtual 2315 Cartridge Facility (V2315CF), I was writing a sector of data to verify that my signal quality fixes had resolved earlier problems. The internal 2310 disk drive of the 1130 has sectors of 321 words in size, a word on the 1130 being 16 bits long. 

The disk has 203 cylindrical paths that the heads can access, changed by doing a seek command to move the arm. There is a head on both the upper and the lower surface of the single 14" disk platter inside the removable 2315 disk cartridge. One rotation of the platter is divided into sectors 0 to 3, thus with the arm at a particular cylinder and with one of the heads selected, the system can read or write any of the 4 sectors available. 

I loaded a buffer in the 1130 memory with a block of 321 words that I wanted to write to the disk cartridge loaded onto the V2315CF. I issued a write command on the 1130 and expected that the image of the 2315 disk cartridge held in the RAM of the V2315CF would have the chosen sector from the write command replaced by the words I placed into the memory buffer. 

I then cleared the buffer to all zeroes and issued a read command for the same sector. I expected to see all 321 words exactly matching what I had put in the buffer. However, it matched up to the 159th word out of 321, the remaining words were all zero instead of the values I intended to write.

MODIFIED FPGA LOGIC TO EMIT A DIAGNOSTIC SIGNAL

Among the questions I want to firmly resolve is whether the FPGA logic I designed in the V2315CF is abandoning the write operation at that midway point, or whether the issue is coming from the IBM 1130 itself. I set up a diagnostic signal that will be 1 when the write state machine is active and routed this out on the external signal lines on the V2315CF so that I could see it on an oscilloscope or logic analyzer.

WATCHING KEY SIGNALS ON THE 1130 PLUS THE DIAGNOSTIC SIGNAL

I put the oscilloscope on the control signal -Write Gate produced by the 1130 when it is writing to the sector. I also hooked up to the -Sector Marker signal to see where the failure occurs in relationship to the sector marking pulses. I recorded the combined output signal -Write Clock and Data from the 1130 to see if it is emitting the intended words after number 159 or is sending words of all zero. 

The -Write Gate signal stays high for the entire 10 milliseconds duration and the sector mark signal seemed reasonable. I wired up the logic analyzer to twelve signals and recorded it to help figure out what is happening here. The signals were:

• -Write Gate
• -Sector Marker
• -Four Sector Pulses
• -Int Req L2
• -Full Wd Count
• -Req CS 0
• -Index Marker
• -Increment Word Count
• -Write Clock Phase B
• -Write Clock and Data
• -RW Condition
• +Sector Marker

TIMING OF KEY SIGNALS CONFIRMED FROM LOGIC ANALYZER

One of the concerns I had was whether the various single shot timers were set properly to allow adequate time for the completion of a write of a sector. Fortunately, the timing is very good, thus no need to readjust the timers.

The sector marker starts the sector. The marker should go low for 160 microseconds, which is generated by my logic in the FPGA of the main unit of the V2315CF. A sector on the disk consists of one fourth of a revolution of the disk platter, marked with two sector marker pulses 5 milliseconds apart. Every other sector marker pulse is blocked, producing the signal -Four Sector Pulses which activates once every 10 milliseconds to delineate the next sector.

When the sector marker pulse ends, 160 ms into the sector, a timer of about 250 microseconds allows the clock and data pulses to transmit a long string of zero bits called the preamble. At the end of the preamble, the signal -RW Cond turns on for the remainder of the write activity. This happened at almost exactly the intended 250 microsecond from the end of the -Sector Marker pulse. 

The end of the preamble comes after we transmit the sync word, a data word of 0x8000 which is recorded on the disk with the last bit first. A word on the 1130 is 16 bits long, which is followed by four error checking bits that enforce the rule that the number of bits that are 1 must be an even multiple of four. Thus the ECC bits can be 0000, 1000, 1100 or 1110 depending on how many 1 bits are needed to reach the even multiple. The sync word needs three more 1 bits after the data is transmitted, so the sync word appears as a 1 followed by the ECC pattern 1110. 

Immediately after, data words are pumped out, with each 20 bits representing a data word plus the ECC bits. The sector consists of 321 words. After each word is completely transmitted, the signal -Incr Wd Count will blip low to count down by 1. When the count goes down from 321 to zero, meaning we have finished sending out the data, the signal -Full Wd Count will go low and end the sector. That also drops the -Int Req L2 signal to interrupt the CPU as the write command has completed. 

As each word is being transmitted, the signal -Req CS 0 will go low to ask for the next word to be fetched from the memory of the 1130. Everything in the trace above looks correctly and properly timed. We also see actual data patterns in the -Write Clock and Data signal for the words being written.

SEEING WHERE THE LIVE DATA STOPS BEING WRITTEN

Looking at the end of the trace, the last word is requested from memory, then the word count is decremented to zero, the interrupt request level is asserted, and the -Write Gate is turned off. This represents the correct end of the write operation, however I can see that the data words are all zeroes for about half of the sector. 

In the trace above, you see the request for the last word, the increment of the word counter and then the -Full Wd Count signal drop. That turns off -RW Cond and turns on -Int Req L2 as the write operation is done. The next -Sector Marker starts which is the end of our sector and causes -Write Gate to return high. All looks correct except that our data has been zeroes rather than the values in the 1130 memory. 

I looked at the point where I stopped seeing valid data words being emitted. It is soon after the -Sector Marker pulse, but that one is not passing through as -Four Sector Pulses so it should not be affecting the disk controller logic. 

I circled the -Req CS 0 signal that fetches the first word that is erroneously zero. I had loaded the memory buffer with 321 words each having its word number as the data value, thus none should be zero. The green circle shows the bits being shifted out have a mix of 1 and 0 data values - these are legitimate. However, once the ECC bits of the last correct word are shifted out, we see the pattern of nothing but zeros for all the remaining data words. 

The duration of the sync word plus 321 data words is 9.347 milliseconds. The first bad word takes place at about 4.6 ms into that duration which is just about the halfway point of the 321 words. That doesn't correspond to an even address multiple, nor even binary count value that would correspond to a bad signal line or gate that would cause us to mis-address memory. 

I decided to decode the last few words that were output and I believe I have a clue. Starting with the last non-zero word and going backwards, I saw x013C, x013A, x0138, and decreasing by twos. That was the clue! My address is jumping by two rather than one, which is why the data ran out early. What is funny is that the early data words step one address at a time, so something has happened to increase the stride from 1 to 2. 

The logic in the 1130 increments the address at the completion of fetching a word, when the signal +CS Level 0 drops. The dance that occurs fetching the data begins when the prior word has had its 16 data bits transmitted over -Write Clock and Data to the disk drive, but prior to the four ECC bits being transmitted. A request to fetch a word from memory (a cycle steal) is asserted by dropping the -CS Req 0 that asks for the top priority memory fetch. 

Once the cycle steal begins, signal +CS Level 0 goes high to report that. During that 3.6 microseconds of a memory cycle, at about 1.3 microseconds from the start, the data has arrived and is being stored in the register that shifts the data bits out to the disk drive. We have four ECC bits to shift out, requiring 11 microseconds which allows plenty of time for the cycle steal to overlap it and the new data to be ready in the register. 

When the cycle steal ends, the address register should increase by 1. A bit later the signal -Increment Word Count goes low to cause the count of words transmitted to be reduced, eventually the count reaches zero and the -Full Word Count goes low to end the write operation. 

If there is a hardware defect in the 1130, it is likely in the circuitry that holds the memory address (the File Address Register or FAR) inside the disk controller logic of the 1130. That circuit also performs the addition when the cycle steal signal +CS Level 0 drops back to low at the end of the fetch. 

The register is a chain of flipflops with combinatorial gates to set and reset each flipflop. There FAR can be reset with the -Reset File Address signal, loaded from memory at the start of the write operation with the -Load File Address signal, and incremented when +CS Level 0 drops low at the end of each memory fetch. The maximum size of an 1130 system is 32K words, thus we need 15 address bits for the FAR; on the 8K system I am restoring, only 13 bits are necessary but the design encompasses the largest configuration. 

In order to understand the circuit, the peculiarities of the IBM logic family used in the 1130 and the documentation methodology they use has to be explained first. The flipflops used in the 1130 are set or reset by the falling edge of an input, not by a steady state signal level. 

The outputs are both a regular and an inverted output, shown at the top and bottom of the right edge respectively. The outputs are steady state other than for undesirable pulses that occur if a flipflop is already set and receives another set input pulse, as well as when the flipflop is unset and receives another reset input pulse. The flipflop produces a brief pulse on the opposite output line - e.g. resetting a flipflop that is already in the off state will produce a brief spurious pulse on the positive output line. 

IBM designs around the spurious output pulses by using combinatorial logic gates that produce or block the input pulses that would cause this issue. The combinatorial gate used to create the set or reset pulses for the flipflop are what IBM called AC triggered gates. 

In the image above, there are two AC triggered gates which will produce a brief negative going pulse when they activate. These are combined together to produce the final pulse that is used to set a flipflop, so that if either of the gates on the left fire, its output sets the flipflop. An AC triggered gate will activate at the falling edge of one input trigger signal, marked with an N on the left side of the gate, but only if the conditioning (other) input to the gate is steady low at the time the trigger pulse. 

Thus, if the conditioning input -B Bit 15 is low at the time that -Load File Address has a falling edge, the lower gate will produce a set pulse for the flipflop. Similarly, if the flipflop is not set, then +File Address Bit 15, the output of the flipflop, is low and conditions the upper gate. When +CS Level 0 has its falling edge, the flipflop is set but only if it had been unset before. 

Thus our flipflop for FAR bit 15 will be set if it is not previously set, when the cycle steal memory fetch ends, or will be set if the value on B Bit 15 is low when we are loading the file address. -B Bit 15 is inverted, so it is low when bit 15 contains a 1. The lowest gate on the left simply carries the signal -Reset File Address through to the reset input of the flipflop; a negative pulse on the reset file address line will reset the flipflop immediately. 

This means we set the FAR flipflops to match what is in the B register (memory fetch output) when we drop the signal to load the file address. The flipflop will be reset when the cycle stead memory fetch ends but only if it had previously been set. We also can reset this if the signal -Reset File Address is dropped low. 

The effect of the +CS Level 0 signal is to toggle the state of the flipflop each time that we have a falling edge on the input signal - every time we complete a cycle steal memory fetch. This is the first step in the addition process that increments the FAR after each cycle steal.

Whenever a bit of the FAR goes off, it toggles the next higher bit, which is how we make this increment. Below, you see that the output of +File Address 15 is connected to the trigger of the gates for FAR bit 14, so that whenever bit 15 turns off, the falling edge will toggle the state of bit 14. The remaining bits are similarly connected, thus dividing by two on each bit position and yielding an address that steps by one every time we fetch a word from memory via cycle steal. 

FAR bit 14 has the same logic to load or reset in addition to its role toggling its state with each drop of bit 15 to zero. This all seems pretty straightforward and the logic analyzer traces show only a single falling edge of +CS Level 0 occuring on each word. Based on this, unless something is defective in the circuits, this should count up strictly by a stride of 1. Further, nothing I see in the circuit would make the low bit (FAR 15) jump based on the state of the upper bits. 

My only speculation is the part of the setting logic for FAR 15 that looks at the value in B bit 15 and turns on the flipflop when the -Load File Address signal drops. If this is failing, then any data word fetched from memory with bit 15 having a 0 value might set the flipflop, then the end of the cycle steal fetch would toggle it a second time. A mechanism like this would produce a stride of 2, which is supported by the data values of the final few words fetched which all had the low order bit value of 0. 

NEW LOGIC ANALYZER RUN TO LOOK FOR THE CAUSE

Since it appears that something goes wrong in the circuits that increment the FAR, I will capture those with the logic analyzer and look for a) confirmation that it double steps FAR bit 15 or fails to bump FAR bit 15, as well as b) indications of the signals that might contribute to that failure. Hopefully that will let me dive into the issue and look for the true cause. 

All Virtual 2315 Cartridge Facility utility programs now using Qt graphical user interface

REVAMPED ALL UTILITY PROGRAMS TO USE A GRAPHICAL USER INTERFACE

The programs had a mixture of Tk (John Ousterhout's graphical interface that goes with his Tcl language), direct python input and Qt toolkit interfaces. Many would pop up simple dialog boxes to grab input such as a sector number.

I decided to build up a more normal graphical interface. All the programs now open a window with buttons, text entry spaces and other elements. The user enters parameters such as cylinder number by pressing a button, typing in the value, and either having it accepted if properly formatted or seeing an error message inside the main window. Action buttons request the functionality such as 'convert a file' or 'update a sector'. 

CONVERTED ALL PROGRAMS TO STANDALONE EXECUTABLES FOR WINDOWS

I used Pyinstaller to build these into a single executable that does not require the user to install Python and the various libraries used by the utility programs. This does make them fairly big, around 50MB each. The github repository for the project holds both the Python script and the executable, for the convenience of the user. 

EXAMPLE MAIN SCREENS

The convert1130.exe program needs the user to select the input file in IBM 1130 simulator format, asks the user to create an output file, but also needs then to have entered the four hex digit cartridge ID to write on the virtual 2315 cartridge along with a free form text description of up to 199 characters that they can use to annotate the contents and usage of this cartridge. The button Convert the file causes the conversion to occur, as long as the required other information has been properly entered.

The updatesector.exe program asks the user to select the file in virtual 2315 disk format that will be opened. The user must enter the cylinder, head and sector address of the sector they wish to update. The cylinder is validated - it must be 1 or 2 hex digits in the range 0 to CA to correspond to cylinders 0 to 202 that can be accessed on the 2310 disk drive. The button Display Sector will cause a window to pop up with a grid that shows the contents of all 321 words of the sector. The user can click on any word in that grid and type in a replacement value. It must be a valid four digit hex value else it is rejected. The user can then click the Write changes back button to update the disk file, or choose a different sector address and display that, or quit the application. 

EXAMPLE OF ACTION WINDOWS THAT POP UP

Above shows the grid that pops up in the updatesector.exe program which allows the user to update any and all words of that sector. 

Above is the output of the listcartridges.exe application showing a list of all files in the selected folder/directory that are in valid 1130 simulator or virtual 2315 disk format. 

EXAMPLE OF BONUS INFORMATION

Additional information is printed to the DOS window that opens behind the executable program (or the script if running the Python code directly), where it might be useful in special cases. For example, while building the list of file names that are either virtual 2315 format or 1130 simulator format disk files, the listcartridges.exe program outputs additional data on the 2315 file extracted from its header.

Wrote more utility programs to use with the Virtual 2315 Cartridge Facility

UPDATESECTOR IS GRAPHICAL EDITOR FOR ONE SECTOR OF A VIRTUAL 2315

This Python program opens a disk file used with the Virtual 2315 Cartridge Facility (V2315CF) allowing the user to edit the contents of one of the sectors on that virtual 2315 disk cartridge. A sector is 321 words long, a word on the IBM 1130 is 16 bits wide, and the words are displayed and edited in hexadecimal. A 2315 disk cartridge is organized into 203 cylinders and each cylinder is accessible by one of two read/write heads. Each of those 406 locations has four sectors of 321 words on it. 

At startup, the user selects the file in the V2315CF disk format, verifies that it is in the correct format, and then asks for the cylinder, head and sector number of the sector to be edited. 

The cartridge number and description are listed then the user is given a series of three pop up boxes to select the cylinder number, head number and sector number of the one sector they want to edit. A graphical grid editor is opened with a grid 

The grid is 16 columns wide and 21 rows long, the last row having only a single cell. The rows are the first two hex digits of the address of the word while the column headings are the third digit. Each cell is the word in the sector at that word number. For example, the bottom right cell shown above is at address 0x0EF and the value in that word is 0xDA34. The grid can be scrolled down to get words in addresses 0x0F0 to 0x140 as shown below.

Clicking in a cell allows entry of four hex characters before clicking elsewhere or hitting a tab to move to the next cell. The keys are validated - must be 0-9 or a-f and must be four long. Below you see the grid after I entered different values in two cells. At address 0x000 I typed in 3002 and then at address 0x016 I typed in AAAA. These replaced the prior values of 0x0000 in both cells. 

Once I click on the X in the upper right to dismiss the editor grid, the application writes the modified sector back to the virtual 2315 disk cartridge file and exits.

COMPAREDISKS WILL HIGHLIGHT EVERY SECTOR WHERE TWO 2315 DIFFER

The user selects the two files, each of which is validated to be in the correct format by the application before continuing to the comparison. The program then checks every word in the disk and reports the cylinder, head and sector number of each sector that has differences between the two files. 

The results are reported on a grid that pops up, with 8 columns across and 203 rows. The rows are the cylinder number in hexadecimal. The columns are:

• H0 S0 - head 0 sector 0
• H0 S1 - head 0 sector 1
• H0 S2 - head 0 sector 2
• H0 S3 - head 0 sector 3
• H1 S0 - head 1 sector 0
• H1 S1 - head 1 sector 1
• H1 S2 - head 1 sector 2
• H1 S3 - head 1 sector 3

Any sector where the data in the two files are different is colored yellow and has the cylinder number, head number and sector number reported. The cylinder number is given in hexadecimal and then decimal within parentheses. 

Simply click on the x in the upper right corner to close the grid and end the application.

AWAY UNTIL EARLY NEXT WEEK

I am visiting my daughter in Providence Rhode Island for a few days, but will be back and in the shop early next week. 

More debugging of write functionality of Virtual 2315 Cartridge Facility

RESOLUTION OF PREVIOUS ISSUES APPLIED

During testing of writing from the IBM 1130 to the Virtual 2315 Cartridge Facility (V2315CF) I had identified two areas of concern. First, the power supply that converted the 12V produced by the 1130 computer system down to 5V for delivery to the main unit of the V2315CF had periodic voltage glitches about every 30 microseconds. Second, the clock signal generated by the V2315CF that is delivered to the 1130 circuits so they can transmit the data stream for a write had several issues.

The power supply problem was due to economy mode operation because the DC to DC converter in the power supply was loafing along with the demands of the V2315CF relative to its 10A capacity. This caused it to turn off the switching oscillator and turn it back on every 30 us for a brief burst. That created a ringing of the supply with over 1 volt swing during each burst. 

The fix was to add about 2A of power dissipation using carbon power resistors so that the supply did not need to enter economy mode, as well as adding a couple of filter capacitors where the 5V enters the main unit of the V2315CF. The oscilloscope confirmed that the wild swings every 30 us had been managed. We now have less than a millivolt disturbance on the incoming 5V to the V2315CF main unit.

5V rail swing with scope set to 200mv per major division

The signal issues included a logic high level that never reached 2V, a major undershoot from ringing, and a slow rise time of the signal. The source of the signal is an open collector gate, which is what gives the dramatic falling edge. The slow rise time and low voltage at the 1130's input pin is due to the high value pullup resistor at the V2315CF and the capacitance involved in the long complex path between the V2315CF unit and the 1130's logic gates. 

The fix was to install a 169 ohm pullup resistor to 5V and a 249 ohm pulldown resistor to ground on the terminator board on the V2315CF. That gives a much stronger pull-up and ensures that the high voltage at the 1130 logic gate is much closer to 3V. It ensures a faster rise time for the signal. Lastly, it should provide a better impedance match to the signal path which hopefully will quench most of the ringing at the falling edge. Again, the oscilloscope on pin B03 of card slot K6 of compartment C1 in the 1130 logic gate A showed a better behaved signal. It is still low, having to do with the effects of all the resistances in the circuit, but the skipped shifts no longer occured. 

Some of the ringing is due to poor scope lead grounding

BETTER TEST RESULTS WITH WRITE IN VIRTUAL MODE ACHIEVED

This time I did achieve a capture of the data I wrote to the virtual 2315 cartridge with no shifted bits. I set up a known pattern in a memory buffer in the 1130 and issued an XIO instruction to write to a given sector of the disk (cylinder 0, head 0 and sector 1).  After clearing out the memory buffer, I issued an XIO to read in the same sector, confirming that the contents matched what I had written - up to a point!. An offline view of the mini 2315 cartridge using the Showsector.exe program I provided confirmed the content of the sector as well. 

The 1130 wrote 159 words out of the 321 correctly - zero errors encountered. However, it did not write anything other than zeroes for the remainder of the sector. This behavior is consistent - always gets the first 159 words captured correctly and then seems to give up on the write.

DEBUGGING REASON FOR EARLY TERMINATION OF THE WRITE

Writing is supposed to commence at the end of the sector marker pulse that defines the beginning of the sector we are writing into. The 1130 should wait 250 microseconds, controlled by a timer (single shot) gate, then begin emitting the sync word pattern. From the end of the sync word detection, it should write out the 321 words requested, shifting each word out as 16 data bits plus 4 error checking bits (total 20). 

These are transmitted in the bit cells that take 1.45 microseconds each, thus each word consumes 29 microseconds and the entire sector would require 9.39 milliseconds. Before the data begins shifting out, the duration of the initial sector marker pulse (160 microseconds), the 250 microsecond timer, and then the 29 microseconds for the sync word are added on top of that total. This gives us a 9.748 milliseconds out of a 10 ms sector. 

When I looked at the logic analyzer output, I did notice that the sync does not finish until about 650 microseconds not 278.7 microseconds as I would have expected. This exceeds the time budget we have! It should result in a slightly truncated sector, but we are seeing about half a sector written before it stops. 

Thus I have identified a few issues to resolve. First, I think the bit cell duration is too long and is causing the data to spill over out of the sector. Second, it appears that the timer that controls when the sync word appears is out of adjustment, starting the data portion of the sector some 375 microseconds later than it should. Third, the write is ending about where a sector marker pulse is arriving since they come once every 5 ms or twice per sector. 

Bit Cell Timing

The original design I developed, consuming 1.45 microseconds, is the equivalent of only a 690 KHz clock rate while the internal disk drive is nominally operating at 720KHz. That is the equivalent of almost 13 words that can't be fit in the sector because of the wastered time. 

The specification of the internal drive is a bit cell duration of 1.39 microseconds at 720KHz. I can get close with a simple change to my design, providing a bit cell of 1.40 microseconds or 715KHz clock rate. I think this is close enough and will make that happen. 

The FPGA operates at a 25 nanosecond clock time, which gives me the choice of the bit cell duration being 1.375 or 1.4 microseconds. There is a way to generate a different clock frequency that yields exactly 1.39 uS but then using signals generated require synchronization because we now have two clock domains that have to interact. For the time being, I will stick with the 1.4 uS as that is less than 1% off the spec.

Duration of the Preamble Before the Sync Word

The disk rotates at 1500 RPM and has eight equally spaced notches that produce sector marker pulses. Since a rotation takes 40 milliseconds so a sector marker pulse occurs once per 5 ms. The sector marker pulse drops the -Sector Marker signal for 160 microseconds then returns it to logic high. 

One of the sector marker notches has a second notch next to it, which produces a special Index Marker pulse once per rotation. This disk controller logic increments a counter on each sector marker pulse, but resets the count to zero when it sees the index marker. That ensures that the counter is always reporting the correct sector. 

The index marker pulse also sets a divider circuit which produces a signal called -Four Sector Pulses  which skips every other sector marker. Thus, we see four of the eight sector markers on that signal line, one for each of the four sectors that we write to. 

When we write to the disk, the command specifies a sector number so that the disk controller can turn on the -Write Gate signal to start the write when we match the sector number and the sector marker from the -Four Sector Pulses signal arrives. When the sector marker pulse ends after 160 microseconds which kicks off the writing on the -Write Clock and Data line. 

A single shot timer is started when the -Sector Marker signal returns to logic high. It is set to emit an output for 250 microseconds. During this time, bit cells are being written with the data value of 0. This is roughly 179 bit cells of zero. When the timer shuts off, the disk controller logic begins writing out words, the first of which is the special sync word. 

This means that the last preamble cell ends 410 uS after the sector marker pulse began. After another 27.8 uS, the sync word has completed and the controller begins writing 321 data words each taking 27.8 uS. In an ideal world, that means the entire sector ends after 9. 361.6 uS leaving 638.4 uS of spare space. 

However, our sync word as measured on the 1130 system ended at 690 uS into the sector instead of the expected 437.8 uS point. The timer must be seriously out of adjustment. Luckily it is an adjustable single shot and I will tune it 250 microseconds. I will also verify that the sector marker pulses are approximately 160 microseconds. If they are longer, it could also be a contributor to the late end of the sync word. 

Explaining the Point Where the Write Aborted

When I look at the data that was written into RAM when the write occurred, it ends at word 159 instead of continuing to 321. This is close enough to the halfway point in the sector that it is possible that somehow the sector marker pulse that is NOT part of -Four Sector Pulses is causing the write to abort. I don't see anything in my logic that could connect that, but if the issue is in the IBM 1130 disk controller logic then it might have aborted the write by deasserting the -Write Gate signal. 

Unless I can figure out some mechanism that could cause the V2315CF to stop the write, I need to do some diagnostics with the logic analyzer to figure out why the short write is happening. I will watch the signals like -Write Gate, -Four Sector Pulses, and -Sector Marker. Hopefully I can get a quick clue that will explain why I am seeing the exact failure that is occurring.