Designing method to use SD card disk images in the 1130 disk drive, while it spins and seeks

INTERNAL DISK DRIVE MECHANISM IN THE IBM 1130

The 1130 contains a disk drive based on a single platter removable cartridge, the 2315. It is a 14" platter inside a plastic cover that is slid into the drive from the front. The platter is spun at 1500 RPM while an arm moves read/write heads to different radial positions to select different cylinders of data. There is a head each for the upper and the lower surface. 

The drive is divided into 203 cylinders from outside to inside, separated .01 inch apart radially. The cylinder holds two tracks - top and bottom - each accessed by its own head that flies on the common access arm. 

One rotation is divided into four quarters, called sectors, with the 1130 storing 321 words  on a sector. The 16 bit word of the 1130 CPU is augmented by a four bit error detection code thus the data on disk is 20 bits per word. Physical notches are cut in the bottom rim of the hub and are detected as sector marks as the disk spins.

The head flies on a cushion of air just .000125 to .00015 inch above the surface of the spinning platter. Since dust grains are often larger that this, as is the height of the oil from a human fingerprint, the disk drive and its air must be kept extremely clean. 

Since the cartridge is not sealed, crashes were not rare. Replacement disk heads are extraordinarily difficult to acquire and the crash can also permanently damage the platter surface and its data. 

REASONS TO MAKE USE OF SD CARD RATHER THAN REAL DATA ON 2315 CARTRIDGE

There are a few reasons why we might want to have the 1130 read and write disk images using a storage medium such as an SD card. 

1. We can avoid crashing and ruining the rare platters and heads of a real drive
2. We can provide disk contents to museum machines that don't have usable cartridges
3. We can transfer data from one 1130 site to another easily without sending cartridges
4. We can create blank cartridges at will without having to buy rare physical cartridges

The act of sliding a cartridge into a drive is memorable for people who used an IBM 1130 years ago. Further, the sound of the disk spinning and the grunting sound of the access arm moving in and out to different cylinders is an important part of the realism of a running 1130. 

Therefore, the objective is to insert an SD card into the 1130, slide in a disk cartridge (whose surface will not be touched at all by the heads), turn on the drive and make use of it exactly as if we were physically flying the heads on the platter. Sounds and other behavior will be the same, but we gain the advantages above. 

PROCESS OF SPINNING UP A DISK AND LOADING THE HEADS TO READ/WRITE

The disk drive starts the motor and waits 90 seconds to see if it has reached full speed. At that point, if the motor speed is good, based on the rate of sector mark pulses that are detected. then a solenoid is activated to load the heads.

That solenoid pushes a cam out into the path of the two head pivots, pushing the heads down towards the surface of the disk to cause them to begin flying. The motion also activates a "head loaded" switch that lowers the solenoid current to a holding level. 

The switch tells the drive that it is now ready for access. The drive has the arms out to the cylinder 0 location, called the home position. If the Read gate is turned on, the drive will emit clock and data bits corresponding to the selected track on cylinder 0, repeating the four sectors over and over. 

If the speed of the disk drops below 70% of target RPM or power fails, the solenoid drops which lets springs pop the heads up out of the way of the platter. A stored charge in a bit capacitor drives the arm movement mechanism to yank the arm all the way back off the platter entirely. 

INTERRUPTING THE HEAD LOAD BUT FOOLING THE CONTROLLER

I can remove the pivot pin so that when the head load solenoid activates, it turns on the 'head loaded' switch but does NOT push the cam out. The heads will stay spring loaded far above the disk surface, but the controller logic will believe they are down. It will then believe it is at cylinder 0 and waits for a Read Gate or Write Gate to command reading or writing at the current location.  

There was an alternative where we would use a switch to reroute the wiring from the solenoid to a fixed resistor, while sensing it and using that to override the 'head loaded' switch. I will look into this because it would make the drive even easier to switch between real cartridge and SD card access. 

INJECTING DATA STREAM AS IF THE HEAD WERE FLYING ON THE DISK SURFACE

IBM widely uses wired-OR junctions in their logic rather than an actual OR gate. This behaves similar to a shared bus. All the gates driving signals onto the wired-OR are open collector gates, which either pull the output down to ground or leave it alone. One pullup resistor makes the wired-OR sit at logic high level if all the driving gates are inactive, but any one or multiple of them can pull down to ground.

There is no penalty if more than one open-collector gate is pulling to ground. This is convenient because we can freely inject signals into these wired-OR structures without needing to add gates. 

The Read Gate is actually an open collector gate which pulls the wired-OR to ground when we are NOT asking for a read. Thus, it doesn't matter if the head circuitry is sending 1 or 0, the output is held constantly low. 

This is the place where we can take control of the read circuitry and send in our own data and clock pulses. Since the real heads are lifted by springs, not flying on the surface, they will not be generating any pulses. The line from the amplifier stays high, only going down to ground as pulses are generated to reflect a flux reversal on the disk surface. 

We will add a wire to this pin and, using an open collector gate, pull the line down to produce pulses at the points where we believe they would be emitted when reading a real disk. I don't need to modify any electronics or disconnect the heads; they remain ready to do their job if the head loading cam pivot is put back in place. 

WHAT WE NEED TO CAPTURE TO EMULATE THE DATA STREAM AT THE HEAD

In order to know what bits to send and when to send them, we must know where the heads would be flying at all times. To do that, we have to tap the disk access and position feedback lines so that we can mirror the movement of the arm, e.g. what cylinder we are on. We have to see the sector marks and the reference or index mark that defines the first of the four sectors. 

As the sector and index marks arrive, we calculate where on a track we are. A fixed time past the end of the sector mark is when we send the special sync word that follows a long stream of all zero bits. This allows the drive to separate the data that will follow into clock and data bits. 

We know the size of a sector (321 words of 20 bits) and the time it takes to rotate through it (10 ms) thus we can know exactly what word and bit is 'under' the head at any moment. Basically we have 1.55 bits passing per microsecond or 31 microseconds per word. 

The drive is sent three signals to control arm movement. It has a direction, to or away from the central hub, a step size which is either .01 or .02 inches, and a 'go' signal that commands the movement. The drive sends back a 'home' signal whenever the arm is at cylinder zero. 

The 1130 software has to figure out what cylinder it is currently accessing. The general method is to loop doing backwards steps until the 'home' signal is detected. It then adds for forward and subtracts for backward, either 1 or 2 cylinders depending on the step size. We will do the same to know what cylinder the real drive arm is sitting over. 

The drive is given a head select signal, choosing whether we are connected to the top or bottom surface for our reading and writing. We have to watch this signal to know which data the head would have been seeing. 

Finally, the drive is sent Read Gate or Write Gate signals when it thinks it has reached the target sector (out of four) for a given read or write operation. We are watching those signals so that we can begin generating the data and clock pulses at the proper time. We look in memory for the sector we are sending, since we know the cylinder, track and sector number. Based on time since the last sector mark, we know what word we are feeding to the controller. 

Data is written on the disk surface from the least significant bit (bit 15 for an 1130) to the most significant (bit 0), followed by a string of four bits that provide error checking. The error check is simply that the number of one bits in a word must be evenly divisible by four. If not, the extra four bits make this happen by sending 0000, 1110, 1100, or 1000 to round up. 

CAPTURING DATA WRITES 

The drive creates the write clock signals and sends them to the 1130 device controller logic, which in turn emits data pulses in between the clock pulses and only when the bit should be written as a 1. We can pick this off the backplane of the drive electronics, thus when we see the Write Gate activated and see the pulses come in, we can ignore the initial zeroes, ignore the special sync word, then capture each of the 321 words to write them onto the disk image. 

THE IMPLEMENTATION I INTEND TO CREATE

I expect to build this around a Digilent Arty S7 Xilinx FPGA module and an Arduino Mega 2560. The Arduino will manage the SD card, transfer the data via SPI link to the FPGA board when 'loading' or 'unloading' the virtual disk cartridges, while providing a user interface through an LCD display with buttons. The FPGA will watch the drive signals, model the movement of the arm and disk surface, thus it will produce the pulses during reads and capture the data during writes.

The FPGA module has RAM on the board which is what we access during disk operations, the full content of the disk cartridge having been loaded down to the FPGA from the SD card attached to the Arduino. Any writes to the virtual cartridge are stored in the RAM. When the physical disk drive is switched off (or power is lost on the 1130), the contents of the RAM are written to the Arduino and used to update the image on the SD card - an unload of the cartridge.