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. 

Troubleshooting the logging function of the Virtual 2315 Cartridge Facility

DEBUGGING CAPABILITIES BUILT INTO THE V2315CF

The Virtual 2315 Cartridge Facility (V2315CF), built around an FPGA, a DRAM chip and a Raspberry Pi PICO, has a serial debugging output available that logs both status and error messages as the unit does its work. It has the capability to log each seek, read and write to the same serial port if I type the letter L into the serial terminal to request logging. 

The FPGA logic that processes read, write and seek operations emits a short pulse for each of those events. These are ORed together and output on an FPGA pin as CMD_INTERRUPT. That pin is routed to pin 6 of the PICO, which is general purpose IO (GPIO) 4. The FPGA is communicating with the PICO over an SPI link, driven by the PICO. 

The PICO is configured to call a routine when there is a rising edge on GPIO pin 4. That routine requests data from the FPGA over SPI and then issues a message on the serial port that indicates whether it was called due to a seek, a read, or a write, accompanied by the current cylinder, head and sector. 

LOGGING IS FAILING TO WORK

All the software in the PICO and the logic in the FPGA appears correct. It used to work a few months ago, but recently it does not. I put a oscilloscope on GPIO pin 4 (CMD_INTERRUPT). The line is steadily high, which is not correct. Without a rising edge, there will be not interrupt and the callback routine won't execute to log the status. 

The same logic that emits the pulses for seek, read and write also drives the indicator lamps RD, WT and SEEK on the V2315CF front panel. Those indicator lights work correctly! I don't know why the signal isn't working correctly into the PICO.

There are a few possibilities. I have already replaced the PICO so it is not that bit of hardware. There could be a short somewhere on the PCB that is driving CMD_INTERRUPT high in spite of it being logically low in the FPGA code. There could be a failure in the FPGA chip itself that is producing a high output incorrectly. There could be some weird Lattice toolchain issue causing the FPGA to not do what I coded. Or, there could be some other kind of unexpected gremlin.

QUICK MODIFICATION TO SEE WHICH OF THE THREE OPERATIONS ARE HIGH

If there is some flaw in the FPGA logic such that one of the lines - seek, read or write - that should be pulsed high temporarily is instead permanently high, I can at least narrow things down to which line is bad. I modified the FPGA and the PICO to add a new SPI transaction type which will return the seek, the read and the write status lines separately. The PICO will output that information periodically with its normal status message over the debugging serial link. 

What I observed was that my output indicated that all the signals were low inside the FPGA, thus the output from the FPGA should be low, however it was logic high continually. 

TRYING THE OTHER V2315CF UNIT

I am building two V2315CF units, one for the Infoage/Vintage Computer Federation museum and one for the System Source Museum. I therefore have two main units constructed. If I swap them on the 1130 I am debugging with, I can rule out FPGA hardware and motherboard trace issues, as the problem will only remain if it is a defect in the logic in the FPGA or the code in the PICO or the toolchain. If the problem disappears, I then need to do some detective work to identify the actual failing part. 

When I ran with the other V2315CF unit, logging worked perfectly. It is therefore an issue with the FPGA or the board traces. As this works well other than the logging, I wouldn't replace the FPGA to cure this, but if I spot something on the board that can be remedied I will. 

Testing my new seek logic for the Virtual 2315 Cartridge Facility - 16 and now works correctly in real mode

TESTED LOGIC REFINEMENT FOR SEEK SHADOWING IN REAL MODE

The Virtual 2315 Cartridge Facility (V2315CF) monitors the seek commands sent from the IBM 1130 system to the 2310 internal disk drive. It has to shadow the position of the disk arm on the 2310 so that it always knows where the heads are positioned. This allows the V2315CF to emit the proper data stream when the 1130 reads from the disk. 

The 2310 records four sectors on the top read/write head at each cylinder, with another four sectors on the bottom head. With 203 cylinders available on the 2315 disk cartridge that is inserted in the drive, it holds 1,624 sectors in total. Each sector holds up to 321 words of data - a word being 16 bits in the 1130. Thus the capacity is about 512K words (1 Mbyte) for each 2315 cartridge. 

The V2315CF has to know which cylinder is under the 2310 disk heads, so that when the 1130 selects the top or bottom head and turns on a read as it reaches one of the four sectors on a cylinder, the appropriate data from the virtual 2315 cartridge image is delivered to the 1130. The V2315CF sees which head by receiving the -Head 1/+Head 2 signal plus keeps track of the -Sector Marker and -Index Marker pulses to know when it is beginning a given sector. Combining this with the shadowed cylinder number allows the V2315CF to retrieve the appropriate sector data from the RAM inside the V2315CF and deliver it to the 1130. 

I made a number of changes to the logic in the V2315CF which monitors the seek commands that flow between the 1130 system and the 2310 disk. Because we see what is sent to the disk drive, as long as the drive correctly moves the arm we should be able to keep our shadow cylinder number in sync. Various glitches were causing the shadow and real cylinder locations to diverge. My changes were intended to eliminate these situations so that the shadow cylinder always matches the actual cylinder of the disk arm. 

SHORT PROGRAM CYCLES THE ARM BETWEEN TWO CYLINDERS

A program will move the disk arm forward by some number of cylinders, then when the drive reports successful completion, it will move the disk arm in reverse by the same number. It then repeats, so the arm should be zooming back and forth between two set cylinder locations. At any time, stopping the program should leave the arm at one of the two positions. 

The IBM 1130 allows the program to request a forward or reverse seek of any number of cylinders up to the maximum  possible movement of 202. The 2310 disk drive only supports moving one or two cylinders in a step. Thus, the 1130 iterates stepping the arm until the full count requested by the program has been accomplished. Moving one cylinder is only done as the first step of a seek and only when the count from the program is an odd number; all other steps are two cylinders at a time. 

The direction and size of each step is controlled by -Rev/+Fwd Direction and -10 Mil/+20 Mil Step signals. The actual request to take a step is sent with -Access Go from the 1130 with the 2310 providing feedback using the +Access Ready signal. Our shadowing of the arm movements will observe each falling edge of -Access Go to begin, change the shadow cylinder number based on direction and step size, then end the step after a complete down and up cycle of +Access Ready. 

Short glitches on these signals are ignored by the 1130 and the 2310 logic circuits, but have tricked the FPGA logic into falsely triggering a step or ending one prematurely. I improved the debouncing functions and added safeguards that should eliminate the impact of short term glitches. 

OBSERVING THE PROGRAM CYCLING BETWEEN CYLINDERS

The V2315CF and the disk arm agreed perfectly. I ran fast and slow patterns, always getting agreement between V2315CF and the disk arm. I seem to have developed a solid approach now. I will do a check for virtual mode when I next get to the shop, followed by running the IBM disk diagnostic program (309) which will validate every aspect of the disk drive. When that runs clean in both real and virtual mode, I move on to wrapping up the project.

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

FPGA IN V2315CF UPDATED TO WORK WITH ELECTRONIC SWITCH VERSION

The FPGA inside the main box of the Virtual 2315 Cartridge Facility (V2315CF) was loaded with the updated logic that renders the output drivers of the box inert for signals that are directly connected in real mode between the 1130 and the 2310. This resolved a problem seen in the last test session, where I two sources were driving signals in opposite directions. I also added in the version of the seek shadowing logic that was hoped would be impervious to glitches. The terminator resistors were installed only on the signals that require them. 

TESTING WITH HAND ENTERED ACCESS PROGRAM

I ran the hand entered code that will repeatedly drive the arm between cylinder 0 and cylinder 200 as long as the 1130 is in run mode. The disk performed exactly as requested, stopping each time at 0 or 200, but the V2315CF got out of sync a bit. It recorded the lowest cylinder location as 2 and the top location as 202. Once it was out of position, it never locked in to cylinder 0. 

OBSERVATIONS OF SHADOWING IN THE V2315CF AS THE ARM MOVES

The logic in the V2315CF can observe the microswitch that turns on the -Home signal to logic low when the arm is at cylinder 0. Based on that, I can reset the current cylinder to 0 when we are beginning a seek when -Home is asserted low. That would have solved this particular issue, but if I had a program that zoomed back and forth between two cylinders that did not include 0 - say cylinder 10 and cylinder 190 - then if it got out of sync the microswitch fix won't help. 

DEVELOPED MODIFICATIONS TO SEEK SHADOWING LOGIC IN FPGA

I put in the logic to reset the cylinder whenever the arm is sitting at cylinder zero. I also made changes to hopefully address whatever issue caused it to get out of sync with the actual disk arm. When I get back to the shop I can test this to see if I resolved the vulnerability or not. I will also have the logic analyzer collecting data as I test this out, to see if I can spot any other situations that cause the FPGA logic to misbehave. 

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

REVIEWING TERMINATOR CARD FOR SIGNALS ENTERING THE V2315CF MAIN BOX

The Virtual 2315 Cartridge Facility (V2315CF) sits in between the IBM 1130 disk controller logic and the internal 2310 disk drive inside the 1130, routing signals into the main box of the V2315CF. Some signals are directly connected between disk and 1130, but a tap sends the same data into the V2315CF, while others are either generated in the main box or received there and then rebroadcast on another line.

The main box has a plug-in board with terminator resistors. One pulls the signal line up to +5V while the other pulls it down to ground. This sets the signal, when no other element drives it, at about 3V and yields an impedance of 104 ohms which is close to the ribbon cables that carry the signals between the main box and the 2310 Interface Board that routes signals to the 1130 and 2310 cables. 

The 1130 or 2310, depending on the direction of the signal, also provide a pullup resistor to +3V for most signals. This can interfere with the impedance and voltage levels of signals. I wanted to observe each signal to see what when they need the termination resistors installed and when they are better off without them. 

WORKING ON SEEK SIGNALS FIRST

The signals involved in a disk arm movement (seek) are -Access Go, emitted by the 1130 disk controller logic to request a movement, along with -10/+20 Mil Step and -Rev/Fwd Direction  signals that the 1130 sets prior to the falling edge of the first signal. The 2310 disk controls the +Access Ready feedback signal, which provides a handshake to the 1130 indicating when the arm has finished moving. 

+Access Ready will drop low about 5 milliseconds after the 2310 has seen a falling edge on -Access Go. The 1130 will respond to the drop of +Access Ready by returning -Access Go to logic high. After a further 10 milliseconds, +Access Ready returns to logic high indicating that the arm movement has completed. All four signals involved in the seek are directly connected by the electronic switch chips while the V2315CF is in real mode, so the output of the 1130 is directly connected to the 2310 and the output of the feedback from the 2310 is directly conneccted to the 1130. 

The FPGA in the V2315CF snoops on those signals so that it can shadow the position of the disk arm, knowing exactly where the drive arm is sitting at any time. I had hammered out some logic that I believed would be unaffected by the kinds of glitches I saw on the signal lines when I observed them using my logic analyzer. 

TRYING TO MOVE THE ARM RESULTED IN HARD SWING TO 202 OR 0

Initially, even when I tried to move just one cylinder, the arm shot all the way to the extreme and kept trying to move. The oscilloscope showed me that the +Access Ready signal was not dropping close enough to ground to be reliably detected by the 1130 controller logic, so it kept asserting -Access Go causing incorrect movement. 

I removed the termination resistors for that signal line and the system cooperated. The arm moved correctly and the signal didn't look too bad. No significant ringing on the timescale that can cause problems for the Solid Logic Technology (SLT) circuitry in the 1130 and 2310. 

CHECKING THE SHADOWING LOGIC OF V2315CF

I ran a program that repeatedly moved the arm from cylinder 0 (home cylinder) to cylinder 200 and back to 0. The disk arm faithfully moved between the two positions, however after a minute of operation, when I stopped the program, I found that the V2315CF shadowing was off by a few cylinders, showing the arm at a low non-zero cylinder when the actual arm was at 0. 

Drat - I am going to need to do even more to ensure that the glitches don't get my logic out of sync. I will work on that over the next day or two. I really want to see the shadowing fully working before I move on to checking the other signals and their need for termination. 

ADDED ERROR MESSAGE ON V2315CF FOR WHAT I EXPECT IS A COMMON ERROR

The physical 2310 disk locks the handle so that a cartridge cannot be inserted or removed until the UNLOCK lamp is lit on the 1130 main console. As soon as the motor begins spinning a cartridge in the 2310, the UNLOCK lamp is turned off and will not turn back on until the platter is stationary again. 

When the user tries to load a virtual 2315 cartridge, they insert it into the V2315CF and flip the switch on that box to LOAD. However, if the UNLOCK lamp is not on, then it silently ignored the attempt to load the virtual cartridge. This reflects real life behavior of the 2310, but the user may not realize what is happening if they start spinning up the 2310 then try to load the virtual cartridge. 

To make this clear, I now display an error message on the LED screen of the V2315CF "Must be unlocked". This is a reminder of the correct operational sequence - load virtual cartridge first, then start up the 2310 drive. 

ISSUE WITH THE CE SWITCHES ON THE BACK OF THE 2310 DRIVE

The 2310 disk drive has four switches on the back that are used by the Customer Engineer (CE) to test the drive. The let the CE move the arm forward or backward in steps of 10 or 20 mils, either one time per press or continuously while the switch is held. These are supposed to be inactive when the 2310 is cabled to the 1130 system, but work if the cable is disconnected from the disk drive. 

The ciruitry for these is hidden across five pages of logic diagrams in two different binders (1130 and 2310) but not completely. The rest of the diagram is shown in the manual Field Engineering Theory Of Operations for the 2310 drive. 

The 1130 side of the cable is connected to the +3V power rail. Inside the 2310, a pulldown resistor to the -3V rail keeps the switches negative unless the cable is connected so that the +3V is present instead on the line +CE Interlock. I previously identified a defect in my design, where I was grounding +CE Interlock which still permitted the CE swtiches to operate. I modified the 2310 Interface Board to connect the incoming +CE Interlock line from the 1130 to the 2310, which should deliver +3V and inactivate the switches. 

I measured the voltage at the 2310 and +CE Interlock was negative. I pulled the cable from the 1130 and checked the signal coming in, which was about 2.4V not 3V. I moved back into the 1130 where the wire originates. The voltage on pin D07 of A-C1 slot N7, the connector end inside the 1130 logic gate, was 2.4V. That pin should be directly connected to the adjacent slot (A-C1 M7) pin D03 which is the pin where the +3V rail enters SLT cards. The pin on M7 D03 was 3V. 

The issue was a failure in a trace that should connect A-C1 M7 D03 to A-C1 N7 D07. I added a wire wrap connection and did have +3V delivered on the 1130 cable where +CE Interlock enters the 2310 Interface Board. That restored the intended lockout of the CE switches. 

REWORKED THE POWER WIRING OF V2315CF

The power to the V2315CF is connected through a power PCB but with wiring to external parts - a timer module, a smart trickle charger, a 12V motorcycle battery, the incoming +12V rail of the 1130 and the power supply board that comes with the RK-05 Emulator kit upon which the V2315CF is built. 

It had included diodes to isolate the battery and +12V inputs, a circuit to detect when the 1130 12V supply dropped, and connections among the other external parts. The diodes caused an unacceptable voltage drop in the supply to the emulator power supply, so I redesigned to eliminate them.

The timer is always powered by the 12V battery now. Its sense line to turn it on for 40 seconds is connected to the incoming 1130 +12V rail. Its SPDT switch is connected with the emulator power supply + input hooked to the armature, the 1130's 12V rail connected to the N/C terminal and the 12V battery + terminal connected to the N/O terminal. This switches the emulator power supply from the 1130 system over to the battery for 40 seconds when the 1130's power drops.

A smart trickle charger maintains the voltage of the 12V motorcycle battery as long as the 1130 system is plugged into the building power, even when the 1130 system is otherwise powered down. Thus the battery is topped off and always ready to support the 40 seconds of power necessary to rewrite the current cartridge contents back to the microSD card in the mini 2315 cartridge. 

I can pull the diodes from the existing PCB and make a few minor changes to utilize it under the new design. I rewired everything and gave it a test on the bench to be sure that it works as intended. 

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

LOGIC ANALYZER SHOWS SHORT GLITCHES THAT CAN AFFECT STATE MACHINE

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

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

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

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

top is -Access Go, next is +Access Ready

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

WORKING ON FPGA LOGIC THAT IS IMPERVIOUS TO SHORT DURATION GLITCHES

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

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

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

OUT OF ROOM ON FPGA CHIP WAS NEXT SNAG

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

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

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

SUCCESSFULLY REMOVED NEED FOR SECOND REGISTER AND ALL THE COMPARISONS

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

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

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

IMPLEMENTED THE CARTRIDGE ICON TO DISPLAY ON V2315CF MAIN PANEL

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

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

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

ELECTRONIC SWITCH ADDED FOR IMPORTANT SIGNALS RELATED TO SEEK

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

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

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

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

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

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

TERMINATOR CHANGED TO OPTIMIZE SIGNAL QUALITY

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

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

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

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

FPGA LOGIC CHANGES NEEDED TO AVOID DOUBLE DRIVING OF CIRCUITS

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

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

FIRST TEST WITH NEW BOARD BUT FORGOT TO UPDATE THE FPGA

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

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

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

PRODUCED 2315 CARTRIDGE IMAGE FOR LED PANEL OF MAIN V2315CF BOX

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

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

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

ADJUSTING THE DISK DRIVE SEEK SETTINGS

I wired up a number of disk drive signals to the oscilloscope. The amplifier balance and dead band adjustments were previously completed. The operation of the trigger that stops the acceleration of the disk arm so that it comes to a stop .01 or .02 inches from its prior position has to be adjusted. Each of the two step sizes, 10 mil and 20 mil, have their own trigger voltage. The level needed to move farther is higher than for the short step. 

The trigger voltage for the steps - 10 mil or 20 mil - are set to correspond to a velocity of the arm at which the logic stops accelerating and flips over to decelerating the arm to a stop. Later adjustments will tweak this to achieve the most reliable stepping operation, but the initial adjustment voltages get us close. They were pretty close already.

A 10 millisecond timer is adjusted to ensure that the feedback from the disk drive to the controller logic in the 1130 is correct. When a step is requested by dropping the -Access Go signal low, a timer waits 2.6 milliseconds while the detent, a tooth that fits in a rack to hold the arm at a specific cylinder, is retracted allowing free arm movement. After th 2.6 ms, the feedback signal +Access Ready drops low and the arm begins its acceleration. The 10 ms timer determines when the +Access Ready signal returns to high signaling completion of the step.

At the end of these settings, I verified several timings, voltage levels and waveforms. There is a 2.6 millisecond single shot timer that must be correct to give the detents time to disengage from the rack teeth before the arm begins accelerating, for example. I also checked the detent voltages and timing. 

DYNAMIC METHOD OF FINE TUNING THE 10 AND 20 MIL STEP THRESHOLDS

Putting a voltmeter on the threshold potentiometers for the 20 mil step size, I moved the arm continuously in 20 mil steps while rotating the pot. The method involves visually detecting when the detents no longer smoothly engage the rack, perhaps skipping teeth to misposition. The observation has to be over the entire range of cylinders, in both directions.  Recording the low and high voltages where the misbehavior begins, I then set the pot to the 2/3 point between those extremes. 

The idea is that this is going to be the most reliable setting. It is similar to how magnetic core memory is adjusted - finding the extremes where failure begins and then selecting the point in between that is known to work best. For memory, a diagram called a Shmoo Plot is drawn to record the extremes and select the ideal operating point. 

Moving over to the 10 mil step potentiometer and the drive step size to 10 mil, I again continuously move the arm back and forth over the entire range of cylinders while changing the pot until I see misbehavior. Using the low and high voltages discovered by this process gives me the 2/3 point voltage between the extremes and that will be the sweet spot for the mechanism. 

RECONNECTING DRIVE AND USING SOFTWARE TO DRIVE THE ARM BACK AND FORTH

I used a simple hand loop to move the arm rapidly back and forth between two cylinder targets, observing the drive to ensure that it does not stop at the wrong cylinder or otherwise misbehave. I changed the forward and backward seek counts to various numbers, having first moved the arm to a desired starting point. This involved several ranges of seek and performed them across various portions of the rack (ranges of cylinder addresses). The most extreme being 202 cylinders forward and back, the extremes of the legitimate cylinder addresses for this drive. 

RESULTS OF THE HAND LOOP TESTING

The drive is seeking very smoothly and accurately. It always reached the intended cylinder regardless of the size of the movement. I am ready to move on to running the IBM disk diagnostic program to validate that the Virtual 2315 Cartridge Facility (V2315CF) is working as intended and ready to have the system installation completed. 

TWEAKING THE ENCLOSURE THAT WILL HOLD THE V2315CF INSIDE THE IBM 1130

I made some changes to the size of the enclosure that will be mounted on top of the internal disk drive, underneath the 1130 top cover that pivots up. Barry Ward is finalizing his printed drive mechanism and mini 2315 cartridges. I did a test fit of his working version of the drive and the main V2315CF unit installed in the front plate of the enclosure. 

The enclosure is assembled with 1/8" thick black plexiglas and mostly glued together, relying on 1/4" square rods to bolster the joints.

The disk drive fits in the right side of the front panel, but I don't have the current outlines for the holes since Barry is working on that part, so my CAD files for testing the assembly are missing that portion of the design. It was enough to feel confident in cutting the acrylic.