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. 

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

RESEATED CARDS AND CABLE CONNECTORS IN 1130, RESUMING TESTING

I pulled out some of the SLT cards to gain access to gate A compartment C1 of the 1130 where the disk controller logic is housed and where the signal cable from the V2315CF is plugged in. As previously reported a couple of cables had come loose from the compartment, I believe when I was testing my 1627 plotter controller card project. 

ERRATIC INDICATOR LAMP INDICATES SHORT TERM GLITCHES ON A SIGNAL

The RD lamp on the main box of the Virtual 2315 Cartridge Facility (V2315CF) lights when the 1130 asserts the -Read Gate signal asking for the upcoming sector to be read into 1130 main memory. This is triggered by the falling edge of that signal and remains on for two rotations of the disk, about 80 milliseconds so that it is detectable. 

The lamp was flickering on and off, although the V2315CF did not treat this as a valid request for a read otherwise. I realized it was due to very short term glitches on the signal line. My FPGA logic for reading will immediately return the state machine to its idle state if the request has dropped before it is time to send the sync word to the 1130 disk controller followed by the 321 word sector data. It did not extinguish the RD indicator, however.

ADDED DEBOUNCERS FOR BOTH READ AND WRITE SIGNALS

I added in my debouncer module that requires a signal to be steady on or off for 500 nanoseconds before switching the output to that state, monitoring both the -Read Gate and -Write Gate control signals. The time scale of disk input-output operations is much larger than this delay. One word coming from disk requires about 27.8 microseconds to be read, a single bit about 2.78 microseconds, thus if the control signal drops in 0.5 microseconds it is quick enough to stop at the same bit as if it were undelayed. 

Further, operations like read and write are requested by the disk controller activating the control signal but don't actually begin until the sector marker for the next sector arrives, telling the controller that the read/write head is just starting into a sector. I changed the start of the indicator lamp activation until this further point - thus it turns on when a read or write is really in process not just a few milliseconds before as it did in the previous version of the logic. 

I simulated these, introducing various glitches and measuring the timing of the logic that performs the read or write operations. Once satisfied, I prepared a new bitstream to load into the FPGA in the V2315CF. 

SOMETHING WRONG WITH -WRITE GATE CONTROL SIGNAL

I put the oscilloscope on several signals coming from the disk controller logic and watched the correct operation of the -Read Gate as well as some others. However, the -Write Gate signal, which should be logic high and only drop to low as a trigger for a write, was permanently low and not changing. 

When I next get to the shop, I will chase this down to locate the fault and correct it, so that I can test out both read and write operations now that seek seems to be solid. 

Completed my EDUC-8 computer based on Electronics Australia articles starting August 1974

ONE OF THE VERY FIRST HOME COMPUTER DESIGNS

The most well known of the early home computer designs is the Altair 8800, a kit from MITS that was publicized in an article in Popular Electronics on January 1975. It was a machine designed around a microprocessor, at the start of a groundswell of homebrew computers being built based on microprocessors - the Apple 1 was developed just a few months after the Popular Electronics Altair 8800 article.

A slightly earlier design, the Mark-8, was released in Radio-Electronics on July 1974. It was a do-it-yourself design, unlike the complete kits for the Altair 8800 that could be ordered from MITS. It too was based on a microprocessor. Few people know of this earlier home computer design, but the Mark-8 did precede the Altair 8800 by about half a year.

There were a few early home computers that were not based on microprocessors. These require many more components to implement a complete computer rather than leveraging the integration of many of those into a single microprocessor chip. A commercial product, the Kenbak-1 was released 1971. It was designed as a trainer, to allow a buyer to experiment with computer concepts. Because of the large parts count multiplier of a non-microprocessor design, these tend to have much simpler architectures and capabilities than the microprocessor based systems. 

The first do it yourself design of a non-microprocessor based computer was published in a series of articles in Electronics Australia magazine, beginning in the August 1974 issue. This was the EDUC-8 which was designed as a simplified version of the DEC PDP-8, a very popular commercial minicomputer. The PDP-8 was sold starting in 1965, at a price tag of $18,500 which is around $190,000 in today's dollars. Being able to build a similar computer for a sliver of the cost was the promise of the EDUC-8. 

The first PDP-8 was a bit serial design, meaning that the adder and other data paths are single bit so that 12 bit word is shifted bit by bit through the system - as a result it wasn't very fast. The EDUC-8 is similarly a serial single bit design, even slower than the PDP-8. Overall, it implements the instruction set of the PDP-8 but lacking a few details and implements 8 bit words rather than 12 bits. 

It offers a full 256 locations of memory and executes instructions at the rate of 10K per second or 100 microseconds each.  The machine has 16 words per page because the instructions that have memory addresses are only given 4 bits in the instruction word. Like the PDP-8, one can link to other pages of memory thus utilizing the full 256 words. 

It has a program counter (PC), an accumulator (AC), plus a memory address (MA) and a memory buffer/contents (MB) registers. There are all 8 bits. 

Because instructions can use indirect addressing, the instruction word has only 3 bits for instruction type, one bit for indirect and four bits for the word within a page of memory. A direct instruction selects within the current page based on the four address bits in the instruction. An indirect instruction allows the full 8 bits of the address to be put in the MA (for a memory reference) or the PC (for a jump), thus one only moves to a different page (16 words) using indirect addresses. 

Just like the PDP-8, the instructions seem a bit odd because there are so few types supported.

• TAD (Twos Complement Add) - takes the data at the memory address and adds it to the AC
• DCA (Deposit and Clear Accumulator) - stores the value of AC into memory and clears AC to zero
• AND (logical AND) - takes the data at the memory address and does a logical AND with the AC
• ISZ (Increment and Skip if Zero) - adds 1 to the data at the memory address, skips over next instruction if the result in the AC is zero.
• JMS (Jump to Subroutine) - stores the next instruction address in the memory location, then jumps to the address after the memory location
• JMP (Jump) - executes the next instruction at the memory address
• OPR (Operate) - two groups, each uses the 4 address bits of the instruction to perform certain functions.
• IOT (Input Output Transfer) - can control two input and two output devices

The OPR groups are a kind of microprogramming, in that the programmer can specify come combinations of the four functions in each group to be performed at the same time. 

Group 1 (OPR with bit 4 = 0):

• CLA - clear accumulator (bit 3)
• CMA - complement accumulator (bit 2)
• RAL - rotate accumulator left 1 position (bit 1)
• IAC - increment accumulator by 1 (bit 0)

Group 2 (OPR with it 4 = 1):

• SZA - skip next instruction if AC is zero (bit 3)
• SMA - skip next instruction if AC is negative (bit 2)
• RAR - rotate accumulator right 1 position (bit 1)
• HLT - stop execution (bit 0)

Within a group, one can combine the functions in certain ways. Coding bits for both CLA and IAC will put a 1 in the AC. Coding bits for both CLA and CMA will put all ones in the AC. CMA and IAC will put 10000000 in the AC. Coding both SMA and SZA will skip the next instruction if the AC is zero OR minus. 

For the IOT instruction, bit 4 is 0 for input devices and 1 for output devices. Bit 5 selects which of two devices of that type are selected. The device provides a flag bit that can be interrogated by the IOT instruction or cleared. Bit 0 causes the next instruction to be skipped if the device's flag is set. Bit 1 causes the data from the device to be put in the AC if an input device, otherwise outputs what is in the AC to the device. Bit 2 clears the flag of the device. Bits 1 and 2 can both be set to transfer between the AC and the device and simultaneously clear the flag. When outputting from the AC to the device, the AC will be zero after execution. 

The front panel of the EDUC-8 displays the PC, MA, MB and AC registers in a grid of 32 LEDs. It has an LED to indicate which of the eight operation codes is being executed (e.g. DCA or OPR). Four status LEDs show status - RUN is off when it halts, FETCH shows it is using the PC as the address in the MA to get the next instruction in the MB.  EXECUTE is one when it is performing the operation using the address from the instruction in the MA and fetching or updating memory through the MB. DEFER is on if the address from the fetched instruction is indirect, thus that value is put in MA and the indirect results come from the MB. 

• Front panel switches include eight toggle switches to set bit values for bits 7 to 0
• Load Address to put the toggle switch value into PC
• Examine to put PC into MA to display the value in that address in MB
• Deposit to put the toggle switch value into memory at the location in the PC
• Step/Continuous to choose to single step or run the program until it halts
• Fast/Slow to run at the full 10KHz rate or slow enough to watch each bit shift through the registers and all the phases of the instruction execution
• Halt to turn on the halt flag just as if an OPR with HALT was executed
• Run to either execute a single instruction or start running
• Normal/Page Zero to force all memory references to the first 16 words (page 0)

Programmers of the EDUC-8 use octal to refer to the values in an 8 bit word, but in an odd format I will call 3-2-3. The first octal digit specifies the value of bits 7, 6 and 5. The second octal digit specifies the value of bits 4 and 3 (thus it can only have octal values 0, 1, 2, or 3). The third octal digit specifies the value of bits 2, 1 and 0. 

MODERN PCB LAYOUTS PRODUCED BY ENTHUSIASTS IN AUSTRALIA

Gwyllym Suter, an enthusiast of the EDUC-8, created KiCAD designs that matched the one-side PCBs shown in the articles. He and others such as Steven Pietrobon have worked out the means to build one today, giving tips on replacements for any parts that are too obsolete to find readily. I came across Gwyllym's work, conversed with him and decided to build my own EDUC-8. 

WRAPPING UP CONSTRUCTION OF MY EDUC-8

I had the chassis and electronics working quite a while ago, but never finished a case to house it until last week. I had a box that was the correct size, with a few tweaks such as cutting away some plastic around the front opening. I was able to fit my EDUC-8 into the box and thought it looked pretty good. 

The original design had a traditional power supply to drop the wall socket power down and produce 5V to power the EDUC-8 system. It had a crowbar protective circuit in addition to an overly beefy design with a 5A slowblow fuse that sits between the transformer dropping line voltage to around 20VAC and the power supply board. Unfortunately, I found this supply to be tempermental, blowing the 5A slow blow fuses often with no apparent justification. I removed it and wired up a 5VDC wall wart instead, which gets the job done without the hassle of mystery fuse blowing events. 

I need to add a fastener to hold the chassis in the opening and want to add some opaque material between the faceplate and the front panel PCB with its LEDs. Other than those two tasks, it is complete and I can carry it around to retro computing events as an interesting curio. 

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

HAD NARROWED THE PROBLEM DOWN IN PRIOR SESSION

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

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

WORKAROUND DESIGNED AND TESTED

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

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

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

LOGGING SEEKS IS COMPLICATED COMPARED TO THE ORIGINAL RK05 DISK EMULATION

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

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

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

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

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

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

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

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

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

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

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

SIGNALS BEING OBSERVED AND THEIR PURPOSE

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

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

SIGNAL RINGING, DISTORTION OR SWING LIMITING IDENTIFIED

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

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

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

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

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

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

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

DECISION ON TERMINATION FOR EACH SIGNAL

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

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

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

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

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

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

Loose connectors

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

RETEST UNDER VIRTUAL MODE TO BE CERTAIN IT WORKS PROPERLY

I ran the same loop seeking in and out by the same number of cylinders, initially 200 then other values - to be certain that the Virtual 2315 Cartridge Facility (V2315CF) is handling seeks properly in virtual mode where the physical disk drive is not spun up. 

I detected two problems. First, my logic is sending the seek requests to the drive even though it isn't spinning, and to my surprise the solenoids that lock the arm into various positions were buzzing away. Second, when single stepping through the program, the V2315CF tracked the intended disk arm position properly, but when I ran at full speed, it got out of sync. 

BLOCKING SIGNALS TO THE DISK DRIVE WHEN IN VIRTUAL MODE

It was simple enough to fix the first issue. I don't emit the -Access Go, -10/+20 Mil, and -Rev/+Fwd to the disk drive while in virtual mode. The only things I emit concerning seeks are +Access Ready feedback and the state of the +Home signal, sending those to the IBM 1130 disk controller logic. 

LOOKING INTO HOW THE SEEK SHADOWING WORKS DIFFERENTLY IN VIRTUAL MODE

I looked over my logic to see where it performs differently and how that might lead to miscounting. The obvious spot was that in real mode, after I update the cylinder number at the time when +Access Ready goes low, I wait the approximately 10 milliseconds for +Access Ready to return to logic high before deciding that a seek step is complete. In virtual mode, I immediately ended the seek when I updated the cylinder address as +Access Ready went low. 

That opens a window for glitches on the -Access Go line from the 1130 to trigger a spurious seek step. I changed the logic to wait until the seek timer gets to zero - that is when I return +Access Ready to logic high and that is the equivalent wait I do in real mode. The only difference is that +Access Ready comes from the disk drive in real mode and is derived from a 14.5 millisecond seek timer in virtual mode. 

RETESTING WITH CHANGED FPGA LOGIC

I introduced those changes and fired up the V2315CF in virtual mode to run my program that seeks back and forth by 200 cylinders. I was looking for the internal drive to remain quiet - no solenoid activations - and for the cylinder address shadowed by V2315CF to match what the program was doing. I tried this with 200 cylinder seeks and then with a few shorter ones so that I could move between two positions that did not include the home cylinder (0). 

I observed that the +Access Ready signal is not pulled up to 3V, it is sitting down around 1.4V when logically high. This is confusing the logic in the V2315CF trying to shadow the movements. There are no terminator resistors on this line, but if I add the standard pair back, virtual mode works properly. The consequence of that is disabling real mode, because real mode couldn't get the signal down close enough to ground to register with the IBM 1130 disk controller logi as a logic low. 

Rather than use a pair of resistors, pullup to 5V and pulldown to ground, establishing a termination impedance, I just installed a weak (10K) pullup on the board. This appears to have solved the issue for both modes - real and virtual.