Test build of Virtual 2315 Cartridge Facility enclosure and mini disk drive

ENCLOSURE TO MOUNT VIRTUAL 2315 CARTRIDGE FACILITY IN IBM 1130

The Virtual 2315 Cartridge Facility (V2315CF) is installed inside an IBM 1130 computer with the main enclosure, constructed of acrylic, bolted to the top of the internal 2310 disk drive of the computing system. Cables from that enclosure connect to other elements of the V2315CF, as well as to the 2310 disk drive and the 1130 system itself. The 2310 disk drive accepts 2315 disk cartridges, which enclose a 14" disk platter that holds 512K 16-bit words of 1130 data. 

The enclosure front plate houses the main electronics of the V2315CF on the left and a miniature version of the front of the 2310 disk drive on the right. Mini 2315 cartridges are inserted into the mini disk drive, in the same way the real 2315 is inserted into the 2310 drive from the front of the IBM 1130. A switch on the miniature disk drive is an analog of the motor on/off switch of the real 2310. 

The mini 2315 cartridges hold a microSD card inside them that stores the 512K words of data that would reside on a real 2315. When the mini cartridge is inserted into the mini drive of the V2315CF, the motor switch on the mini drive turned on and the switch on the main electronics panel is flipped to Load, the contents of the mini cartridge are read and copied into RAM inside the main electronics. The File Ready lamp on the IBM 1130 console turns on when the V2315CF is ready to let software read, write and seek between cylinders of the virtual disk drive. 

The V2315CF supports two modes - real and virtual. In real mode, the physical 2310 drive in the IBM 1130 is switched on with a dummy 2315 inserted. It spins and the disk arm moves around as commanded by software in the 1130, while the V2315CF transfers data from the mini cartridge instead of the disk heads of the real 2310. In virtual mode, the physical 2310 drive is not turned on, but the V2315CF instead simulates its behavior so that the 1130 software can access the mini cartridge. 

When the motor is turned off and the main electronics switch flipped to Unload, the contents of RAM, which may have been updated as the 1130 software wrote new data to sectors of the 2315, will be transferred back to the microSD card inside the mini cartridge. Thus, the data is permanently saved on the mini 2315 just as it would be on a physical 2315 cartridge used with an unaltered 1130 and its 2310 disk drive. 

PROTOTYPE ENCLOSURE LASER CUT AND GLUED TOGETHER

My friend Barry Ward cut the design on some smoked black colored acrylic and glued it together. I added the support brackets and tested the mounting of all the components. Here I am looking to discover all the interference issues or other changes that will make the production version easier to build and service. 

TESTING PROTOTYPE OF MINI DISK DRIVE DESIGNED BY BARRY WARD

Barry Ward measured the front entrance of the 2310 disk drive from the IBM 1130 system at my workshop, along with a 2315 disk cartridge, and modeled miniature versions that will be used with the V2315CF. 

The mini 2315 cartridge is 3 3/4" in diameter and proportional to an IBM built 2315 cartridge. It mounts a PCB underneath with a microSD socket, a few components and a male 2x4 header that is in the rear. That header plugs into a female socket inside the disk drive when the mini cartridge is slid into the mini drive.

The front of the disk drive in the IBM 1130 is accessed by swinging the right front door open on the 1130 system, where you see the opening of the disk drive, with a blue handle used to open and close the drive, plus a motor switch. 

The drive handle is opened in the real 2310 drive, allowing a 2315 disk cartridge to be slid into the drive or pulled out. When the handle is returned to the vertical position, the cartridge is ready to be used. 

Prototype without motor switch mounted

The motor switch can be recreated with a very small toggle switch that is only a bit out of proportion (bigger than the real drive scaled down). Barry and I did some careful modeling in CAD and he is test fitting the modified front bezel right now. 

What a real 1130 internal drive front looks like

Barry has laser cutters and 3D printers in his home (and heavier duty machinery in his workshop). He is making the next revision of the prototype while I finish the work on the enclosure and other parts of the V2315CF. 

Debugging write of Virtual 2315 Cartridge Facility - ensuring data is captured correctly

WRITING DATA EARLIER IN THE CAPTURE OF EACH WORD

My logic had been waiting until the last of the twenty bits had been captured - the 16 bits of the data word and then the four error checking code bits that validate the integrity of the data. That was unnecessary and put the request too close to the point where we reset to begin accumulating the next word. I now lock in the data value while we are starting on the first ECC bit and request the write while we are starting on the second ECC bit. The RAM controller will put the word away in RAM while we are finishing up on the ECC bits.

Since it was possible that my garbled data was a consequence of address and data bits changing too close to the time when the RAM controller is driving the write, starting earlier should eliminate this risk. I updated the FPGA logic and loaded it into the Virtual 2315 Cartridge Facility (V2315CF) main unit. I again repeated my test where I read in a sector, changed a few words and then did a write to replace the sector. 

RESULTS OF TESTING WITH THE CHANGED LOGIC

The data was still wrong, but when comparing the data on the mini cartridge after the write with the original contents, I noticed that the sector was only changed up until the halfway point. That was a major clue. I went through the entire logic for writing to a sector, including the process of storing it in RAM. I expanded my simulation testbench to track all the aspects of reading and writing to RAM as well as the SPI link data that flows between the PICO and the FPGA.

I identified two issues that have to be resolved. First, the data is not being stored in RAM correctly. Second,  if I restore the logic that locks up the disk drive and puts it off line when an ECC error is detected during a write from the 1130 to the V2315CF, the fault light goes on during the write. That means I am detecting an ECC error during the write logic somehow, although the logic analyzer trace I collected makes it appear that I should be grabbing it correctly. 

The ECC error signal is routed on the V2315CF bus connector B pin U2 which I should be able to detect with the logic analyzer. This will tell me where in the sector write the error is first detected and that may serve as a clue. 

My next diagnostic change will be to output the data bit value that was captured, using the same connector B pin U2 of the V2315CF. Syncing that with the -Write Clock Phase B and -Write Clock and Data signals being captured on connector A pin T2 and connector A pin F2 respectively, I can see any place where I DON'T correctly capture the data value coming from the 1130. The changes were made ready and the logic will be installed into the V2315CF FPGA for the next testing session. 

EXHAUSTIVE SIMULATION RUNS AND INCREASINGLY SOPHISTICATED TESTBENCH

I have not been able to cause the ECC errors to show up when simulating the logic. I have not thought of a type of glitch or timing issue in the incoming signals that should produce the error, but keep adding details to the simulation allowing me to experiment until I can recreate the failure. Hard to fix it when the nature of the failure is unknown.

I should be able to triangulate in on the cause by alternating simulation sessions with live system data collection. Fixing the issue is easy once I know what is going wrong, but the real work has been in capturing the errors. 

Deglitching the write output of the 1130 for Virtual 2315 Cartridge Facility - part 2

RESULTS OF TESTING A WRITE TO THE V2315CF USING MY NEW DETECTION METHOD

I loaded a test 2315 cartridge into the Virtual 2315 Cartridge Facility (V2315CF) in virtual mode, so that the IBM 1130 saw the disk drive as ready for activity about 90 seconds after loading. I had a few hand inserted instructions in memory to be able to test the disk.

I coded an XIO Start Read command to the disk for a full sector of 321 words, bringing the current data on the mini cartridge into memory. I then modifed a few words of the memory and changed the instruction to an XIO Start Write. This will capture the changed data from memory and replace the contents of that sector inside the V2315CF RAM. 

I can then zero out the memory location before doing another XIO Start Read, ensuring that what comes back from RAM (from the disk) is what I intended to write. If not, I can see how close or far it is from properly capturing the stream of data coming from the IBM 1130. The flag from my logic when it detects an error in the error checking (ECC) bits was routed out to a connector so that I could capture it with the logic analyzer and oscilloscope. That would tell me where in the sector it first detected invalid data. 

RESULT OF FIRST TESTS

My logic analyzer is watching the incoming data from the 1130 on -Write Clock and Data and observing the signal that is raised if the four error checking code bits at the end of each word indicate some error grabbing the word. The error signal was never raised - my logic is grabbing the data properly, I believe, and never sees an ECC error. 

However, when I read back the sector that I wrote, I get random garbage. I used my utility box to open the mini cartridge on my laptop and then examined the sector with the showsector.exe program I developed. The data matches - it is the same garbage that I see when I read the sector. The data that is being carefully assembled and error checked is somehow not getting put into RAM correctly. 

This leads to to suspect the interaction of the logic processing the write from the 1130 and the logic that updates the RAM. I will do some careful examination - the likelihood is that I am not holding the data value steady long enough for my RAM module to lock it in. I will do some simulation aimed at testing this theory and look for ways to trigger the RAM module earlier. 

BUILT ANOTHER COPY OF THE V2315CF FOR THE SYSTEM SOURCE MUSEUM 1130

Since I intend to install another instance of the V2315CF on the 1130 system up in Maryland, I wired together the entire power system, built another 2310 Interface Board and have the second main unit ready to transport once I have all the debugging wrapped up.

Final wiring of Virtual 2315 Cartridge Facility into the VCF - Infoage Museum IBM 1130

POWER FAIL PROTECTION FOR V2315CF INSTALLED

At the heart of the Virtual 2315 Cartridge Facility (V2315CF) is RAM that holds the entire contents of a 2315 disk cartridge. The persistent home for each cartridge image is on a microSD card inside the mini cartridge, but it is read into RAM when loaded so that the contents can be read and updated as IBM 1130 programs issue read, write and seek commands. After powering down the disk drive, the unload switch on the V2315CF triggers it to write the contents back to the mini cartridge thus the changes are persistent.

If system power were to abruptly fail, any changes that were made to the cartridge image in RAM will be lost since the user is unlikely to hit the Unload switch in time to have it fully written. In fact, it could produce a corrupted version, rending the mini cartridge contents lost. To avoid that risk, I designed a way to provide backup power for enough time to write the contents of RAM written back to the microSD card. We can't depend upon the operator to recognize the issue and flip the switch to Unload, so this process is automated.

I have dual power sources attached to the V2315CF main unit, one of which is a 12V motorcycle battery. The connections run through the Power Distribution Unit (PDU) PCB. A timer module is triggered by the falling edge of the 12V system power, which switches  the V231CF main unit to the battery for 45 seconds before shutting off. That is plenty of time to complete an unload of the RAM contents to the microSD card. 

A sensing circuit on the PDU pulls a signal wire down to ground at all times when the system 12V supply is on. When the power drops out, the signal is pulled up by the input pin on the PICO processor thus the code can detect the failure as soon as power drops. This does an emergency unload of the RAM back to the mini cartridge. The front panel of the V2315CF shows the unloading of the cartridge image back onto the mini cartridge. 

The final element of this power protection is a means to keep the motorcycle battery charged so that it is ready to support an emergency unload. A smart charger manages the state of the battery, doing trickle charges to keep it at the proper state of charge. That smart charger is plugged into a utility socket on the side of the 1130, inside the right side cover. This outlet is always powered, even when the 1130 system is turned off, as long as the system main power plug is connected to building power. The trickle charger does not impact the use of the battery during an unplanned power outage. 

The 1130 handling of power failures is quite compatible with this design. If the input power drops or the main power switch is flipped off, the main power rails sag rather rapidly. A sensing ciruit in the system detects this and opens a relay to disconnect the 12V and 48V supplies from the rest of the equipment. All of the bulk capacitors for the system's 12V supply are on the other side of the relay from the loads, so the power disappears quite crisply. 

There is buffering in the power supply module that converts 12V down to 5V for the V2315CF, enough to allow it to continue working while the time delay relay quickly connects the battery to the power supply module. The relay stays energized for about 45 seconds once it trips, then reconnects the V2315CF to the 1130 12V supply which is unenergized. The V2315CF turns off very soon after this. 

PERMANENTLY WIRED ALL THE PARTS OF THE V2315CF INSIDE THE 1130 SYSTEM

I placed the battery inside the 1130 at the base and secured it. I completed wiring the power supply module, timer and trickle charger together along with power down to the 2310 Interface Board. I have tested that this system works as intended thus it is time to make it permanent. I used 18ga stranded wire to make all the connections as neat as possible. 

I had worked out a way to wire everything together that only required two junctions to be made of wires; all the rest were interconnected on the power distribution board. The Power Distribution Board is designed to help with the interconnection of all these elements - 1130, battery, charger, timer, failure detection signal, 2310 Interface Board, and the V2315CF power supply module. I re-used the PCB for the power distribution board from an earlier version, but without the diodes installed. Instead, two wires tied together three holes to make the board fit the current design.

A short extension cord with a flat plug is connected to the IBM 1130 utility outlet and has the trickle charger inserted into its other end. All of the boards and components other than the 2310 Interface Board, battery and extension cord will sit inside the plexiglass enclosure that is mounted on top of the internal 2310 disk drive inside the IBM 1130. At the current time, I have not completed the enclosure so they sit atop the disk drive. 

TIGHT FIT IN FPGA REQUIRES BELT TIGHTENING OF CODE

The Lattice ICE40HX1X FPGA chip in the V2315CF main unit is limited in the capacity it provides for logic elements. Often when I make a seemingly small change in the Verilog code, during the routing and placement phases of the IceCube2 toolchain, I will get a message that the design needs more Programmable Logic Blocks (PLB) - a mix of lookup tables, flipflops and related elements. 

The chip provides 160 PLBs but recently I saw it request 167. If I work to remove some code in the FPGA that isn't strictly necessary, or recode some function in a way that needs fewer flipflops or gates, I can get it to fit. Often, it will initially claim that it needs 163 but is able to cram everything into the 160. It appears 167 is just too far over the limit for the toolchain to find a way to squeeze into 160.

This did slow me down in doing the write functional testing recently. I find that I suddenly blossom the requirements so that I can't generate the bitstream to load into the FPGA, when I whip up what should be a trivial change, such as routing a signal to an external pin or blocking the logic from considering an ECC (Error Checking Code) error to be a fatal disk failure. This just adds time and a touch of frustration to the debugging and resolution activities. 

Deglitching the write output of the 1130 for Virtual 2315 Cartridge Facility - part 1

EVALUATING STRATEGY FOR DETERMINING BIT VALUE

The IBM 1130 writes to disk alternating values on the -Write Clock and Data signal line, with a 0 always written to -Write Clock and Data during the first half which represents a self clocking pulse and then writing the inverse of the bit value during the second half. The two halves are 1.38 microsecond intervals driven by the 720KHz clock produced by the internal disk drive. That self clocking signal, delivered on the -Write Clock Phase B signal line, is 0 during the clock (first) half and then 1 during the second half when the data bit value is written.

The logic in the IBM 1130 that produces the -Write Clock and Data line is combinatorial, driving a 0 value while the -Write Clock Phase B is 0 and then outputing the current bit value, inverted, while the -Write Clock Phase B is 1. However, there are glitches produced because this is not generated by clocked logic, so time delays in signal propagation produce some glitches that are too fast for the internal disk drive circuitry to react to. 

During the low phase of -Write Clock Phase B the output of -Write Clock and Data is low. In the high phase of the clock, we drive -Write Clock and Data low during a write in one of two cases, represented by the two A (and) gates on the left. The bottom one takes the bit being shifted out of the data register during the first 16 clock cycles of a word. 

The top one is used during the last four cycles, those that will produce the error checking code. As long as the total count of 1 data bit values sent is not an even multiple of four, -Zero Check Count is high causing the -Write Clock and Data value to be low producing a 1 bit. As soon as the total count becomes 0 modulo 4, -Zero Check Count is low which blocks the upper gate from emitting any further 1 bits. The remaining ECC bits are therefore seen as 0. 

Other factors contribute to glitches as well during the data (second) half. Any glitch in the -Write Clock Phase B signal as received by the 1130 will falsely flip the gates to pass through a 1 as if it were the clock half instead of part of the data half. A signal flaw in -Write Clock Phase B produces a spurious 1 bit value if it happens when we are evaluating the signal -Write Clock and Data as the data bit value. 

To bolster the reliability even further, I introduced a method that could block the effect of most short term glitches. When the -Write Clock Phase B rising edge occurs, we begin counting all the FPGA clock cycles (one per 25 ns) where -Write Clock and Data is low, that is has a bit value of 1. When we get to the end of the data phase and -Write Clock Phase B has dropped to low, we judge if we saw a 1 by whether the count of cycles with a 1 detected is more than 15 out of the 29 cycles during which the data value is being transmitted. 

I found a theoretical vulnerability in how I implemented the detection algorithm. If we have a glitch in the -Write Clock Phase B such that it drops low for a cycle or two when we should be in the data phase, this can interfere with the counter mechanism I used. I reset the count when I see a rising edge of the clock; if we had a glitch that dropped the clock and then it goes back to its correct high value during the data phase, the counter gets reset to 0. If the glitch happens later in the data phase, even with zero glitches during data we can't count high enough to meet the bar for detecting that the data bit value was 1. 

Late glitch guarantees bit value seen as 0

The graphic above shows the -Write Clock Phase B signal, where the high portions are when we should be looking for a low value on -Write Clock and Data to count it as a possible data bit of 1. When a glitch happens relatively late in the high portion of the clock, the count is reset and cannot count high enough to achieve the minimum of 15 detections even if the data signal -Write Clock and Data is low for the entire time of the clock phase. 

The reality for this project is that I generate the -Write Clock Phase B inside my FPGA, thus I do have a perfect internal clock that I can use to drive the decoding. This reduces the impact of glitches, as they are only seen on the incoming -Write Clock and Data line. These can be induced by glitches in the -Write Clock Phase B as it is used inside the IBM 1130 disk controller circuitry, but that is the purpose of my counter and threshold logic. 

EXAMINING LOGIC ANALYZER OUTPUT TO EVALUATE METHODOLOGY

My current design looks at the value of the -Write Clock and Data signal at the time that the -Write Clock Phase B signal has a falling edge. If -Write Clock and Data is low, I record it as a bit value of 1, inversely a high signal denotes a bit value of 0. 

I converted the logic analyzer data to a spreadsheet,  hiding all captures except when the -Write Clock Phase B signal changed from 1 to 0. I took the inverse of the -Write Clock and Data signal as the bit value. After the correct interval for a string of all zero bits, I saw the proper sync pattern which is a 1 bit followed by the four ECC bits of 1 1 1 0 and thus could interpret all the following data bits as words. 

I recorded the bit values as they would be interpreted by my logic, counted the number of bits in each block of 20 that had a value of 1, and checked that this count was 0 modulo 4 which is the error checking algorithm. I also verified that the data that would be captured was exactly what was in memory when I issued the XIO Start Write command on the IBM 1130 to do the write. 

It all looked as if it would be perfectly recorded using the algorithm, in spite of the fact that the V2315CF was flagging an ECC error on the read. The timing was correct as well - the entire sector of 321 words took 9.311 milliseconds from the beginning of the first word until the end of the final word (321). With 10 ms available for a sector, this was exactly what I would expect. I also checked the time between words.

To help evaluate what is taking place, I temporarily blocked the ECC error flag from triggering a disk fault. That will allow me to read back what we wrote and compare it. If I see any words that don't match what I had in memory for the write, that may suggest where to look further. I also brought the ECC error detection signal out on the main V2315CF box on connector B pin V2 so that I can spot it on the scope and logic analyzer as it is turned on. Next session I will make use of this modified logic to test how well my logic does the job and whether there are any further subtleties I need to address. 

Debugging 1130 disk controller logic concerning -write gate malfunction part 2

WHAT I OBSERVED MONITORING THE SIGNALS INVOLVED IN -WRITE GATE

In my last post I discussed the circuits that generate the -Write Gate signal from the IBM 1130 disk controller logic that is continually triggering my Virtual 2315 Cartridge Facility (V2315CF) to perform a write. I can see the signal is at logic low level but it should not be until the short time when the 1130 has executed an XIO Start Write instruction and the virtual disk rotates to the sector that is requested in the instruction. Otherwise it should be high. 

This turned out to be an issue with a cable not fully plugged in. Once I discovered this and monitored the write select latch, I saw it correctly turn on when the virtual disk platter entered the requested sector and it turned off at the end of the write operation, simultaneous with it raising a request for a interrupt on level 2 to indicate the completion of the operation to the 1130. 

TESTING A WRITE RAISED A DISK FAULT ERROR

My logic captures each word of the sector as it is 'written' by the IBM 1130 disk controller logic. Each word from the 1130 is followed by four error checking bits. The error checking bits are used to validate that the number of bits with a 1 value are an even multiple of four after counting all 20 bits - 16 for the data in the word and the 4 error bits. If this check fails, I report an ECC error on the write and turn on the disk fault latch. 

The V2315CF lights the FAULT indicator and locks out any further operations on the virtual 2315 disk cartridge when that happens. I have to unload and restart the virtual disk drive to clear the lockout. 

I put the logic analyzer on the signals coming into the 1130 disk controller to see what was coming out of the 1130 that my logic will have to decode to capture the data being 'written' to the sector on the virtual disk. Based on that I was able to figure out a better way to grab the bit values, based on what was actually emitted by the 1130. 

I updated the logic of the V2315CF and changed the simulation to match the relative timing of the signals that I observed coming out of the 1130. When it was all working as intended I created a new bitmap to load into the V2315CF. Next session will see how it works. It does appear that read and seek are solid, thus this is the last bit of the functionality to iron out.

RESTRUCTURED FPGA CODE FOR V2315CF

When external signals are used in a clock synchronous circuit such as an FPGA, the risk of a signal transition almost exactly at the same time as a clock edge must be managed. When an input to a logic gate changes too close to the clock, the flipflop can assume an intermediate metastable state which is not valid for use by the following logic elements. 

To combat this, a chain of several clocked flipflops is used to reduce the chance of a metastable output to near zero. In most of my designs, this is a series of four in a row, using only the output of the fourth to drive my subsequent logic. This synchronizes the input to the clock domain of the FPGA. 

The IBM 1130 and 2310 internal disk drive signals are unsynchronized with respect to the FPGA clock thus they need this processing. There are 17 input signals to the V2315CF of this type. I had scattered the synchronization chain for the input signals among the various functional modules in my FPGA code. In a couple of cases, I noticed that this would take a signal already processed by one chain and pass it through a second chain of four clocked flipflops. 

I decided that I would create a serializer module to implement the four clocked flipflops and instantiate that for each input signal in my top level verilog code, rather than embedding it througout the various lower level modules. The 15 serializer instances ensure that any signal that is used by any logic in my code is properly synchronized and has the risk of metastability properly managed. 

A chain of flipflops to synchronize a signal like this is coded in verilog as a four bit vector, e.g metasignal[3:0],  inside a clocked loop. On each cycle, the vector is shifted left one bit and the input signal is added to the end. The first position is therefore the fourth flipflop in the chain and that is the output to safely use. This does create code that refers to the signal after synchronization as something like metasignal[3] which is less intelligible than if a simple signal name were used. My serializer produces a simple name for the output, hiding the four bit signal vector inside the serializer, thus making my code easier to read. 

The logic had done edge detection of signals by comparing the value of metasignal[3] to metasignal[2], but that takes away one flipflop from the synchronization when looking at metasignal[2]. After my restructuring, any logic that needed to detect an edge would be saving the output of the serializer on each pass through a clock loop and comparing the current serializer output to the saved output of the last pass. This means that both signals had at least four passes through the flipflops. 

I ran all my simulation testbenches against the code to ensure that I didn't make any errors when coding edge detection. Once everything was meeting my requirements and working properly, I put the restructured logic bitstream into the V2315CF FPGAs. 

Debugging 1130 disk controller logic concerning -write gate malfunction

WRITE STEADILY COMMANDED AS VIRTUAL 2315 CARTRIDGE FACILITY BECOMES READY

After I enabled my logic to begin testing the write functionality, because my FPGA logic had a temporary block on it, the WR indicator on the main box of the Virtual 2315 Cartridge Facility (V2315CF) lit up steadily. That stopped the FPGA from properly processing read or seek functions. 

I spent some time verifying that the signals were routed properly from the cable in the 1130 disk controller through the 2310 Interface Board and the main unit of the V2315CF. I checked the routing in the boxes and the termination resistors. Eventually I determined that the signal was incorrectly generated by the 1130 disk controller logic and was not a fault in my project. 

COMPLEX LOGIC RELATED TO WRITE SIGNAL

The -Write Gate signal is produced by combining the +Write Select signal with the 90 second timer that allows the disk drive to fully purge dust before it loads the heads and becomes ready. It asserts the +File Ready signal to indicate that the 1130 can use the drive. 

As soon as +File Ready went on, the -Write Gate was turned on (logic low) and began driving the V2315CF to perform a write. It was due to the +Write Select going high and the source page of the Automated Logic Diagrams for this is complex, with several interlocking flipflops. The gates involved and signals are spread around on the page making it hard to understand how it all works. 

In order to understand it during any debugging, I pulled the page apart and reorganized the gates so that the logic behind each flipflop and latch was easy to understand. The first issue I discovered was right at the last bit of circuitry, the Write Select Latch that generates the +Write Select signal.

WRITE SELECT LATCH SIGNALS ARE SEEMINGLY CONTRADICTORY

This is a classic latch as used by IBM in that error, formed by wiring together combinatorial gates in a loop. In this case, a NAND, an OR and a NOT gate form the latch, with the loop indicated in the picture above with the green highlighting. The OR gate is how the latch is set; the upper NAND gate will set the latch through the OR gate when both of the upper flipflops (R-W Op and R-W Select) are set. The lower NAND gate is how the latch is reset. This happens when either -DC Reset 3 or -Four Sector Pulses go low. 

The -DC Reset 3 is asserted low when the machine powers up and any time the 1130 RESET button is pushed. As the 2315 disk cartridge rotates in the disk drive, four 165 microsecond pulses are produced per rotation, one each 10 milliseconds or 1/4 turn, at the start of each sector. The -Four Sector Pulses signal goes low to form the sector pulses. That resets the latch at the start of the sector marker pulse since we don't want to continue writing when we get to the end of a sector. 

I put the oscilloscope on the +Write Select signal and the -Write Select Latch signal, the first produced by a NOT gate from the second signal. What I found was that both signals were the same but that could be because there is no pullup resistor on the signal line. IBM's Solid Logic Technology (SLT), used in the 1130, is a form of Diode-Transistor-Logic which is insensitive to a voltage for the high logic level, nominally 3V. 

All that matters to activate a gate is that a current is sunk by the driver circuit from the input line. As long as the voltage on the input side is low enough that the diode in the input conducts, and the current that can be sunk by the driver at that voltage is high enough, it triggers the SLT gate. 

Looking at the driver side of the diode in the SLT gate, when the conditions are not right for the diode to conduct, might show no voltage at all. A pullup resistor on the driver gate may establish the nominal 3V high level, but without a pullup it could show as 0. Unless we can measure the current flow into the driver gate, we can't tell if it is conducting or not. 

The signals were not as they should be, perhaps due to this oddity of SLT logic. If the latch is indeed on, I need to figure out which of the two flipflops that activate it is turned on and causing the latch to set. That is, the R-W Op or the R-W Select would have to be turned on to cause the Write Select Latch to be set. 

This presents some difficulties because there is no pin assigned to either of those flipflops. The only way to observe the flipflop state would be a test point on the edge of the card, something very difficult to attach to. However, I might be able to infer which is active if I can see that the signals which activate the flipflop are in the correct configuration. 

R-W OP FLIPFLOP LOGIC STUDIED

The flipflop is turned on if the 1130 is executing an XIO instruction requesting a disk write, turned off either when the 1130 is executing an XIO requesting a disk read or when -File Reset is asserted. For either the XIO read or XIO write, as part of the execution the disk controller issues a short pulse to load the memory address for the data using the -File Load SP pulse. At the end of processing either a read or write, the disk controller asserts the -File Reset low. 

Thus I have to monitor the four signals that would activate the flipflop. If the flipflop itself is defective and not turned on by its input signals, I would not see it unless I can somehow connect to the testpoints. 

R-W SELECT FLIPFLOP LOGIC STUDIED

I can't directly see the state of this flipflop either but most of the inputs that wouuld activate or reset the flipflop are accessible; unfortunately the R-W Op flipflop is one of the sources, which I explained in the section above is difficult to observe. The R-W Select flipflop is turned off either from the -DC Reset 3 system wide reset signal or when read or write completes by asserting the -Int Req Lvl 2 to raise an interrupt to the 1130. 

Setting the R-W Select flipflop occurs only when the sector marker pulse begins at the start of one of the four sectors on the disk. Another flipflop, R-W Req, must be on. If  the sector number that the XIO instruction requested matches the sector that is just about to start (+Sector Equal) and the disk arm is settled, either the top or bottom NAND gate is active, based on the state of the R-W Op flipflop. That active NAND will turn on the R-W Select when the sector marker pulse begins. 

The overall logic is that the XIO instruction for read or write will set the R-W Req and because the type of data transfer is indicated by the R-W Op flipflop, the R-W Select turns on right at the start of the correct sector that the instruction has requested. The request (R-W Req) could be active for a majority of a disk rotation until the target sector arrives. Finally, the write select latch is set when the R-W Op flipflop indicates that a write was requested and the R-W Select flipflop turns on because we are at the correct sector to do the write. 

R-W REQ FLIPFLOP LOGIC STUDIED

The R-W Req flipflop is set when the -File Load SP pulse occurs during the XIO instruction execution, when it is either a read or a write XIO. It is turned off when the data transfer completes and -File Reset is asserted, or when the R-W Select turns off because we hit the next sector marker while still processing the read or write. I can monitor the R-W Req flipflop state as well as the R-W Select and other signals that drive the R-W Req flipflop state. 

READ CHECK FLIPFLOP LOGIC STUDIED

There is one final flipflop on the ALD page, but it is only involved with an XIO read instruction. One can set bit 8 in the control field for the XIO Read instruction to request that it does not transfer the data, it just reads the disk. This validates that the sector has valid error correction bits otherwise the drive will flag the error. 

When the -File Load SP activates during the XIO instruction execution, if bit 8 of the control word was on, Read Check flipflop is turned on. If it is a write rather than a read, then this is ignored, which is why they don't involve the XIO write signal. The flipflop is turned off either when the -Int Req Lvl 2 turns on or the -File Reset signal is turned on at the end of the operation. I won't need to debug this flipflop. 

NEXT SESSION I WILL DEBUG THE SIGNALS ABOVE TO FIND THE FAILURE

When I get to the shop on Tuesday I will check all the signal sources and behavior of the circuits studied in this post. I will report on the results in the next blog post.