The disk drive mechanism in the IBM 1130 loads the heads once the drive has reached full rotational speed. Spinning the motor will only occur if the drive detects that a cartridge is physically loaded, via a microswitch, and the drive switch is turned on.
The drive pulls 48VDC through a solenoid that forces a rod with a cam to slide sideways. This rod has a spherical shaped cam on it that will push the two head arms so they pivot down and reach the surface of the spinning disk platter. The rod that slid sideways also activates a microswitch which indicates that the heads have been loaded.
I will wire in a switch that will disconnect the signal to load the heads from the solenoid and instead connect it to my Arduino. The switch I am adding will also reroute the heads loaded signal from the microswitch to the Arduino. The Arduino will, if there is a virtual cartridge loaded into the FPGA RAM, in turn send the signal that tells the drive it has succeeded in lowering the heads onto the platter.
With the switch in Physical 2315 position, the drive activates the solenoid and the microswitch informs the drive electronics when the task is complete. With the switch in Virtual 2315 position, the heads are never loaded onto the disk platter but my Arduino can fool the drive into believing its load command was executed.
MY TEST OF THE METHOD
I am not yet ready to wire up the switch, but the leads to the microswitch and to the solenoid are available on a terminal block at the rear of the disk drive. The pick signal can be unhooked and then I can short the microswitch to indicate that heads are loaded.
Step one was to pull the connection from the solenoid to the sliding rod, to that it will not move even if I am not successful with my methodology. We don't want the heads forced into each other.
Step two was to put in an actual cartridge to continue my testing. I had to power up the system as the blue handle on the front of the drive must be unlocked by a solenoid under power.
At this point, I discovered a hiccup that requires a bit of tweaking to my method of converting the drive for dual Real/Virtual cartridge operation. I didn't continue with testing because I want to solve this and then test with the final mechanisms in place.
OOPS - THE DISK ARM IS PHYSICALLY BLOCKED FROM SEEKING IF HEADS NOT LOADED
The mechanism to load the heads involves a long bit of metal that pivots on an axis parallel to arm movement. It has a very strong spring holding it to one side of its travel, with the solenoid responsible for moving it to its other extent when the head load signal is active.
This long bit of metal is in the path of the arm mechanism, so that it can't be slid outwards towards the center of the disk when the solenoid is not activated. This also protects the arm from jostling back and forth during shipping or physical movement of the 1130, but it would block the drive from performing a seek.
The original goal was to modify the drive such that it has the one switch, Real versus Virtual, that effects all the changes. That would permit it to operate as designed with physical cartridges and the heads actually reading and writing the surfaces, or to move without head contact in virtual mode. Discovering the mechanical interference of the pivoting metal with the arm mechanism means my design would not work.
EXPERIMENTING UNCOVERS A POSSIBLE SOLUTION
I carefully operated the lever that is pulled by the solenoid, watching when it began to move the heads downward towards contact with the disk surface. At the same time, I tested the interference between the pivoting metal and the arm mechanism.
I discovered that there is an early range of motion where the metal is pivoted far enough to allow the arms to move in and out, yet the cam has not yet contacted the heads to move them down. More fortunately, it is a reasonably wide range of positions so that we can safely pick a spot that is certain to NOT load the heads but certain to allow seeking.
I believe that I will need to design and install a mechanical stop that keeps the lever a bit activated and the pivoting metal rotated slightly, with the solenoid completely deactivated. This won't interfere with the solenoid actually pulling the lever to load heads when we are in Real mode. It also won't activate the Heads Loaded microswitch, so that this can be controlled by my Virtual 2315 Cartridge system when we are running in Virtual mode.
FUTURE TESTING ONCE I INSTALL THE MECHANICAL STOP AND ADJUST IT
Once again I will insert an actual cartridge into the drive. Switching on the drive, I should observe it achieve full rotational speed. The drive waits 90 seconds for air to be purged of particles before it attempts to load the heads.
I would need to observe that the signal to load the heads is given at the proper point, but that the solenoid does NOT activate with the wiring the way it will be when switched to Virtual mode.
The next step is to short the heads loaded microswitch and verify that the File Ready lamp on the front of the drive is activated. If this occurs we have completely tricked the drive electronics and made it ready to accept input output commands from the system.
CODING VHDL FOR THE VIRTUAL 2315 FPGA SIDE
I have already implemented the logic to track the cylinder from the access commands issued to the drive as well as to track the sector that the heads are rotating over. There are quite a few other functions that have to be written to finish the disk side.
There is also the SPI link where my Arduino will push down virtual cartridge contents before loading heads and pull back the RAM contents when the drive is switched off. I have finished simulation modeling of the basic one word SPI slave transfer, which will be used by a transaction state machine that receives a command, disk address, 321 words of sector contents, handles a checksum and then exchanges a flag word.
The checksum is a running XOR of all words in the transaction, which is sent by the Arduino when it is pushing down a virtual cartridge and sent by the FPGA when the Arduino is pulling cartridge contents back up. The other side calculates the same checksum and does a comparison. If they don't match, or any other errors are detected, the flag word signals an error.
The Arduino code is written to retry any sector which gets an error either going down or coming up. It also retries any SD card read or write if there is an error detected during the card access.
SPI does not have any error detection built in. If the SPI master on the Arduino pushes down a disk sector but nothing is receiving it on the slave (FPGA) end, the words are sent and silently disappear. The way we detect this problem is with the checksum and flag - since the default word of all zeroes coming back is seen as an error flag.
It does mean that I can start an FPGA transfer from the Arduino even without the FPGA wired up, but the very first transaction and every subsequent one would see an error. The practical result would be an infinite loop trying to write to the FPGA.
Meanwhile I am coding the state machine for the transaction, such that I can eventually verify that transfers are properly verified with good checksums and success flags sent back. That would be visible as the Arduino side completing its virtual cartridge load.
No comments:
Post a Comment