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.