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

NEW TERMINATOR BOARD IMPROVES BUT DOES NOT FIX V2315CF SEEK TRACKING

The Virtual 2315 Cartridge Facility (V2315CF) watches the control signals between the 1130's internal disk controller and the internal disk drive (named 2310 or 13SD or RAMKIT). It shadows the position of the disk arm as commanded by programs issuing XIO Seek commands, since the data to be returned when the software reads from the disk depends on which of the 203 cylinders the read/write heads are positioned over. The V2315CF generates the data signals instead of the disk heads. 

The current situation is that requests to move the arm are obeyed correctly by the disk drive. The physical arm is in the correct location after every move. However, the location as shadowed by the V2315CF is off, short by 1 or 2 cylinders from the actual final position. The error is cumulative.

The programmer requests a movement of some number of cylinders relative to the current arm position. The disk controller implements that as a series of steps of 1 or 2 cylinders at a time, the first being 1 cylinder only if the requested movement count is an odd number; all others are 2 cylinders at a time. 

Glitches on the signals between the 1130 and the disk drive do not appear to affect the disk drive's operation but confuse the V2315CF logic. I can work on two fronts here - eliminating the glitches entirely and/or ensuring that V2315CF is invulnerable to the glitches. 

OSCILLOSCOPE OBSERVATION OF SIGNAL ISSUES USING NEW TERMINATOR BOARD

I set up the oscilloscope to watch +Access Ready inside the 1130 at gate A, compartment C1, where the signal enters the logic card. A second probe was connected to the V2315CF main box where the +Access Ready signal is emitted. A third probe was attached at the pin on the 2310 Interface Board where the cable is attached running to the 1130 logic where our first probe is placed. The final probe monitors the signal as it is produced by the disk drive. 

I triggered on the falling edge of +Access Ready, using my test code in the 1130 to issue an XIO Seek of 3 cylinders forward which is one that we have seen malfunction consistently. I captured the waveforms and looked to see what was happening to the signal at several points in its routing and hoping to understand what is producing the glitchy behavior. 

I can see a very strong drive from the output chip on the V2315CF and then substantial ringing of the signal where it enters the 1130 logic circuits. Part of the problem is ground bounce between the 2310 Interface Board, the V2315CF, the 1130 and the disk drive. I will add some wire braid for high frequency ground paths, although that is not the issue here. 

NEW LOGIC IN FPGA TESTED TO SEE IF IT MATCHES DISK ARM POSITION

I modified the seek shadowing logic in the V2315CF and installed it to the flash memory that initializes the FPGA. I ran some seeks of various sizes, noting for each whether the arm position matched the intent of the seek and whether the V2315CF reported cylinder matched the other two. 

We were down to one issue with the shadowing. The V2315CF seemed to miss the first seek, that error in positioning remained for all subsequent seeks. I tracked that down to an error in my Verilog, where I look at the state of the Home signal and don't bump the cylinder when it is on in real drive mode. That means we don't count the first step away from cylinder 0.

I updated the logic and tested again. The disk drive and V2315CF are in complete agreement with the seek amounts I executed. I ran a series of forward seeks in a small program, issuing the next seek as soon as the previous one caused an operation complete interrupt. I moved 40, 20, 10, 7, 6, 3 and 1 cylinders with the short program. It completed in a fraction of a second with the disk arm and V2315CF showing the current cylinder location as 87. 

Testing my new seek logic for the Virtual 2315 Cartridge Facility - part 9 - Fixed cylinder 202 issue

ADJUSTING THE FORWARD CRASH STOP ON THE INTERNAL DISK DRIVE

Crash stop when arm is not at 202

Arm against crash stop just past 202

In order to be safe, I changed the stop to a gap of .008", giving the maximum margin for acceleration while still blocking the ability of the arm to move to cylinder 203. With an attempt to move 20 mil, the arm should stop and the detent should still fall back into the notch for cylinder 202. 

Just as importantly, it should not do anything bad if it gets a 10 mil step thus engaging the odd detent instead of the even detent. Looking closely at the positioning rack, I can see there is a notch at the 203 location which the odd detent can enter. 

The way you read the location is to look where the right detent is pointing. The numbers are etched every 40 tracks, with a large vertical bar at the 20 track intermediate point. The fine vertical lines on the positioning rack mark each 4 track step, with a notch in between at the 2 track point. The left detent (odd) will fall in to indicate that the location is the number you read from the right detent plus 1. 

The picture is of the arm when I had a .006" feeler gage between the crash stop and the arm, the arm not quite far enough along to let the even detent fall into 202. However, you can imagine the rack slightly to the right so the right (even) detent enters the 202 notch. This is where the arm stops at the last legitimate location. 

If we attempt a 1 track (10 mil) step forward, the drive flips which detent is used to stop, now engaging the odd (left) detent. Since there is a notch there that the odd detent can enter, it will try to hold the arm there. That means the drive is trying to be at 203 but the mechanical stop is trying to keep it from moving past 202. 

It may be slightly mispositioned to read or write on the cylinder but it is a reasonable state to stop in. As long as the circuitry in the disk drive turns off the acceleration of the arm so it doesn't lock up buzzing, this is a decent outcome. It will back up correctly. A step of 10 mil will bring it back to 202 with the even detent engaged, a 20 mil step will move it to 201 still using the odd detent. 

The IBM maintenance manual blithely instructs the field/customer engineer (CE) to run the drive, use the CE switches to move the arm out to cylinder 202, then adjust the crash stop to a specific gap. The stop is a bolt that is threaded into a big block holding the arm mechanism together, with a nut that locks it in position. 

The issue is that the slot in the bolt that one turns to adjust the crash stop is directly against the 2315 cartridge case that is in the machine. There is no room to fit a tool in there to turn that once the nut is loosened. If I remove the cartridge, the drive will not spin up nor load the heads, thus it wouldn't allow arm movement or perform seeks. 

However, I can manually push the microswitch that detects a cartridge is inserted, to allow the drive to spin up and load the heads. They won't really load for two reasons - no platter to ride on, but more importantly my modifications have stopped the heads from being pushed down so they will remain safely apart 

I did find a way to use pliers to turn the threads of the bolt after loosening the nut, thus could adjust this with the arm actively sitting at 202. The gap was much too small, so I adjusted it out to a suitable amount that would stop the seek action but not move past 202. 

TRYING TO MOVE THE ARM PAST 202 AFTER MY ADJUSTMENT

The disk drive is designed so that if the cable that plugs into the drive from the controller (or from the 2310 Interface Board in our case) is removed, the Customer Engineer (CE) switches and buttons can control arm movement without having to issue XIO commands or involve the 1130 disk controller logic. 

I moved the arm to cylinder 201 from zero by setting the Step switch to 20 Mil and held the switch at Continuous movement until it got close. I then set the Step switch to 10 Mil and advanced one step at a time until I verified that the arm reached that point successfully. This would have the odd detent in the rack.

I then moved the arm 1 track, with Step set to 10 Mil and using a single advance, which should put the arm at 202. That was verified by looking at the arm . The even detent should be engaged.

Now, the moment of truth. I issued a seek of 2 tracks farther, with Step at 20 Mil and a single movement request, which should leave the the arm at 202 and the drive should recover from the attempt to move past. The even detent should remain engaged. Worked great.

I cycled the drive to get the arm at the home cylinder and used 20 Mil steps to advance the arm to 202. I moved 1 more track, with Step set to 10Mil, wanting to see what happens with the detents and the arm. I looked at the detent and the arm position, as well as the V2315CF. If the odd detent is now engaged, a reverse step of 10 mil would actually stop the arm at cylinder 200 instead of 201, which is not desirable. If the even detent remains engaged, I need to understand the mechanism.

After testing and observation, it does engage the odd detent, but has bounced back to 201. I hooked up the system and did plenty of seeks, with the pathological behavior gone. This problem is now resolved. 

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

FINISHED MODIFYING TERMINATOR BOARD WITH NEW RESISTOR VALUES

The terminator board that fits into the Virtual 2315 Cartridge Facility (V2315CF) main unit is the same one used successfully with the unit in its original role as George Wiley's RK-05 Emulator connecting to a DEC computer to emulate a disk drive that is a derivative of the IBM drive. The terminator implemented the same resistance values as the M903 terminator board built by DEC. 

The impedance of the terminator connections is just over 122 ohms, which may match the impedance of the cabling in the DEC computers. The RK-05 emulator kit offers an option A1 RK-05 to RK8-E that has two IDC 40 pin ribbon cables to make the connections to the controller card, since the RK-05 drive needs 36 signal lines for the interface between disk and controller, deploying ground lines between each signal line on the ribbon cables. 

Ribbon cable characteristic impedance for single ended signals (not differential pairs) is 80 to 100 ohms with interspersed ground wires. Using the DEC terminator board yields a big mismatch in impedance, which will lead to reflections of about 20% of the signal level. If the rise time of signals is faster than 6 nanoseconds the signal will ring and appear to have spurious transitions. 

I determined resistor values to drop the terminator impedance to about 100 ohms, which would minimize the issues even with the current sharp rise times. The Lattice FPGA does not support the means to slow the signal transitions to 7ns or slower instead typically rising at 1 to 1.5 ns.

I removed all the original resistors - a mix of 1206 size and 0603 size for the pullup to 5V and the pulldown to ground respectively - and cleaned up the board.

The original terminator board has a few unpopulated resistor locations - the crude circles show you were to concentrate to see them. 

I installed my 179 ohm pullup and 249 ohm pulldown resistors onto all the positions where I have signals connected to the ribbon cables. The new terminator board was tested and then plugged into the V2315CF to do more testing. 

DETAILED VIEW OF EFFECT OF SIGNAL GLITCHES ON SEEK BEHAVIOR

A glitch on the +Access Ready signal causes the 1130 disk controller logic to malfunction, thus not forming correct step requests to the drive. The disk drive responds to brief glitches in -Access Go that are induced by the +Access Ready glitch, so it does move to the requested cylinder. The V2315CF fails to recognize the malformed sequences thus it does not reach the same cylinder number as either the drive or the intent of the XIO Seek commands. 

The dance of signals we should see is the controller drop -Access Go with -10 Mil Step low, holding it until the drive drops +Access Ready about 5 milliseconds later. When +Access Ready drops, the signal -10 Mil Step will rise from low to high since only the first seek should be a 10 mil step. 

Also at the time when +Access Ready drops, if the count register (Bits 7 to 14 plus the -10 Mil Step which is bit 15) has all bits on, the -Full Word Count signal is dropped which terminates the seek in the 1130 disk controller logic.

The disk drive, meanwhile, moves the arm for another 9-10 milliseconds then raises +Access Ready to indicate the seek step is complete. If the count register is not all ones yet, another cycle of -Access Go dropping with its +Access Ready responses will occur, iterating until -Full Word Count drops. 

Above, we will examine a successful seek of 1 cylinder. We can see the signals conforming exactly to the protocol. After -Access Go is dropped with -10 Mil Step low, we see +Access Ready drop 5 milliseconds later. At that time, the controller changes -10 Mil Step to high, which turns on -Full Word Count, stopping the controller from trying any more steps. At 15 ms from the start of the step, +Access Ready returns to high indicating the move is complete. 

When I did a move of 3 cylinders, however, the glitches arrived and the process breaks down. The arm moved three cylinders but the V2315CF only saw a single cylinder step. Lets look in detail below, zooming in to the time when the glitch first arrives:

At the 5 ms point, when +Access Ready should drop for 10 ms, we see a very short blip downward, circled in red. This turns off the -Access Go and makes -10 Mil Step go high as pointed by the green arrow.

We see another -Access Go, but very brief, indicated by the blue arrow. Since -10 Mil Step is now high, this asks for a 20 mil step. The short drop of +Access Ready just to the left of the blue arrow causes the disk controller to add 2 to the count register, making it reach the all-ones state and turning on -Full Word Count pointed to by the pink arrow. The seek is over so no further step requests. 

The drive did respond to the additional -Access Go, in spite of the prior seek not being finished. It is only a 20 nanosecond pulse, borderline for the Solid Logic Technology (SLT) edge detectors to see but obviously long enough. Somehow the drive managed to do the second step correctly, as the arm did end at the proper spot. 

Since the V2315CF logic is generating the correct protocol dance - keeping +Access Ready low for 10 ms starting 5ms after the falling edge of -Access Go. It doesn't watch for the next -Access Go falling edge until after the 5ms and it misses the defective short mistimed pulse that the disk drive responded to. 

The drive even responded to a 5 cylinder seek with a correct movement. The signal pathology is even uglier, as seen below:

We see that a single step is observed as far as the V2315CF, based on the 15 ms dance expected. Zooming in on the glitch area, we can see how it managed to move 10 mil, 20 mil and 20 mil to achieve the 5 cylinder goal. 

The glitchy +Access Ready is see to the left of the green arrow, resulting in the -10 Mil Step signal going high where the green arrow points. The first step we began is 1 track, but the subsequent moves will be 2 tracks each. A glitch from the controller shown with the first red arrow drives the arm another 2 tracks. Later we see the -Access Go drop for a longer interval, driving the last 2 track move. This adds 2 to the count register, completing the count of 5 and turning on -Full Word Count to complete the XIO Seek. 

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

TESTING NEW SHADOWING MECHANISM

I loaded the FPGA and PICO of the Virtual 2315 Cartridge Facility (V2315CF) with the updated functionality and repeated the tests from before - using the disk in real mode, issuing seeks of various distances. I wanted to check that the V2315CF reported the ending cylinder number that is expected from the distance of the seek, that the disk arm moved to the correct ending cylinder number, and that the program seeks a successful completion. 

The arm appears to be reaching exactly the cylinder it should based on the XIO Seek commands issued. The V2315CF is still missing some counts which is still symptomatic of the glitches from +Access Ready as it appears at the 1130 backplane. This is a combination of the disk controller logic being tripped up by the glitches and the V2315CF misbehaving. 

Interestingly, the disk drive still sees the correct number of steps, even if it is a short glitch on -Access Go that was triggered by the glitch on +Access Ready. While I could probably develop logic in the V2315CF that would be insensitive to the glitches and mistakes of the disk controller, the right thing to do is to fix the glitches themselves. 

The top signal is -Access Go as emitted from the 1130 backplane. The second signal is +Access Ready as it comes back from the V2315CF. This is produced from a timer based logic chain thus the signal going out of the FPGA pin is unglitched but it sure isn't when it arrives at the 1130. The third signal is the -10 Mil Step signal, being advanced to a 20 mil step because the glitch appears to be the drive dropping +Access Ready as it is in the midst of the 10 mil first step. 

SIGNAL INTEGRITY WORK PLANNED TO ELIMINATE THE GLITCHES

I had already ordered new terminator resistors to improve the impedance matching. The parts arrived today and I carefully removed the 113 resistors on one of the terminator boards and clean up all the pads. It is ready for me to solder on my 1206 size 179 ohm and 0603 size 249 ohm resistors, when I get back to the shop.

The new version of the 2310 Interface Board is still in fabrication in China, but I have the parts to put it together if I believe that the signals will be improved by connecting source to destination directly for all the important seek related signals, eliminating the FPGA in the signal path other than to monitor some of them. 

I am going to work on the twisted wire shielding for the cable I made to run from the 2310 Interface Board to the disk drive. I may be picking up induced signals that are leading to the glitches. 

I need to put the oscilloscope on +Access Ready both at the 1130 backplane at as close to the V2315CF circuitry driving it as I can. I want to see exactly what these signals look like that are causing the issue. 

ORDERED THINNER CARTRIDGE BOTTOMS FOR MINI CARTRIDGES

The mini 2315 cartridges used with the V2315CF are built with a circular white PCB marked to look like the top of a 2315 cartridge, mounting the micro SD card socket and other parts underneath, and placed on a 3D printed bottom cover to make it look more like a tiny version of the physical disk cartridges. 

I thinned out the bottom cover a bit. I can't make the depth proportional to a full sized 2315 cartridge because that doesn't allow enough room for the sd card socket and the header pins that connect the mini cartridge to the V2315CF. However, I had excess material on the bottom which I cut back to improve the esthetics a bit. 

Actual color is white

I ordered a batch of 25 from CraftCloud3D.com in white PLA. These will be glued to the bottom of the PCB to make up the mini cartridge. Proportionally, the walls would need to be about 1/4 of the height in order to look like a tiny 2315. 

I could get closer by notching out the space where the right angle 2x4 header is installed (the opening in the front of the image above) so that it hangs down below the bottom of the mini cartridge. The plastic and copper of the header would be visible below the mini cartridge yet the rear portions look like the 2315 in miniature. 

INVESTIGATING THE MECHANICAL STOP AND THE CYLINDER 202 ISSUE

I had observed an issue when the disk controller attempted to move the arm past the physical limit of the disk drive. The disk implements 203 cylinders, thus can move from cylinder 0 (home) to cylinder 202. Seeks are relative operations, requesting a movement of a number of cylinders from the current position. Thus, it is possible to request a movement that would naively move the arm past cylinder 202 (or backwards past the home cylinder). 

The disk does not directly support a relative movement of an arbitrary number of cylinders. Instead, it can move exactly 1 or 2 cylinders, a step size of 10 mil or 20 mil. The disk controller converts the count of relative movement given by the 1130 XIO Seek instruction into a series of 1 or 2 track steps to move the arm to the final destination. 

The drive has two mechanical stops that block the arm from moving past the two limits. In addition, there is a microswitch that turns on when the arm is at the home cylinder, which the disk controller uses to block any further reverse movements. There is, however, no microswitch to indicate that we are at cylinder 202, so the disk controller will try to move forward to complete its count and the disk drive will try to move 1 or 2 cylinders per step until the controller stops requesting steps. 

Cyl 202 crash stop in red, home crash stop nut in green

Moving a step in the drive involves releasing a detent, a tooth that fits into a notch in a rack to hold the arm at its current position. It then accelerates the disk arm using a voice coil magnet up to a set velocity, then decelerates to bring the arm to a stop. The detent is also released to fall into the appropriate notch for the new cylinder location. 

If the mechanical stop blocks the arm from moving, it can't accelerate to the trigger velocity. The circuitry to stop the voice coil acceleration depends upon that trigger being reached. Thus, one of three conditions can occur. First, the velocity reaches the trigger level and the movement stops. Second, some backup method stops the movement of the arm even though it doesn't reach the trigger speed. Third, it doesn't reach the trigger speed and the backup method fails to work, resulting in the circuit perpetually driving the voice coil to accelerate the arm. 

In the third case, the drive makes a continual buzzing sound and even a system reset of the 1130 will not stop it. Only by turning off the run switch can we break the drive of that pathological state. This is exactly what we are experiencing when we try to move past 202. 

There is a vague mention of the backup method - stating that "a resistor" causes the trigger to be turned off in about 40 milliseconds because it charges the integrator that is otherwise only charged by the tachometer sensing the speed of the arm. Normally the acceleration reaches the trigger level in less than 4 ms, so this would definitely be a safety net for the drive when it is blocked from actually moving. 

However, nothing in the manuals defines where this path is or how it works. I suspect I understand the mechanism and the way it might fail - only a very few components could still allow normal arm movement but fail to trigger when the arm is blocked from moving.

My first check will be the setting of the mechanical stop that blocks the arm from passing 202. It must have a gap between the arm and the stop, when the arm is at 202, of .003 to .009 inches according to the manual. This must be wide enough that the tachometer can charge up to the velocity trigger before the arm stops moving, otherwise we reach condition 3 that is the pathology observed. 

A single track is 10 mil wide, .01 inches, thus the outer range of the setting has to be less than this to ensure we don't actually move to cylinder 203. Thus, the max gap is .009" for the stop setting. However, we don't know how close the minimum gap can be and still block a 20 mil step. It depends on how long it takes to accelerate the voice coil to its target velocity for that step size - the velocity needed for 10 mils being lower than that for 20 mils. 

Ideally the design of the drive provides some safety margin so that even with the minimum gap of .003" the target velocity can be attained, but I have no data to see the speed we could reach in that case nor the trigger level needed to shut down the acceleration. 

The gap did appear to be too tight- with a .006" feeler gage in place, the arm did not get the even detent tooth fully to the notch for 202. 

Something occurred to me as I thought about the condition when we are already at cylinder 202 and attempt to move beyond it. If we try to move 10 mil, the disk drive circuits alternate between odd and even detents to achieve a 1 track movement. If we step past 202 with a 10 mil step, the detent will flip from even to odd. 

The tooth can't fall into the notch for 202 - that is a notch on the rack under the even detent. It must fall into a notch under the odd detent, which might put the arm back at 201 or let it set at 203. There is no circuitry to stop the alternation of detents, thus no way to block this if we are at 202 and try a 10 mil step. This does not sound like a useful behavior for the drive, but I can't see how it will detent properly back at 202 in this scenario. 

TESTING THE SEEK PAST 202

I did some testing using the small test program I put into memory. My first seek from cylinder 0 was to reach 201, which it did successfully. I verified the arm position and that the odd detent was the one engaged in the rack. 

I then issued a move of 1 cylinder forward, which caused the drive to successfully stop at 202 with the even detent engaged. Now I was ready to attempt to move past 202 to see what would occur. 

I did a seek of 1 cylinder again, which switched to the odd detent and tried to move past 202. It entered the pathological condition, buzzing with the voice coil steadily energized trying to move the arm forward. This did confirm however that the design of the disk drive does not recover to a good state if the advance past 202 is done with a 10 mil step. 

I believe I tried again, getting the arm to 202 but this time I moved 2 cylinders so that the even detent will remain engaged. This time it attempted the move, ended the seek normally and was sitting at 202 afterwards. My conclusion is that the drive should be shut down and restarted if the program ever tries to move beyond 202, since in the best case it is on 202 but it could slip back to 201, try to hold position without a detent in a notch, or enter the pathological case.

Improved Virtual 2315 Cartridge Facility behavior when drive powered down then back up

SITUATION BEING ADDRESSED

When we have loaded a valid mini cartridge into the Virtual 2315 Cartridge Facility (V2315CF) it should remain active regardless of whether we power the disk drive down and back up. In the real world, a 2315 cartridge that had been inserted in the drive will still be there when the switch if flipped to run. So too, the virtual cartridge should remain available if we spin up the disk drive.

When we have powered down the disk drive, the V2315CF state machine sits in its run level 9, waiting for the disk drive to signal File Ready after the drive believes it has loaded the read/write heads on to the disk platter inside the 2315 cartridge. Once the drive goes ready, V2315CF advances to run level 10 where the 1130 can access the disk however it wants.

Powering down from run level 10 will simply step back to run level 9, since we do have a valid virtual 2315 image loaded into the V2315CF. The next time the disk asserts File Ready after we spin it up, we will go to run level 10 and be able to use the cartridge again from the 1130. 

What was not properly modeled before was that the cylinder number that V2315CF records to match the position of the real disk arm does not go to zero when the drive is powered down (File Ready goes off). That is what the real drive hardware does, but V2315CF naively keeps its previous cylinder number instead.

SIMPLE FIX APPLIED

The same logic in the PICO code that turns the File Ready lamp on or off on the V2315CF main box will now reset or set a flag in the FPGA that forces the cylinder number to 0. Anytime the RDY lamp on the V2315CF is turned off (and the File Ready lamp on the main 1130 console is off), the cylinder will be locked to 0 (home cylinder). Turning on the lamp also unlocks the arm so that seeks from the 1130 can be recorded to set the cylinder to the appropriate number. 

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.