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

NEW APPROACH FOR SHADOWING SEEK IN REAL MODE

I made changes to the logic for the FPGA in the Virtual 2315 Cartridge Facility (V2315CF) to handle the glitches I saw on +Access Ready as it was passed to the 1130 disk controller logic. That feedback signal generated by the disk drive had glitches which looked like spurious changes of state to the disk controller, resulting in failure to drive the disk arm to the intended cylinder in all cases. 

For virtual mode, where the disk drive is not involved at all, V2315CF generates +Access Ready using a timer to match the specification for what the 2310 internal disk drive would do if it were hooked up natively. When an -Access Go from the 1130 requests a movement, the disk waits 5 milliseconds, then drops +Access Ready for a further duration of 10 ms. At the time that it first drops the feedback signal, the logic records how the cylinder number (disk arm position) would have changed based on the step size and direction that accompanied the -Access Go falling edge. 

I now generate the same +Access Ready signal in real mode (where the disk drive is running and performing the seeks being requested) as we do in virtual mode. Thus, we don't care about +Access Ready coming from the disk drive, we just assume that it is performing the seek as requested. This ensures that the V2315CF will interact properly with the disk controller logic and that we record every arm movement that was requested by the 1130.

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

BETTER LOGIC ANALYZER RECORDINGS AND THEIR RESULTS

I recorded several seek movements - 1, 2, 3 and 193 cylinder movements. What I observed in all of these are glitches or spurious changes of +Access Ready which caused the 1130 disk controller to malfunction. 

For example, here I zoomed in on +Access Ready, the second signal in the trace, dropping low for a short (invalid) period which triggers the disk controller to step the count register and in this case to switch from 10 mil to 20 mil steps. It also confused the controller into turning off its =Access Go request but it turned it back on because +Access Ready was back on. 

An even more flakey case is captured on an attempted seek of 3 cylinders, which actually moved the arm just one step. The count stuttered very rapidly and reached a full count condition that stopped the seek. The drive saw only the single -Access Go with -10 Mil Step asserted, thus it moved only one cylinder. 

The arm physically moved to cylinder 175 when we requested the seek of 193 cylinders, because the count was being updated by +Access Ready glitches. 

The root cause is incorrect +Access Ready signals as seen by the 1130 disk controller. These are also being seen by the FPGA logic in the V2315CF which causes it to miscount in its own way. The state machine behind the seek shadowing function expects +Access Ready to drop 5 milliseconds after -Access Go is set low, for +Access Ready to stay low for another 10 ms and then return solidly to high. The glitches cause the state machine to advance when it shouldn't or fail to advance. 

NEW VERSION OF 2310 INTERFACE BOARD PCB ORDERED TO HELP WITH THIS

The new version has the electronic switch circuits that will directly route the +Access Ready signal coming from the disk drive out to the disk controller logic, so that it does not have to pass through the FPGA at all. The FPGA is able to see that signal from the disk drive, so that it can shadow the arm movements properly. 

I also switched the terminator resistors on the V2315CF to better match the impedance of the 1130 cables and ribbon cables between V2315CF and the 2310 Interface Board. Hopefully these will help with reflections and other signal issues for +Access Ready. 

CHANGE TO FPGA LOGIC TO AVOID THE ACCESS READY GLITCH ISSUES

In virtual mode, the V2315CF generates the +Access Ready signal using timers so that it conforms exactly to how the disk drive should work. It drops 5 ms after a seek begins and returns to high a further 10 ms beyond that. This worked perfectly in testing.

I will send that same generated +Access Ready to the disk controller logic, not the signal coming from the disk drive, so that real mode will not have the improper feedback to trip up the operation of the disk controller logic. 

My shadowing logic must be made bulletproof even with odd behavior of the detected +Access Ready signal, so that it too counts properly. I will drive it off the same timers that generate the signal for virtual mode. If we receive an -Access Go, we will step through the timing without regard to the feedback signal coming from the disk drive. I may test the state of +Access Ready in order to detect failures of the disk drive, but it must be a soft enough check that the glitches won't bother it. 

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

UPDATES MADE TO LOGIC OF THE V2315CF

I made a few updates to the C code for the PICO and the Verilog for the FPGA of the Virtual 2315 Cartridge Facility (V2315CF) based on the prior day's testing. I had noticed that a completely valid sequence of steps did not perform in a way that makes sense. The state machine was changed to handle this in a more reasonable way.

The user inserts a mini cartridge containing an image of a 2315 disk cartridge on a microSD card inside the holder, plugging it into the V2315CF main box. The switch is set to Load which causes the V2315CF to read the contents into memory so that the 1130 can read and write to that just as if a physical 2315 disk cartridge had been inserted into the 1130's internal disk drive in an unmodified system.

A placeholder 2315 cartridge is inserted into the disk drive in the 1130, one which is only used to generate timing signals and provide realism. The run switch is turned on for the disk drive and it spins up. After about 90 seconds the disk drive believes it has loaded the read/write heads down to fly atop the surface of the disk platter inside the cartridge. The File Ready lamp lights on the 1130 console and on the V2315CF main box.

After accessing the disk by software instructions run on the 1130, the run switch of the drive is turned off. The File Ready lamp goes out and the drive slows to a stop. The Unlock lamp on the 1130 console lights, indicating that the 2315 cartridge could be removed and another inserted. If, however, we just turn the run switch back on, we should be able to continue using the virtual cartridge we loaded into the V2315CF just as we would continue to use a physical 2315 cartridge in an unmodified drive.

After the drive spins up and waits 90 seconds, the drive thinks it loads the heads and wants to turn on the File Ready lamp. However, it does not light, nor can we access the virtual disk from software. This does not make correspond to what happens with an unmodified 1130 and disk drive, where we could turn it on again and it would be ready for access. I had to unload the mini cartridge and reload it to get the V2315CF to start up the drive and make it ready.

When we load a mini cartridge into the V2315CF, the state machine sits (lets call this state W) waiting for the File Ready signal from the disk drive before it advances to turn on the File Ready lamp (call this state R) and allow access. My change was that when we had been in this second (R) state, but turned off the drive, the state machine returns to that first state (W) where it is only waiting for the drive to turn on File Ready.  

I also removed the Schmitt trigger filter I used with the +Access Ready incoming signal, because that adds additional delay which may have been causing the 1130 disk controller logic to malfunction. That was one possible cause of the seek errors I was seeing - a seek of N cylinders sometimes moved only L cylinders instead, plus the V2315CF believed it had moved to cylinder L-1 instead of L where the arm actually stopped. 

INSTALLED THE LOGIC ANALYZER ON THE DISK CONTROLLER LOGIC

I hooked up the 16 channel logic analyzer to key signals in the disk controller logic that might point me toward the cause of the seek anomalies. I watched the nine bits of the count register, as well as the signal to move the arm (-Access Go) and the feedback signals from the drive (+Access Ready and +Home). I also hooked the analyzer to the signal +Access Control generated during an XIO Seek instruction and the internal control signal -full_word_count that indicates the count register contains all ones. 

When an XIO instruction requests a seek of N tracks from the current location, the value N is inverted and loaded into the count register. That is, every bit is inverted to form the ones-complement of the count from the XIO. The disk controller logic then sends -Access Go signals and bumps up the count register, taking steps of 1 or 2 tracks, until the count is complete because all nine bits of the count register are 1. 

When the count N from the XIO instruction is an odd number, the low order bit of the count register has a 0 in it. This causes the disk drive to move only 1 track in the step (-10 Mil Step signal). As soon as the drive responds to the -Access Go about 5 milliseconds later with a drop of +Access Ready, the low bit is forced to 1. When +Access Ready returns to high, the count register has 2 added to it and -Access Go is again asserted to take the next step. This will always be a 2 track step. Only the first is 1 track and only when the count N is odd. 

This restart of -Access Go is blocked when the count register is all 1s, causing the seek operation to complete. I will look at the interaction between -Access Go, +Access Ready, the 9 bits of the count register and the -full_word_count condition, which should proceed according to the rough timing of 5 ms for +Access Ready dropping and 10 ms after this, +Access Ready returning to high. -Access Go should go off when +Access Ready drops. The seek operation should not end until we have moved the full count N tracks. 

A challenge with the logic analyzer is having enough recorded information to find the defect. The logic analyzer runs fast, but the timescale for a seek is glacial by comparison. Each step takes around 15 milliseconds so a seek of 200 tracks would span 1.5 seconds. The practical limit for recording in the 256MB buffer depends on the sampling rate and number of channels being recorded. For 16 channels being captured, at a sampling frequency F we will have 16/F seconds recorded. 

To watch the signals based on nominal behavior, we have to catch signals that change in the neighborhood of once each 5 to 10 milliseconds. If I set the sampling frequency at 5MHz, then we record about 80 Mbits in a second; with a memory of 256Mbit to hold them I can capture about 3.2 seconds worth. PPPp

Using the rule of thumb that we should sample 10X the rate we expect signals to change, I should be able to see signals changing on the scale of 500KHz with a 5MHz rate. That corresponds to about 2 microseconds. I can't be certain to capture glitches that occur on a shorter timeframe with this recording rate, but I can certainly count the steps and validate the change of the count register. 

If I see that weird things sometimes happen, with counts advancing too rapidly or the hint that the dance between -Access Go and +Access Ready is sometimes happening faster than the 15 ms we expect, I can increase the sampling rate and try some short seeks that still fit in memory until I have visibility of whatever is triggering the malfunction. 

FIRST OBSERVATION FOR A SEEK OF 193 CYLINDERS

I set up the XIO with a seek count of 0xC1 which is 193 in decimal. It is an odd number as well as very long, where previously we had very repeatable failures to seek the entire distance. The logic analyzer set to 5MHz sampling can easily record the entire operation, triggered by the +Access Control signal that is generated as the XIO Seek instruction executes. I can store the contents of the data and use the DSView software to look at it. 

The V2315CF agrees with the disk arm position, which is a significant improvement from last time. Unfortunately, the saved file from the logic analyzer didn't save enough to capture the end, so I couldn't count the seek steps to verify that it matched the seek count. 

ZOOMING IN ON A SEEK OF 3 CYLINDERS

If I set the analyzer to the max rate for 16 channel recording of 100 MHz I can capture about 167 milliseconds of signals, good enough for a seek that should last a bit of 30 ms. If I want to just zoom in on the -Access Go and +Access Ready signal waveforms, plus the +Access Control trigger and the -full_word_count end signal, the analyzer can capture at 400MHz for the same 167 ms. That lets me see signals with good accuracy down to about 20 nanoseconds or two ticks of the FPGA main clock. 

Again, due to my low familiarity with the DSView software that captured the trace, I didn't save enough duration to see the end of any of the small seeks. The only one that I was able to see in its entirety was a seek of 40 tracks, which the trace confirms that it issued -Access Go 20 times and I did verify that the disk arm was moved exactly 40 tracks. 

I also don't have good traces for two signals, which I suspect means that I misconnected the two leads from the logic analyzer since the two missing ones are both on the same SLT card slot. 

However, I did do some individual 1, 2 and 3 track seeks which did move both the disk arm and the V2315CF cylinder variable the correct amount. 

ANALYSIS OF RESULTS

It appears that most of the issue I was experiencing was due to the Schmitt trigger filter which I removed from the FPGA logic. However, it was my impression that the disk arm stopped at around cylinder 161 when it should have ended at 193, but I am not certain. 

I plan to go back to the workshop and more carefully record the signals including ensuring that the traces fully capture the entire duration of the seek command. I was triggering on the wrong signal to start as well. Stay tuned for the update, which will either confirm that the seek is fully corrected or help identify a remaining issue with long seeks. 

DISK DRIVE ISSUE WHEN ATTEMPTING TO SEEK PAST CYLINDER 202

When I do a seek that attempts to move the arm past cylinder 202, the drive should keep the arm at the proper location and report completion. What I am experiencing is a steady buzz with the drive continually attempting to move the arm past 202. Even doing a system reset of the 1130 system does not stop that error. Since the reset will ensure that -Access Go is not asserted, it is an issue entirely inside the disk drive. 

The drive has 'crash stops' fixed to block the arm from moving outward past cylinder 0 (Home) and from moving inward past cylinder 202. These are mechanical stops that are adjustable.

The electronics that moves the arm makes use of an integrator to add up the speed pulses from a tachometer on the arm. When the integrator gets to the preset trigger level, it shuts off the access go latch, turns off +Access Ready, which in turn causes the 1130 disk controller logic to return -Access Go to high. 

In one document, it makes mention of a resistor that will charge the integrator if the arm is not able to move, due to the mechanical stops. It claims this takes about 40 milliseconds to turn off, longer than the 2.4 to 3.8 ms during movement that reaches the integrator trigger level. I don't see that 'resistor' in any of the other documents for the disk drive, but I will have to study the circuitry in detail to see if this is actually implemented. If it is implemented, then that charging path is defective, probably due to an open resistor. 

I should do a test where I attempt to seek 2 tracks in reverse, starting at track 1, to see if the drive malfunctions in the same way. It may not, because the access go latch is turned off my reaching the home cylinder which turns on a microswitch. There is no such microswitch nor turnoff path for reaching cylinder 202. 

The issue may be due to the crash stop being set incorrectly. There is a minimum gap between the stop and the arm when it is at cylinder 202, which might be far enough to let the integrator level reach the trigger point. If the space is too small or non-existent, the tachometer won't record enough pulses. 

I can quickly check the spacing of the crash stop, but if that value is acceptable then I have to dive deeper. I suspect that the paths that charge the integrator are represented in the schematic below, as I have colored the paths to show my speculation. 

When the forward direction is active, transistors Q19 and Q22 apply +48V (green) and ground (blue) across the voice coil in the proper direction. The resistor at the start of the red path has a voltage drop proportional to the current flowing in the voice coil. If the coil is stalled it should increase the current and therefore increase the voltage of the red line relative to ground. This voltage flows through a diode D1 thus it only acts to effect things if the voltage is above the voltage drop (about .3V for germanium) of the diode. 

The red line is injected into the yellow path that runs to both transistors Q5 and Q6 of the integrator. Normally, the pulses from the tachometer will cause Q3 or Q4 to pulse the either Q5 or Q6 to drain energy from the capacitor C1 which is initially charged to +6V and pulled down by Q5 or Q6 towards -3V until the comparator triggers the reset of the accelerator go latch. 

However, with no movement to pulse the tachometer, the voltage from the red line flows through the balanced resistors connected to transistors Q5 and Q6. If the balance of the yellow line is offset by current from transistor Q9 (pink) which is active when the -Access Forward line is low (asserted). This causes some current flow to discharge C1 albeit more slowly than if the tachometer pulses were driving Q5/Q6 actively. 

I struggled to find a component that is not working properly for the injection from the red path, but works properly for normal forward and backward movements of the voice coil, other than diode D1. It would have to be a short circuit to stop the red voltage entering the yellow path. If the gap at the mechanical stop for cylinder 202 is too small to allow the tachometers to drain C1 far enough, then I will try to find diode D1 on the circuit board and test it. 

Changing the terminator to improve impedance matching for the Virtual 2315 Cartridge Facility

IMPEDANCE FOR SIGNALS IS COMPLICATED

IBM engineers the 1130 for 92 ohm impedance on cables, although in practice there are ribbon cables, traces on printed circuits, wire wrap on the backplane, and twisted pair wiring involved in the path between the 1130 and its internal disk drive. However, since the engineering goal was matching 92 ohm impedance, I will use that as a working start.

The 2310 Interface Board is where the twisted wire cable from the 1130 and a new twisted wire cable to the disk drive are connected, allowing the Virtual 2315 Cartridge Facility (V2315CF) to sit in between the signals of the 1130 disk controller and the internal disk drive (called 13SD or 2310). It has two IDC 40 pin ribbon cables that run from the 2310 Interface Board to the V2315CF main unit. That unit is a significantly modified version of the RK-05 Emulator from George Wiley, since the RK-05 is a derivative cousin of the 2310. 

CURRENT TERMINATOR VALUES ARE SUBOPTIMUM

The RK-05 Emulator has a terminator board for the signals arriving there over the ribbon cables which uses 178 and 383 ohm resistors pulling up to 5V and down to ground respectively. That provides an impedance of about 122 ohms, which is a mismatch to both the IDC ribbon cable and to the 92 ohm IBM cabling on the 2310 Interface Board. We will use an impedance of 102 ohms for the IDC cable. 

On the 2310 Interface Board, the mismatch between 92 ohms and 102 ohms is not too bad, particularly with the relatively slow rising edges from the 1130 and 2310 electronics over the size of the interface board. However, the mismatch between the 102 ohm ribbon cable and the 122 ohm terminator board is going to lead to some ringing, reflections and power loss. 

CHANGING THE TERMINATOR BOARD TO IMPROVE SIGNAL INTEGRITY

If I switch the terminator resistors to 169 ohms and 249 ohms, still pulled up to 5 and down to ground, it will give me a 100 ohm impedance. I ordered the resistors and will remake the terminator board when the parts arrive. 

Adjusting my Virtual 2315 Cartridge Facility design to increase signal integrity between 1130 and disk drive

LOGICALLY THE V2315CF SITS BETWEEN THE DISK AND THE 1130 COMPUTER

The cable that ran from the disk controller logic cards in gate A compartment C1 of the 1130 originally plugged into the internal 13SD disk drive, but we inserted the 2310 Interface Card between the two. The original cable plugs into that card and a new cable from the card plugs into the disk drive. Two ribbon cables connect the 2310 Interface Card with the Virtual 2315 Cartridge Facility (V2315CF) main box where the signals are processed.

The V2315CF operates in one of two modes - real or virtual. A switch on the 2310 Interface Card selects the mode of operation. 

In real mode, the 13SD disk drive is operating and performing all of its functions except for the data streams to and from the read/write heads. The V2315CF uses a virtual cartridge file in a mini cartridge to generate the bit stream that the drive should have produced, if that virtual cartridge were a real 2315 disk cartridge inserted in the drive. It also captures data that the 1130 intends to write on the disk drive, instead updating the virtual image file in the V2315CF. 

The disk drive spins a 2315 cartridge, although what is on the cartridge doesn't matter since the read/write heads are never lowered onto the disk surface. The cartridge generates sector and index pulses that identify which sector the disk head is flying over at any instant. The disk drive indicates when the cartridge is spinning at the proper speed and it has completed the load sequence, so that a File Ready light illuminates and the 1130 is allowed to command the disk drive. 

The 1130 commands the disk drive to move the arm with the read/write heads inward toward the hub or outwards to one of 203 circular paths on the surface of the disk, called tracks or cylinders. The control signals and feedback signals flow between the 1130 and the disk drive by entering the V2315CF and being passed out to the other side. 

The V2315CF must snoop on the movement of the arm, in order to understand which track the 1130 believes it will be reading from or writing to. The data being read or written is to that track's position with the virtual cartridge file. 

In virtual mode, the V2315CF produces the sector and index pulses and indicates when to turn on the File Ready lamp and allow access. The disk drive is not powered up, does not spin and the arm does not move in and out. Everything that the disk drive did is now generated in the V2315CF and all interactions are between the 1130 and the V2315CF. 

REAL MODE SIGNAL INTEGRITY AND DELAY ISSUES ARE POSSIBLE

Signals from the disk drive must flow into the V2315CF so that the FPGA inside can direct a copy out to the 1130, and conversely signals from the 1130 must first be detected in the FPGA so that the FPGA can generate the same signal out to the disk drive. This adds delays of 80 nanoseconds or more to the passage of the signal. It may also result in the signal developing glitches that cause incorrect behavior. We are troubleshooting issues with seek - moving the arm to a different track - which might be caused in part by these signal integrity issues.

REDESIGN TO CONNECT THE 1130 AND DISK WIRES TOGETHER

I came up with a redesign of the 2310 Interface Card that will connect together the corresponding wires when we are in real mode, so that the signal produced by the 1130 is directly received by the disk drive, and vice versa for signals in the other direction. We can still snoop on those signals, in order to keep track of the arm position on the real drive, but we don't detect them and the generate a copy. 

This is possible because the V2315CF main box, derived from George Wiley's RK-05 Emulator, uses specific interface chips for incoming and outgoing signals. Most importantly, it uses open collector output drivers for signals generated by the FPGA. Thus, if we set that driver signal so that the transistor is not conducting, then it is electrically isolated. 

I added electronic switch chips - TMUX1112 - that connect the input and output sides just like a physical on-off switch. The switch that determines whether we are in real or virtual mode is used to activate those electronic switch chips when the switch is set to real mode. Thus, the -Access Go signal from the 1130 disk controller is connected to the -Access Go wire to the disk drive, allowing the signal to flow without any reshaping or delays.

In real mode, we control the output drivers for those signals so the transistors are off. We connect the two sides using the electronic switches. The input buffers that allow the FPGA to read the signals coming from the 1130 or the disk drive are still operational, thus the FPGA can see what is happening on the 'wire' we connected between the two sides. This supports the shadowing of arm movements and other needs of the logic inside the V2315CF. 

In virtual mode, the switches are turned off and the signals going to the 1130 are produced by the open collector output drivers in the V2315CF. Signals from the 1130 are detected by the buffer chips. Nothing is generated on the output drivers going to the disk drive, since it is turned off. We don't pay any attention to signals that would come from the disk drive since it is not operating. 

NEW VERSION OF 2310 INTERFACE CARD PCB DESIGNED AND PARTS ORDERED

I added a couple of the TMUX1112 electronic switch chips into the schematic, wired them up to bridge pairs of signals that should flow directly between 1130 and disk drive while in real mode, and controlled those switches by the real/virtual mode switch on the board. I placed the parts, routed the connections and prepared the files to send to a PCB fab.

I ordered the two electronic switch chips and changed the logic in the V2315CF to keep the transistors of the output drivers turned off in real mode. Once the new PCB arrives and is assembled, I will place the new version of the logic into the FPGA and test the V2315CF. 

I will finish debugging the seek behavior of the V2315CF and if it turns out that signal integrity or delay plays any role in the issues, I will send the board out for manufacture and buy the electronic switch chips. If everything works solidly after any defect resolution of my logic or disk/computer hardware, I won't spend the money nor invest the time to implement this change. 

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

MORE OBSERVATIONS OF SIGNAL FOR A SEEK WITH AN ODD COUNT

I used my hand programmed code to make several seeks of different lengths in order to watch what the disk drive itself as well as the V2315CF logic saw. For example, when I requested a seek of 161 tracks, it should have stopped the disk arm at 161 and reported 161 on the V2315CF log. What I saw instead was the arm stopped at 141 and the log was also not reporting 161.

I then set up a longer seek to 193 from the home cylinder, with the drive appearing to be at 167. Requesting 81 from the home cylinder left the arm at 77 but the V2315CF believed it was at 76. A seek from home to 41 put the arm at 37 and the V2315CF reporting 36. A seek of 21 put the arm at 17 physically and the V2315CF believed it was 16. 

ANALYSIS OF THE OBSERVATIONS

There are three entities that could be defective - the 1130 disk controller logic, the V2315CF logic and the disk drive. I am still not certain which is wrong, but the discrepancy between the drive position and the V2315CF position tells me that I have a problem in my logic in addition to whatever is happening elsewhere.

I could have problems with the interface signal integrity since the V23215CF sits between the disk controller logic and the disk. While the design intends to pass the signals through between the two, if there are signal issues that might throw off the way the two sides interact.

The interface between the two sides is very simple. The controller logic sends three signals to the drive and the drive responds with two signals. Only those five signal wires are involved in seek operations. The outbound signals are:

• -10/+20 Mil Step is a signal that requests moving 1 or two tracks
• -Rev/+Fwd is the direction of the movement relative to track zero
• -Access Go is the request for a seek movement

The return signals from the disk drive are:

• +Access Ready is the feedback, goes low 5 ms after a seek request and returns high by 15ms
• -Home reports low when the arm is at track 0 (home)

The details matter in terms of timing and behavior both inside the disk drive electronics and in the 1130 disk controller logic. 

Timing inside the disk drive

When -Access Go drops to low, the falling edge sets a go latch inside the disk drive which begins some timed operations. The state of the -10 Mil and -Rev signals determine the movement direction and size and are held steady during this part of the seek. 

A timer of 2.6 milliseconds expires before it begins actual movement. The detents are removed from the rack teeth during this time, which would allow the arm to move freely. If the -Access Go edge is at T-0, this runs to T-2.6 ms.

Depending on whether it is a 10 Mil or a 20 Mil step, a timer then runs for 2.4 ms or 3.8 ms. It runs twice, first accelerating the arm and then decelerating it to a stop. That is, the acceleration is from T-2.6 to T-5 ms or T-6.4 ms depending on step size.

At the end of the first 2.4 or 3.8 ms interval (acceleration) the signal +Access Ready drops to low. This resets the go latch. The signal drops at T-5 ms or T-6.4 ms. It also flips the active detent at this time, toggling between even and odd if the step size was 10 mil or not changing if the step was 20 mil. 

During the second 2.4 or 3.8 ms interval the detent begins to engage and the arm stabilizes its position, coming to a stop by the time the tooth engages the rack to hold the position. Thus by T-7.4 ms or T-10.2 ms, the arm is stopped. 

At the time that +Access Ready dropped, at the end of the acceleration, the drive also begins an approximately 10 us timer at the end of which it restores +Access Ready to high. The entire seek timeline runs from T-0 to T-15 or T-16.4 depending on the step size. 

Timing in the disk controller

The disk controller begins a seek during an XIO instruction, setting the counter of how many tracks to move and the direction of movement, asserting -Access Busy for the duration of the entire seek. It then repetitively issues seeks of 10 or 20 mils until it has counted out the total movement. At the same time as -Access Busy goes low, the access drive latch turns on. 

At the completion of the full number of tracks from the XIO instruction, it pauses for an additional stabilizing interval of 22.5 ms then turns off -Access Busy and turns on Operation Complete to request an interrupt on level 2. 

Once the -Access Busy in the controller goes low and turns on the access drive latch, the logic asserts -Access Go to the disk drive. The direction is held steady for the entire duration that -Access Busy is low.  However, the step size -10 Mil signal is determined by the value in the count register in the controller and thus may change between the first step and the remainder.

The low bit of the count, which is inverted in ones-complement from the seek quantity of the XIO instruction, determines the step size of the first step. If the count is odd, then the inverted low bit will be a 0 which makes the -10 Mil Step signal request a 10 mil step. After the first step, the low bit is forced to a 1 thus every other step is going to be 20 mils. Each time the access drive latch is turned on, it adds to the count register in the controller, adding two except for the first step of an odd count which effectively adds one. 

When the signal +Access Ready from the disk drive goes low, it turns off the access drive latch and returns -Access Go to high. We wait until the disk drive completes the seek step, which it signals by returning +Access Ready to high. 

The rising edge of +Access Ready will turn on the access drive latch again unless the value in the count register has reached all 1s, meaning we completed the full count requested by the XIO. Turning on the access drive latch means we assert -Access Go again for the next step. Thus, this logic iterates steps of the drive.

Glitches may confuse the interlocked logic of the drive and controller

If the +Access Ready bounces back high right after it goes low when a seek step is active, the controller might turn on the access drive latch incorrectly, also incrementing the count register incorrectly. The drive won't move because it ignores a falling edge on -Access Go if +Access Ready is not high. Since +Access Ready is generated internally to the disk drive it has it low during the seek when the signal bounced as seen by the controller. Thus the drive ignores one of the movement requests because it is sent at the wrong time, while the drive is actually still busy moving. 

The rate of glitches on that line, if that is what is going wrong, has to be relatively low since most of the movement is completed successfully as far as the V2315CF and the disk drive is concerned. Short total counts are close, the discrepancies grown with long counts. 

HARDENING V2315CF TO BE ABSOLUTELY CONSISTENT WITH THE DISK DRIVE

I am concerned that the V2315CF is off by one when the controller is moving an odd number of tracks. I suspected that it is the timing of when I capture the step size, since the -10 Mil Step signal comes from the count register and that is incremented just as the -Access Go signal is asserted low. Since I wait to grab it until +Access Ready drops, it has already changed and will always be seen as a 20 mil step size. That means I am also missing one step entirely since the count is low not high by one. 

I had previously added a kind of Schmitt trigger as a debouncer for the signal that drives my seek shadowing. My logic tried to minimize the risk of bounces/glitches on the +Access Ready signal by requiring 10 cycles of a steady signal level before I acted on it. However, that gives the counter time to be incremented in the disk controller and for the -10 Mil Step signal to rise so that I no longer captured the signal state when the seek step started. I removed that from the logic so that I grab the step size immediately on the falling edge of -Access Go. 

TIMING RACE CONDITION POSSIBILITY TO CONSIDER

Because the V2315CF must operate in two modes - real and virtual - I was passing the seek signals through the V2315CF. This means that I had to eliminate metastability risks on the input to the FPGA for each of those signals. That adds four FPGA clock cycles before a signal is passed along, 40 nanoseconds of delay. 

The interlocked behaviors from the two sides would typically occur much closer together, but a sequence where one side sees a signal change (e.g. +Access Ready drops) and then changes an outgoing signal (e.g -Access Go rises) will take 80 nanoseconds longer or more than the direct wiring without V2315CF. 

At this time, I can't imagine how that would cause a problem. Therefore I am left with two broad categories where the cause may lie. First is some hardware failure in the 1130 controller logic, the other is a signal integrity issue over the wiring between the 1130, V2315CF and disk drive. 

NEXT DIAGNOSTIC STEPS

I want to identify which of the categories is our problem. I will start by wiring up the logic analyzer to the signal pins on the IBM 1130 gate A compartment C1 where the controller logic lives. I am practically limited to capturing 16 signals at a time.

I  will try to record a long seek and capture all the -Access Go and +Access Ready signal interchanges. I should see if there are the correct number of seek steps commanded and perhaps spot anomalies that might be triggering errors. Another set of signals I will record are the nine bits of the counter, so that I can watch it count off the seek. 

If I see the count change at the wrong time, or see it miscount, it can steer me closer to the root cause. 

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

HAND CODED SEEK PROGRAM EMPLOYED TO CHECK BEHAVIOR

I had whipped up a short program that I toggled into core which would walk through a list of seek amounts and issue them to the drive. I stepped through it to see if the reported cylinder in the Virtual 2315 Cartridge Facility (V2315CF) log matched where it should stop. 

ANOMALIES DETECTED WHICH I HAVE TO INVESTIGATE FURTHER

As an example of a sequence of five seeks that I ran, starting with the drive at the home position (cylinder 0), this is what I saw:

• seek forward x18 cylinders, from 0 to 40, and V2315CF agreed
• seek forward x03 cylinders from 40 to 43, but V2315CF stopped at 42
• seek forward x18 cylinders, from 42 to 66, and V2315CF agreed
• seek forward x03 cylinders, from 66 to 69, but V2315CF stopped at 68
• seek forward x02 cylinders, from 68 to 70, and V2315CF agreed

Looking at quick pictures I grabbed of the arm position, I decided that I can't really tell. Many are too blurry to see the very fine teeth which are just 20 mils apart. A difference of 2 tracks is just 1/50 of an inch, barely detectable to the human eye.

SEEK BEHAVIOR INVOLVES THE DRIVE, THE CONTROLLER AND MECHANICAL STUFF

The voice coil pushes or pulls the arm to move it 10 or 20 mils at a time, then at the time the movement ends, one of two mechanical teeth (detents) will engage in the rack. The one closest to the position marked cylinder 0 is the even detent, and the odd detent is 410 mils to the left of it. It is offset by 10 mils so that it can hold the arm at odd numbered cylinders while the even detent holds it at even numbered ones. 

Above is the mechanism in an exploded kind of illustration. The rack has major markings every 40 tracks with numbers, divided in half with scribe lines at 20 track multiples. Then, one the fine teeth of the rack, ther are marks every other tooth which is a step of four tracks. Lastly, if the odd detent is engaged we are at an odd number one above the position where the even detent is pointing, since the even one is disengaged and over the tip of a tooth. The odd one is wedged firmly in the notch of its tooth. 

The picture above is the clearest I had, which shows the arm at cylinder 40. The even (rightmost) detent is aimed right at the 40 marking and is engaged in the notch of the tooth. I am trying to shoot with my phone down inside the disk drive housing, using a flashlight for illumination, with a scale where all 200+ positions are in a range of 2 inches of travel. 

It is the disk drive electronics that are responsible for remembering which detent is engaged. It then flips to the other detent when the movement is a one track step (10 mil) or uses the same detent as before if the movement was 20 mils for a two step movement. 

The disk controller logic in the 1130 is responsible for issuing a series of 10 or 20 mil movements to make the arm move the relative amount requested by the program. The design has it make 20 mil (two track) moves and only does a 10 mil movement as the first step if the count to move is odd. Thus, a seek of 9 cylinders would be sent by the controller as movements of 10, 20, 20, 20, and 20 mils. A seek of 4 cylinders, being even, is sent as 20 and 20 mil steps. 

The programmer specifies a relative number of tracks to move (and a direction) in the IOCC pointed to by an XIO instruction. The disk controller converts this into the sequence of 20 mil steps and a final 10 mil step for an odd total movement. 

The V2315CF is inserted in between the disk controller logic in the 1130 and the disk drive logic. Thus, it sees sequences of movements with each set to either 10 or 20 mils, in the forward or reverse direction. It does not have access to the state of the even and odd detents, nor to any feedback about the absolute position - with the exception of the microswitch that indicates we are at cylinder 0. 

ANALYSIS OF WHERE THE FAULT MAY LIE

A failure of the disk drive electronics to properly engage the odd or even detent would not cause the V2315CF to get out of sync with the programmed XIO seek operations. If the program asks to move three tracks and the disk controller logic correctly issues one 20 mil step followed by a 10 mil step, then the V2315CF and the program should be in sync unless my logic in the V2315CF is not capturing the 10/20 mil steps properly. 

The disk controller logic loads an internal register with the ones complement inverse of the cylinder count from the IOCC when an XIO seek is issued. Note that the 1130 is normally a twos complement machine but not in the controller logic. The low order bit is the control signal to the disk drive, when on it asks for a 20 mil step while off is a 10 mil step. 

If the low bit is off when the seek begins, it is asking for a 10 mil step. At the completion of any step, the low bit is forced on (to 1), thus only the first step has the potential to be a single track movement. When the low bit is 1, each step is requested to be 20 mils and the end of that step increments bit 14, thus adding two to the count. Once the counter steps to FFFF the operation is terminated and thus the seek is over.

If the program sends a seek amount of 4 in the IOCC, the ones complement is 111111111011 initially. The low bit (15) is on thus we are requesting a 20 mil step. After the first seek, we add to bit 14 thus the new value is 111111111101 for the second steek. The second seek also has bit 15 on, thus it is also a 20 mil step. Once that second seek ends, we add to bit 14 which makes the end value 111111111111 which triggers the end of the operation. We did two 20 mil steps, which moves us four tracks. 

If a program sends a seek amount of 3 in the IOCC, the ones complement is 111111111100 initially. The low bit is off so we are requesting a 10 mil step. At the end of every seek, including this first one, the low bit is forced to 1 so the value after the first seek is 111111111101 for the second seek. With the low bit now turned on, our next step is 20mil and after we finish that second seek, we add to bit 14 making the value 111111111111 ending the operation. 

Thus what could explain the error is if the ones complement value set in the counter register for a three track move is 111111111101 instead of 111111111100 which cause our first seek to be 20 mil instead of 10 mil. The end of that first seek gives us an add to bit 14 and the seek ends. Thus, a seek request of 3 would move just two steps if bit 15 is erroneously set to 1 in all cases. 

UNDERSTANDING THE SEEK LOGIC IN THE 1130 DISK CONTROLLER

In order to make the testing results clear, I will provide some background information to explain the schematic segment below taken from Automated Logic Diagram (ALD) page XF201. This involves two structures which are different from modern logic gates - AC triggered gates and flipflops. 

The first is the AC triggered gate. Any logic gate that has an N or P input on the left is only going to respond when it has a falling or rising edge on that input. Further, it will only respond to that edge if the conditioning inputs are all asserted. For inputs that have the inversion character ◣ in front of them, they must be low. When the gate responds, it produces an output pulse, negative going if the output has the inversion character ◣ displayed. See blow for an AC triggered gate. 

The second is that the flipflops in the IBM 1130 do not switch on a clock edge, they are triggered by pulses that are essentially asynchronous to the machine clock. Thus when a negative going pulse arrives at the set or reset input to the FF, the falling edge causes the flipflop to change state. 

However, if a pulse arrives that would cause the FF to stay in the same state, it produces an anomalous false pulse out of the opposite wire of the FF. A FF which is set on which gets a pulse on the set input emits a short pulse on the unset output (notQ). To protect against that spurious output, there is a connection from the flipflop back as an enabling input to the AC trigger gate that drives the FF input.

In the excerpt above, the notQ output of the FF is one of the enabling inputs, thus the AC trigger gate will only fire if the FF is set (not Q is low), as long as the other enabling input is low and we have a falling edge on the trigger. 

For convenience, I removed the feedback from the FF to the AC triggers in the schematic portion below, thus only showing the enabling and trigger inputs that set or reset the flipflop.

At the end of any operation (read, write or seek), the -File Reset signal is pulled low which resets the flipflop. This is also asserted when the overall reset signal -DC Reset is active low. Thus + bit 15 should be at 0 except during a seek of more than 1 track duration.  

Midway in the processing of the XIO that starts the seek, the signal -Load Word Ctr SP is pulsed low. if the enabling input to the top left gate is also low (meaning bit 15 is a zero) then when the trigger has its falling edge, we set the flipflop. In other words, we set the flipflop to 1 when the seek count is even otherwise the flipflop should remain set to 0. 

The second gate down on the left is only involved when this counter is used in read or write operations. Its enabling input -Bit Counter Gate will be high during a seek, disabling this gate. The fourth gate down on the left is also only used during read or write operations, thus the -Bit Counter Gate high state keeps that AC gate from triggering. 

The third gate down on the left is enabled when the drive is in the middle of a seek, thus -Access Busy is asserted low. The triggering input is +Access Drive which is the is the control signal to the drive to take a step. When it ends, the falling edge of the trigger input produces a pulse. This is what sets the bit 15 flipflop to one at the end of any seek step. A seek usually involves multiple steps of the arm, thus -Access Busy is low for the entire length of the seek while +Access Drive is asserted for each of the steps.

The flipflop for bit 15 has its notQ output routed to the disk drive as the -10 Mil Step control signal. If the FF is not set, notQ is high and that requests the disk drive to take a 10 mil step. Once the flipflop is set, either because we have an even quantity for the seek or because we have completed a step of the arm, the notQ output is low which asserts -10 Mil Step to ask the drive to move two tracks in this step. 

Putting this all together, we set the bit 15 flipflop to the ones complement (inverse) of the low bit of the seek quantity from the XIO Seek instruction. Depending on that bit value, the drive may do a 10 or 20 mil step initially. After every step of the arm, the flipflop is forced on which signals the drive to move 20 mils for each step. 

No counting is taking place in this bit position of the count register, since bit 15 is special to control the seek step size. The flipflops for bit 14 and the other count register bits are designed to add one to the count of the bits other than 15 each time the -Increment Word Count signal has a falling edge because it is asserted. In a seek, -Increment Word Count is asserted whenever +Access Drive is asserted, e.g. each time we command a step of the arm we increment the counter. 

When every bit of the count register is 1, the signal -Full Word Count is asserted low which turns off -Access Busy, ending the seek operation. That raises the interrupt request line for level 2 and sets the operation complete flipflop for when a future XIO Sense Device interrogates the disk drive status. 

OSCILLOSCOPE SET UP TO TEST BIT 15 DURING A SEEK

The signal that we are in a seek is when - Access Busy is asserted low. This is picked up at gate A, compartment C1, slot M6, pin B13. All logic for the disk controller is in gate A, compartment C1 thus I will leave that off of the following signal locations.

The value of + bit 15 in the count register is slot M6 pin G12 (equivalent to slot M7 pin B12 as this is a double size SLT card in slots M6 and M7). It is asserted high when we want a 20 mil step and should be low for the first step of an odd count seek which is sent as -10 Mil Step to the disk drive. 

+Access Drive is turned on to force the disk drive to take a step. It is picked up at slot M6 pin G04 (equivalent to slot M7 pin B04). 

-File Reset is the signal which turns off the bit 15 flipflop at the end of an operation. It is picked up at slot M6 pin J11 (equivalent to slot M7 pin D11). This goes low to reset the bit. 

-Load Word Counter SP is a pulse that sets up the count register to its initial ones complement version of the seek count. It is picked up at slot M6 pin G13 (equivalent to slot M7 pin B13). This goes low to set the flipflop depending on the value of +B Reg Bit 15. 

+B Reg Bit 15 is the input that has the total seek count from the XIO Seek instruction. It is picked up at slot M6 pin J10 (equivalent to slot M7 pin D10). When -Load Word Counter SP goes low and this is low, +Bit 15 should be set high, otherwise it should remain low. 

One challenge in watching a seek on the scope is the timescale for the arm movement. This can take up to 15 milliseconds, while the pulses that set and reset the flipflop operate on a timescale of less than 30 nanoseconds, 500000 times longer. As a result, I have to watch this in portions, otherwise I would hook up the logic analyzer to gain the long scale needed to observe everything.

First I want to see that bit 15 is already at zero when the XIO Seek begins. I would see this by triggering on the -Access Busy signal going low and watching both +Bit 15 and -File Reset signals. I should see -File Reset go low and +Bit 15 be low after as a result and have been initially low before -Access Busy goes low.

Next I want to watch the setting of the bit 15 flipflop for both odd and even seek counts. I would trigger on -Load Word Counter SP going low, watching +B Reg Bit 15 and +Bit 15. The initial state of +Bit 15 should be zero and its end state will be the opposite of +B Reg Bit 15.

I could watch for +Access Drive going high and verify that +Bit 15 is turned on if it was 0 initially. However, the failure symptoms do not seem to align with this failing to work, so that isn't an important observation. 

Based on what I see here that does NOT look right, I would move around and scope appropriate signals to figure out what is failing and leading to this anomalous behavior with odd numbered seeks. 

OBSERVATIONS OF ODD AND EVEN SEEKS USING THE SCOPE

As I observed the outputs of the disk controller logic in the 1130, the state of +Bit 15 was perfect, but the drive was not moving the -10 Mil Step as it should. All the signals from the controller logic looked good.

I then hooked up to the same signals as they come out of the V2315CF box. Eventually I captured an image with a long enough time duration to see the -Access Go command from the 1130 de-assert. There was a difference right there.

What I saw was that the first access step was commanded for 10 mil and when the -Access Go turned off, the -10 Mil Step line went high for a short period then dropped back to low. Meanwhile, the -10 Mil Step line from the 1130 controller logic remained high. Something in my logic in the V2315CF is causing this! 

I triggered on the rising edge of -Access Go and increased the resolution, to see that the -10 Mil Step signal went to high and remained there for a bit of a microsecond before dropping. There is a microsecond timer pop in the V2315CF that advances a timer, used to determine when the seek has completed when we are in virtual mode and used as a watchdog timer to free up the state machine while in the real (hybrid) mode. 

This was interesting. Looking at my logic, the signal from the 1130 disk controller logic should be passed along untouched to the disk drive, yet it clearly is not. I looked through all the FPGA logic and don't see a clear fault that would cause the outgoing -10 Mil Step signal to be driven low. 

Basically that input signal from the 1130 disk controller logic should be passed straight through to the disk drive, while also observing it to shadow the seek movement. I see that the routing logic blocked the signal when an internal condition called Selected_ready is turned off. There is no reason to do this in real drive mode, so I changed the logic. 

I do see that there is a spurious redrive of the -Access Go soon after it returns high. This should be around 5 milliseconds into the seek. My logic captures the falling edge of that signal after a chain of flipflops to eliminate metastable state issues. One thing it does with a falling edge is set a timer in the logic to 15,000 which then counts down with each 1 microsecond pulse generated for use in various places inside the FPGA logic. 

I use that as a watch dog to catch a case where my state machine somehow hangs up forever waiting for +Access Ready to drop low but that event doesn't occur for arcane reasons. If the time expires I move on to the final step where I wait until +Access_Ready is high again. In the pathological case I am protecting against, the signal will already be high so that means we end the seek state machine and wait for future requests. 

The disk drive electronics also look for a falling edge on -Access Go to begin a seek. It sets a latch when that edge is detected but the latch is reset after about 5 milliseconds when it drops +Access Ready thus the glitch in the scope was a potential threat to turn the latch back on. Fortunately, the -Access Go signal trigger has an enabling requirement that +Access Ready be high, so in this case the glitch doesn't pass through. 

I really didn't see a clear cause for the observed results in my review of the logic in the V2315CF box. The 1 microsecond duration of -10 Mil Step being high before it drops again suggested that the 1 us timer in my box was involved, but I don't see that. 

I updated the V2315CF with the logic changes I made and tested again. I had to watch a few more cases to be certain of what is happening, perhaps moving to observe signals on the disk drive logic itself. I will do this on the next return to the workshop. 

Human 1, AI 0 - 40 minutes of debugging and my PICO tool projects microSD card as USB thumb drive to PC

CARTINTERFACE - TOOL TO MOUNT MINI 2315 CARTRIDGE ON PC VIA USB

The Virtual 2315 Cartridge Facility (V2315CF) employs microSD cards to hold a disk volume with a file that is a virtual image of a 2315 disk cartridge. These cards are mounted on a small circular PCB that is the top of a mini cartridge, looking like a tiny version of the 2315 cartridge, with a 2x4 header that plugs into the V2315CF main box so that the disk image can be accessed by the IBM 1130 system. 

The PCB has a microSD card socket on board and is wired so that the V2315CF can access it via Serial Peripheral Interface (SPI) over the header pins. The card socket and other components are on the underside of the small PCB. The mini cartridge has a 3D printed shell glued under the PCB, forming a 2315 cartridge shape. 

For convenience, I wanted a tool that allowed me to plug the mini cartridge into a socket and have the file on the microSD card appear on a PC as a virtual disk drive, just as a USB thumb drive appears. I whipped up a small box with a Raspberry Pi Pico, a 2x4 socket and some pullup resistors as an interface box, which I call CartInterface. 

The mini cartridge is plugged into the 2x4 socket and the USB cable from the PICO is plugged into a PC in order to open the microSD card FAT file system as a virtual drive on the PC. The file on the card can be accessed (or replaced on the PC to update the mini cartridge).

WORKED WITH AI TOOLS TO BUILD THE PROJECT

Since this would use a number of libraries that I was not familiar with, plus be a first time I tried to project a mass storage (disk) device over USB, I looked for advice from four AI systems - Gemini, Copilot, Claude and Grok. They all identified the two examples of the same functionality that were published on the internet - one using the Arduino development environment and the Adafruit TinyUSB library, the other using the No-FS-FatFS-SD-SDIO-SPI-Rpi-PICO library from Carl J Kugler III in his carlk3 github repository. 

Each of the AI systems burned through eight hours, offering code and setup instructions and then bumbling through build errors, toolchain configuration changes and then fruitless debugging. I tried both methods - the library from carlk3 which had an example inside that was almost exactly what I wanted to achieve, and the Arduino IDE version, alternating which method I used with the next AI tool.

STOPPED USING THE AI TOOLS AND DID IT MYSELF

Since the AI systems appeared to simply be conducting web searches and scanning posts and documents they found, but failing to understand what was occurring enough to properly advise or debug, I dropped the tools and did my own searches. 

I decided to work on the Arduino version leveraging Adafruit TinyUSB. It did involve looking into library code in a few places but I quickly zoomed in on what was going wrong. Within 40 minutes, which included web searches and reading of code, I had the CartInterface working properly. 

ENCLOSING CARTINTERFACE IN A PROJECT BOX AND UPDATING MY V2315CF GITHUB

I have a small plastic project box into which I installed the CartInterface board, exposing the 2x4 header socket on the face and routing the USB cable through a hole. It is now complete and ready for productive use whenever I want to transfer 2315 cartridge images between the physical IBM 1130 with its V2315CF and an IBM 1130 simulator running on a PC. 

I added the code and instructions to the V2315CF repository on github thus others who build this in order to use virtual cartridges with an IBM 1130 computer have this convenience tool. 

Grok joins Claude, Copilot and Gemini in my hall of shame; pleased to hear my 1627 Plotter card was built successfully for another 1130

1627 CONTROLLER CARD SUBSTITUTE WAS ADOPTED AND IS IN USE

Friends at a museum in Europe have made use of the 1627 github project to build a substitute card and install it per the instructions. They have already restored a 1627 Plotter but did not have the controller card installed in their 1130 to make use of it. Today they first tested it out - it is working perfectly and soon they will try out a special feature I added above and beyond the IBM functionality. 

It emits a stream of movement messages on a serial link over USB - that will allow programs to draw plots virtually through the link rather than consume the very rare plotter paper stocks. Those virtual graphs can be displayed live on a monitor and/or printed on a color printer. 

PUT IN THE SAME EIGHT HOURS WITH GROK AS I GAVE THE OTHER AI SYSTEMS

I have a very simple objective in mind, a way to access the virtual disk cartridge files from the Virtual 2315 Cartridge Facility (V2315CF) from a PC without having to open the mini cartridge and transfer the microSD card into a card reader on the PC. It should be easy to have a microcontroller access the mini cartridge in much the same way that the V2315CF does, then present the fat32 file system from the card as a disk drive on the PC. 

The V2315CF makes use of a Raspberry Pi PICO to read and write on the microSD cards, accessing the files through a 2x4 socket that the mini cartridge plugs into. There are several successful projects that people have done with a PICO that accomplished exactly what I want - accessing a microSD card then projecting it to a PC as a disk drive. However, I have yet to get this to work even starting with each of the previously successful projects.

I attempted to lean on the various AI systems to work my way through the creation and testing of the project, but was not impressed at all with the quality of the advice. My impression was that these were good a doing extensive web searches and read through many accounts and documents, but lacked much understanding of the subject. As a result, the advice was often stale or wrong, leading in circles and taking pointless diversions. 

Grok was the last of the AI systems I attempted with this. If the question I asked was straightforward, one whose answer comes out of a manual or is simple syntax, the results were quite satisfactory. When things are going wrong but it is a misbehavior or misconfiguration rather than straightforward syntax, the results were poor. 

I gave Grok the chance to help me implement the example from the no-OS-FatFS-SD-SDIO-SPI-RPi-PICO library that is essentially exactly what I want to accomplish. There is only a very minor difference between what I want and the example - the microSD card socket was accessed by SDIO instead of SPI - thus it should have been a simple matter of building it and being done.

That is not how this went, however. Between configuration issues with Visual Studio Code, problems with the build process and other issues that arose, it did take about seven hours just to get the code to build but somehow it is not working on the PICO. 

I believe I would have made faster progress on all of these by doing my own google searches and read the documents and source code myself, so that I understood what is going on and can achieve some success. 

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

PROGRAMMED THE INITIALIZATION MEMORY FOR THE FPGA

Once I had the license in hand for IceCube2 I could synthesize and generate the bitstream for the FPGA device used in the Virtual 2315 Cartridge Facility (V2315CF) main unit. I grabbed the Lattice HA-USBN-2A programming cable and plugged it into the V2315CF, then powered up the V2315CF. fired up the Diamond application and used it to update the FPGA to use my latest logic.

PRIOR PROBLEM WAS HAVING THE V2315CF AND 1130 DISK DRIVE GET OUT OF SYNC

The V2315CF should be shadowing the seek operation as the IBM 1130 system disk controller commands the internal 13SD disk drive to move the arm to various cylinders. After a sequence of moves, the cylinder where the disk arm stopped was sometimes slightly different from the cylinder that the V2315CF believed we had reached. We fed data from the wrong cylinder of the virtual 2315 cartridge, which the diagnostic program flagged as a failure to seek properly. 

My new logic should be more robust and hopefully track the seeks exactly The goal is to have the seek test of the IBM disk diagnostic pass with no errors. All the other functions such as reading and writing were proven to work correctly, thus this is the last issue before the V2315CF has passed its testing.

RUNNING THE DISK DIAGNOSTIC AGAINST THE V2315CF

I set up the V2315CF for real mode, which is where it moves the internal disk drive arm and determines its sector position based on the disk drive generated signals, but feeds data from the cartridge image we loaded into the V2315CF rather than the read/write heads of the 13SD disk drive. I inserted a virtual cartridge into the box, put a real 2315 cartridge into the 13SD drive, and powered up the system. 

I loaded the virtual cartridge image and let the disk drive spin up and become ready. File Ready light turned on at the 1130 console, indicating it was ready to be accessed. I used the memory loader function I added to the IBM 1130 to load the 1130 memory with the disk diagnostic program, then started its execution. 

RESULTS OF SEEK TESTING

The diagnostic reported that this was not a special CE test cartridge - however the same image runs properly on the 1130 simulator. This may be a problem with how I am starting the diagnostic or it could represent some issue in the V2315CF. I brought the virtual disk image home to check it on the simulator and found that it was good. That means I have some debugging to do on the machine.

One possibility is that my seek routine is not working properly yet, since the indication that we have a special cartridge is a particular word pattern 0xCEDC that is read from cylinder 199, head 1, sector 2. If I am not correctly positioned to that cylinder, the data being read would not contain that magic pattern. 

Whiling away the hours waiting for Visual Studio to install

CLEAN INSTALL OF VS AND PICO SDK - AN EXERCISE IN PATIENCE

I need a functional development environment for the Raspberry Pi PICO but after the debacle with AI misdiagnosing problems and directing changes to my prior install, I had to uninstall and start over. AI had me change the terminal type - command shell, power shell, etc - multiple times which impacts how each new suggestion works or doesn't work when typed into the terminal. It had me override so many things that I had no confidence left; it also would not configure to build anything. 

The MS installer was asked to set up C++, Python and the toolchains for devices like the PICO. This resulted in an installation of some 513 packages. I have 1G internet but the installer is averaging about 300K per second which means that 3GB of download is going to take a v-e-r-y long time. However, the reality is much slower than the reported rates. I am guessing that there is a big lag in starting each new package, because this has been running for a couple of hours and is only about 40% done. 

I then will download and install the PICO SDK which should be a much faster operation. That should allow me to build the example code from the carlk3 github that is cited by everybody and by all the AI systems as the most reliable means to accomplish what I want - to present a microSD card as a disk drive to a PC using a USB cable to a PICO that accesses the microSD card via SPI. 

More experimenting with AI for USB microSD PICO project

RESUMING CLAUDE WORK

Another few hours, still zip. I gave up when finally it did a screen scrape and found some report of issues with TinyUSB and the PICO board support. It then recommended giving up on the Arduino IDE approach and going over to the Visual Studio code that all the other AI systems found and regurgitated. 

DISCOVERY ON MY OWN - CODE OFFERED BY AI FLAWED IN KEY WAY

I did my own research and came across an important detail that the code provided by Gemini configured the key hardware configuration file for the SPI connection to the microSD card holder in a way that doesn't make sense. 

The Raspberry Pi PICO has two SPI components - SPI0 and SPI1. For each, there are only certain pins that can be assigned for the clock, MOSI, MISO and chip select operations of those SPI components. The code from Gemini configured the SD card as SPI0 with SCLK on GP10, MOSI on GP11, MISO on GP12 and CS on GP13. Those pins are okay for SCLK, MOSI, MISO and CS but for SPI1, not for SPI0. 

No wonder the SPI component was hanging up or not working properly. No wonder it couldn't read the card descriptor or other data from the card. 

GOING TO HAVE TO REBUILD MY VISUAL STUDIO AND PICO SDK ENVIRONMENT

I had to restore Visual Studio to the point where it can again successfully build software for the PICO. I can then try to get the code built and try it out, now that I have the SPI functionality issue resolved. 

More experimenting with AI to assist in simple tool to use Raspberry Pi PICO to present microSD card as disk drive over USB

HAVING HAD A POOR EXPERIENCE WITH GOOGLE GEMINI, I TRIED COPILOT

I decided to give Microsoft's Copilot a try and posited the same requirement. Use a PICO to connect to a PC over USB as a disk drive showing the contents of a microSD card, accessed by SPI and formatted in FAT13. I chose the approaches that used Visual Studio and the PICO SDK. 

EIGHT HOURS OF HAND TO HAND BATTLE, NO SUCCESS WITH COPILOT

The same kind of tomfoolery happened with Copilot. Plenty of recommendations with 'official links' that got 404 errors or were deprecated, followed by "you are correct, here is the proper site" which sometimes was just another bogus stale recommendation it had screen scraped from Bing searches. 

It was never able to do a clean compile. Many hours of changes, reinstallations of VS and the PICO SDK and the toolchain. Lots of changes to Visual Studio, which I suspect has left it a shambles. Previously it had been able to cleanly compile the C code for the Virtual 2315 Cartridge Facility project. Many claims that "now we have the evidence" and "this is a rare issue", every single one leading to the same error. Unable to configure the compiler and assembler for the build. Many many tests that never led to a successful diagnosis. 

TODAY I TRIED USING CLAUDE

It was the same mission - microSD card accessed by SPI and presented over USB as a disk drive to a PC. It told me there was a straightforward way to do it using the Adafruit PICO board, avoiding a different PICO board due to compile conflicts - but of course that was stale information and it then admitted that the Adafruit board code was not longer supported, to please use the board file it dissed in the first response.

I put up the code in Arduino IDE and the compile failed.  Pasting the messages to Claude gave me recommendations. First about removing the board manager then reinstalling it, testing that a simple Blink script compiles. Then about manually removing the Adafruit SDFat library manually. 

It actually compiled clean. No guarantee it will work correctly but having something I could actually load to the PICO was an accomplishment after yesterday's fiasco. I took my laptop to the workshop, installed the code on the PICO and gave it a try.

No joy. I then went through about five hours of debugging suggested by Claude, up until I ran out of free chats for the day. It appears that the PICO is freezing during its USB initialization and it may have nothing to do with the code generated for the function, other than certain libraries initializing during the PICO startup prior to one line of my setup function running. 

I will return after 2PM when the Claude timeout ends and see where it takes me. I had also started a Grok session since I am interested in seeing how fundamental the issues are with using AI tools for this sort of project, versus different approaches in the various systems. 

GENERAL MUSING ON AI AND ITS USE WITH PROGRAMMING TASKS

A few were more upfront than the others, showing me a running set of web searches they performed before offering the advice. It confirmed my belief that these are just digesting and regurgitating the postings of others, thus only as good as the original postings. There didn't seem to be any understanding of the actual operation of the code being proffered, nor of the failures other than repeating how others had debugged the symptoms. 

This is different from how I have experienced the AI tools building code for algorithms I requested. They do seem to understand how to structure code and do a very good job with what they produce. I believe the key difference here is that I am asking to do things that involve very complex nested systems, libraries and functions built into the microcontrollers, which are not fully documented other than the source code. 

Since the failures occur deep in those nested systems, the AI falls back on web scraping to find similar symptoms and thus reverts to surface level simplistic analysis. If the AI tool were to ingest and study all of the IDE, microcontroller and various libraries, building up an algorithmic understanding of everything, then it might be able to truly evaluate the issues and chart out successful code at the top level calling or interfacing with these complex systems. 

Wrapping up the successful 1130 memory substitute project

RESOLUTION OF THE ISSUE

As I covered in my last blog post, the addition of a braided ground wire with many fine strands was sufficient to solve the high frequency impedance of the ground connection. The board is now solid as a rock. 

RERAN CPU DIAGNOSTIC AND MEMORY DIAGNOSTIC SUCCESSFULLY

All diagnostics run clean, thus the memory and indeed the CPU are working properly. I can move back to testing of my Virtual 2315 Cartridge Facility which expands the usefulness of the internal disk drive tremendously. 

DECLARING VICTORY AND FINISHING UP THE MOUNTING INTO THE 1130

Based on this, my 1130 MRAM board appears to be working properly. It replaces the core memory stack and associated logic cards that sat in compartment B-C1 of the 1130 system, since that core stack was unrepairable. Three ribbon cables plug into my board instead of into the backplane in compartment B-C1. I disconnected all the power connectors to that compartment, but left all the components in place. 

My design includes two holes for attachment of the printed circuit board onto mounting brackets to hold the board inside the compartment. I fabricated something and have the board in its permanent home. It was necessary to remove the top row of SLT cards from the compartment to allow the PCB, cable connectors and FPGA daughtercard to fit within the air plenum at the top of compartment B-C1. I ran the braided ground conductor from my board to the ground bus of the 1130 to shunt any high frequency noise around the 16 gauge stranded wire ground connections for +12V and ground.

The 1130 is pretty insensitive to the noise generated but it can cause the ground of the board to shift a bit relative to the ground of the rest of the 1130 due to the impedance of the stranded wire at higher frequencies. The braided conductor bypasses the stranded wire for high frequencies. I dressed all the power lines to the board to make things neat. 

GITHUB FINALIZED

The github repository for the 1130 MRAM substitute project is now up to date with all the files, documents and other information needed by anyone who wants to build a replacement core memory for their 8K 3.6us IBM 1130. 

Failed testing of mechanism to read virtual 2315 cartridges conveniently from a PC

VIRTUAL 2315 CARTRIDGES STORE THE IMAGE ON A MICROSD CARD INSIDE HOLDER

The Virtual 2315 Cartridge Facility (V2315CF) makes use of microSD cards to hold a file with the contents of a 2315 Disk Cartridge for use in the disk drive of an IBM 1130 system. The microSD card is kept in a holder that appears to be a miniature 2315 cartridge, presenting pins on the edge that plug into the main box of the V2315CF to use that image for access on the 1130.

In order to read and change the files on the microSD from a PC, one would normally have to remove the microSD card from inside the holder's socket and place it into a card reader plugged into the PC. It is preferable to have the mini 2315 cartridge assembly remain glued together rather than opening it for access. 

I decided to build a simple component that the mini cartridge could plug into, with the component connected by USB cable to a PC. The microSD card will appear on the PC as a disk drive, thus it can be accessed just as if it were removed and put into a card reader but leaving the mini 2315 cartridge sealed.

The unit is implemented on a Raspberry Pi PICO with just a few resistors and the socket added so that the mini 2315 cartridge can plug into the unit. The PICO was programmed to open the microSD card as a FAT file system and present that on the PC in the same way that a USB memory stick appears to be a disk drive. The first design made use of Carl J Kugler III's library no-OS-FatFS-SD-SPI-RPI-PICO after suggestions from Google Gemini. The code did not open the microSD card successfully. 

Since debugging was going to be a bit awkward since I was using the PICO USB cable to appear as a disk drive to the PC, requiring me to wire up a UART link for debugging messages. I tried blinking the LED on the PICO board to let me know where it went astray, but it was some issue the library found with the microSD card image that I couldn't readily determine. 

I went back to the drawing board, this time accepting advice from Gemini to use an Arduino IDE approach, leveraging the PICO core from Earle Philhower to access the microSD card in a more direct and hopefully more successful way. I built that version and loaded it onto the PICO for testing. 

That failed and failed and failed. Lots of unrecognized USB device errors. Gemini seems to be doing brainless google searches of symptoms and steering me to each fix from those posts, without truly understanding what is happening. It gave me fifteen different attempts before doing a test and blaming a timing race between Windows and the PICO. 

It then had me download CircuitPython onto the PICO and load some scripts. That continued to show errors, which several iterations worked on but ultimately it decided that now we had to switch to MicroPython. About a dozen iterations later, including one where it reported that its previous code had an error crashing the boot, it reached the point where it proudly chimed when the USB cable was connected but showed no drive at all.

Now it is recommending that I go to direct C/C++ code, a precompiled load file for the PICO at a repository link. When I went to the github repository, there are no xxx.uf2 files at all. I pointed that out, got a "you are correct, it is only source code" response and then directed to yet another method. Useless. Completely useless. This is simply regurgitating posts it scrapes from the web. 

I am going back to the Visual Studio C code I originally worked with, but asking MS Copilot for how to accomplish it. Hopefully I will find the deviation from what Gemini offered. It is hard to believe that companies believe they can replace programmers with AI at least based on my experiences. 

Needed to wait for Lattice Semi to send the hobbyist license file

FOUND ONLINE COMMENTS THAT SUGGEST FORMATTING OF MAC IS AN ISSUE

Some internet messages suggested that Lattice expects the MAC address of the network interface to be formatted a specific way, without hyphens or colons as most systems display them. My first request changed the subject line to Renewal from their boilerplate New iCEcube2 License Request wording. I then changed it to what they had, since they may have a simple script grabbing the license requests. 

When I still had radio silence for a long period, I did some searches to see if others were experiencing delays or other problems. That is where I found hints that they expect the MAC to be 12 contiguous hex digits although their boilerplate simply asks "MAC address for license generation: " without any format guidance. I sent off a third request just now, hopefully matching the unspoken rules and allowing me to receive the license file shortly.

RESPONSE RECEIVED - LOG ON AND REQUEST LICENSE FILE

I was given a subscription number as the response to my earlier email requests. That had me log onto the Lattice website and request a license for the subscription. With that number entered plus my MAC address without hyphens or spaces, it told me to wait for an email. 

Great news, however, because the license file arrived almost immediately. I set up the program to point at the license and was able to synthesize and create the bitmap which I have to flash onto the FPGA memory device so that the new logic becomes active. 

SUBSTANTIAL PROGRESS DOCUMENTING BUILD OF V2315CF

It is a complex project that requires building and then modifying George Wiley's RK-05 Emulator, building several custom PCBs, modifying the internal disk drive of the IBM 1130, making wiring changes in the 1130, connecting quite a few units together and then installing them in a custom enclosure or inside the 1130 system. 

There is also the need to create Solid Logic Technology (SLT) compatible male and female connectors since we are intercepting signals that run between the disk drive and the 1130. Mini 2315 cartridge replicas are constructed to hold the contents of the virtual disk cartridges, and software is used to manage theses mini cartridges. 

I have generated many images to help guide the builder in these steps, then written about each step with those pictures in support. I had to cross reference many schematics and design files to be able to clearly identify where wires are connected or removed. 

I estimate that the document is now 75% complete. A few more days work and I should be able to upload it to the github repository. 

More this and that, while waiting

BUILDING BRACKETS AND COATING THE 1130 MRAM BOARD FOR INSTALLATION

The gates in a Solid Logic Technology (SLT) generation mainframe have multiple compartments, each hosting as many as 96 SLT printed circuit cards which plug into a printed circuit board that interconnects those 96 card slots plus some top and bottom signal cables. One side of the compartment has the large board with about 2,500 wire-wrap pins that form the 104 sockets for SLT cards or cable connectors. 

The other side of the compartment is a metal cover behind which the SLT cards are inserted. These cards are oriented so that air flows in the 'aisles' between the cards, from bottom to top, to remove heat. Fans sit on the bottom of the compartment and pull air through filters to blow it up over the SLT cards. The top of the compartment is a grill through which the warmed air exits.

Compartment C1 in gate B housed the original core memory for this IBM 1130. It has a three dimensional core memory stack installed on the big board in place of about half the card slots. The remaining card slots have SLT cards which provide the addressing, driving and sensing circuitry for the core memory. 

Since the core memory stack has irreversible corrosion that is eating internal traces, it is no longer feasible to use it on the 1130. I developed a printed circuit board to replace all of the functionality of that card compartment. The three cables which connect this compartment to the rest of the 1130 circuitry are plugged into my PCB instead of the big board in the compartment. All power connections to that compartment are removed, thus nothing is operating in the compartment; my PCB serves as the core storage for the system. 

My PCB is mounted inside the compartment, just below the top grill where the hot air would escape. The three cables originally plugged into the compartment backplane in the top connector slots T1, T3 and T4. My board has those cables fitted and is suspended at an angle inside the gate just below the grill so that it is cooled by the airflow from the fans below. 

SLT backplane/compartment

mounting method

I cut some brass to form the brackets that will hold the PCB at a diagonal under the grill, permitting the existing SLT cards that are inactive to remain in place. The PCB and its brackets were given conformal coating to keep the electrical components insulated from any contact with the compartment walls or grill. The coating should be fully dry by Wednesday when I intend to bolt the memory PCB in place and close up the 1130 system. 

STILL FIGHTING WITH THE HEAD CLAMPS OF THE DIABLO 31 DRIVE

The Diablo model 31 disk drive mounts two read/write heads on the arm, one each for the upper and lower side of the disk platter that is inside the 2315 disk cartridge. These are held in place by three clamps - one each for the upper and lower head holders and a third that holds both head holders in place.

These had been loosened too much and could not be tightened into their proper position. The upper and lower head holder clamps have a tang at the bottom that nestles into a groove on the drive, keeping the clamp upright so that the bolt simply loosens or tightens it. The bolts had been turned too many times and now the tang was not in place, allowing the clamp to spin around. 

Access to the area where the clamps sit is exceedingly restricted and hard to even see into. I finally pulled out a fiber optic camera on a cable that I could push into the area and try to get enough visibility to work. Below is a view from the camera of one of the two head holder clamps, rotated out of position but at least with the bolt still threaded into the end. 

View through the fiber optic camera - not great

I was able to finally work the lower head holder clamp into position so that it tightened up, held from rotation by the tang. That took quite a bit of fussing and work until I finally got the clamp in place.

I then began working on the upper head holder clamp, but that seems jammed against the lower clamp or perhaps against the third (common) clamp. I need to get this one sorted out before I can move on to the third clamp which should be easier to orient once I slide one of the head holders into place. I ran out of steam; this will be waiting for me when I get back into the shop.

CREATING THE BUILD AND INSTALLATION MANUAL FOR THE V2315CF PROJECT

I am now at a point where I will be finalizing the debugging of the Virtual 2315 Cartridge Facility (V2315CF), an ambitious feature that works with the internal disk drive of the IBM 1130 to allow access to a wide range of cartridge images either archived from real disk cartridges or created on IBM simulators. These can be mounted and accessed as if they were real physical disk cartridges, with the internal drive spinning and the arms moving in and out. 

However, the heads do not actually load down onto the one physical cartridge that is inside the drive, thus eliminating the risk of crashes that could destroy the rare disk heads or the disk cartridges. The data for a virtual 2315 cartridge is held on a microSD card inside a little 2" replica of a cartridge which is plugged into the V2315CF main box. The data that is ready by the 1130 comes from the virtual disk image, rather than the heads in the drive. Any data written or changed by the 1130 will be stored on the virtual cartridge's microSD card. 

Virtual cartridge images can be transferred to and from the IBM 1130 simulators that run on modern computers. As well, the collection of physical 2315 cartridges that I have collected will be archived by the other current project, the Diablo Archiver, so that they can be used on the V2315CF. 

The only issue that was outstanding when I had to walk away from the debugging (due to the core memory of the 1130 failing) was the coordination of seeks (disk arm movement between the 203 cylinders of a 2315 cartridge) between the internal disk drive, IBM 1130 and the V2315CF. I am optimistic that this will shortly be resolved, after which I can finalize the installation of the V2315CF in the IBM 1130 that belongs to the Vintage Computer Federation and which I am restoring. 

This is a complicated system that involves modifications to the internal disk drive, several printed circuit boards, a complex power system with battery backup, and the main box of the V2315CF. The main box is an extensively modified derivative of George Wiley's RK-05 Emulator which he built to emulate the DEC disk drive which is a derivative of the internal disk drive from the IBM 1130. There are also the virtual cartridges, software to transfer the disk images and changes to the RK-05 Emulator kit. Finally, a plexiglass case mounts the main box and some of the other components inside the top cover of the IBM 1130, right atop the internal disk drive. 

I began writing a manual which details all the modifications, construction details and other tips necessary for someone to build and install a V2315CF for use with their own IBM 1130. The project is shared on Github along with PCB design files, Verilog and C code and other essential files, but the manual covers the essentials for putting it all together. This manual will be at least 50 pages long and may grow substantially beyond that as I validate that a reader will have all the information they need to successfully implement the project.

WAITING TO PROCEED ON OTHER TASKS

I have no response yet from Lattice about the license file I need to synthesize the FPGA logic for the V2315CF - those changes are what I must test to finish debugging the seek behavior of the project.  

I am waiting for filter and gasket materials to get the Diablo model 31 disk drive in good working order for the Diablo Archiver project to begin reading and saving the contents of the 2315 cartridges from my collection. 

I will also be tied up all day Wednesday providing a tour of Cape Canaveral Space Force Station and its historical facilities to 200 undergrad and graduate college interns, a Brigadier General and other brass in support of the Air Force Civilian Services organization. It is likely that my progress is mostly stalled until Thursday when the awaited items may be on hand and when I can get time to go back into the workshop.