Invested time simulating and correcting code to archive IBM 2315 cartridges on a Diablo model 31 disk drive

ARCHIVAL NEED

I own several dozen 2315 cartridges that contain software for IBM 1130 systems. Rather than risk them directly on the internal disk drive of the IBM 1130 (and rather than risking damage to the very rare disk heads inside the drive), I want to extract the contents and put them on virtual cartridges for use with my Virtual 2315 Cartridge Facility (V2315CF) for the 1130. 

The V2315CF holds the contents of a cartridge on an SD card inside a holder designed to look like a miniature cartridge. When inserted into the V2315CF, the contents are made available for the IBM 1130 to read and update while it believes it is accessing the physical internal disk drive of the 1130. 

A dummy 2315 cartridge spins in the physical disk drive, providing the timing information and offering the user the sounds and vibrations of a running disk and its seek movements. The data flow to the heads is instead fed from the V2315CF, giving the 1130 the stream of pulses that would have come from the heads. Any sector that is written to will have the pulses from the 1130 captured and update the contents of the virtual cartridge. 

The archived contents of the physical 2315 cartridges can also be used with the IBM 1130 simulators running on personal computers, expanding the pool of software available for hobbyists and researchers of the 1130 system.

IBM developed the 13SD drive and used it with the IBM 1130 and 1800 computing systems. It took the 14" disk platters and head technology from the larger 2311 and 2314 disk drives, creating a single platter version that was housed in a cartridge (a 2315 cartridge). 

The 13SD drive was installed in IBM 1130 computer systems, inside the main 1131 processor cabinet. Drives were also put into the separate IBM 2310 cabinet, hosting one or two drives in each cabinet to give expansion capacity for 1800 and 1130 systems. The cartridge was pushed into a front loading slot of the 13SD drive and spun up to use it with the drive, then removed when a different cartridge's contents were desired. 

DIABLO MODEL 31 STANDARD DENSITY DRIVE

Diablo licensed the technology from IBM to design their Model 31 standard density disk drives. These used the same 2315 cartridges and were compatible, able to share data between the model 31 and an IBM 13SD drive. A 2315 cartridge in standard density read and wrote bits at 720Kbps with the cartridge platter spinning at 1500 rpm. 

The data is recorded in a self clocking using a 'double frequency' method where each bit is recorded in a cell with space to record two magnetic flux reversals. The first reversal was always recorded - that was the clock bit. The second time interval would either have a flux reversal, to indicate that the data bit value was 1, or skipped a reversal to indicate that the data bit was a 0. 

The platter was organized into 203 concentric rings of information as the disk head moved radially inward and outward towards the center. 2315 cartridges from IBM had the circumference of the platter divided into eight equal pie slices, with a notch in the hub ring generating a Sector Marker as the drive reached each of the slices. A special double notch at one point generated the Index Marker to define which was the first sector of the eight. 

IBM chose to combine pairs of slices to form the four logic sectors that were used in the IBM 1130 and 1800 systems. Diablo offered cartridges with 8, 12, 16, 20 and 24 physical sectors per rotation. 

Diablo then enhanced the drive, doubling its capacity, as the high density version. Many other minicomputer manufacturers licensed the IBM disk technology and made use of the high density approach. Over time, these vendors also narrowed the size of a ring on the platter to implement 406 cylinders rather than 203. None of these were interchangeable with the IBM 1130. 

The disk controller for the 13SD drive handled disk arm movement differently from Diablo. IBM used a toothed comb with pins that held the arm in the 203 positions. An arm movement involved a command to the disk drive to move 1 or 2 positions in either the forward or reverse direction. The drive made a grunting sound as the pins detented into and out of the comb during seeks. 

A microswitch in the drive indicated that the arm was at the home (cylinder 0) position. Modeling the seek meant tracking the arm position based on the 1 or 2 track movements received as well as the home cylinder indication. A feedback signal turned off when a seek began and switched back on when the arm was settled in position on the new track. The command signals to move, the step size and direction were all defined length pulses. 

Diablo dropped the use of the comb and pins, instead implementing a servo that precisely positioned the arm at the 203 possible cylinder; it was much quieter as a result. The drive accepted different commands. It was given a cylinder number to attain and simply asked to seek. The request was maintained until feedback indicated it was accepted. 

The drive would first acknowledge acceptance of the target cylinder number with one feedback signal, requiring the controller logic to drop the movement request once the feedback arrive. Another feedback signal would turn off when the seek began and turn back on once the arm was correctly in position. The drive did not indicate when it was at cylinder zero.

The drive would emit the Sector Marker and Index Marker pulses, just as did the 13SD, but in addition would output a binary coded decimal Sector Number directly. The controller logic no longer had to interpolate the sector by counting SM and IM pulses. 

Other differences included a Restore command that would move the arm to cylinder 0. Error signals were generated if the requested new cylinder number was out of range or if the seek mechanism somehow failed to work properly. 

FPGA LOGIC WRITTEN A WHILE BACK BUT HAD KEY DESIGN FLAW

My version of the archiving logic used the 13SD seek commands and feedback signals. The Diablo model 31 did not conform to that, thus it required redesign to use the Diablo interface signals. 

ADAPTING TO THE DIABLO INTERFACE

Fortunately, I am quite familiar with the Diablo drives and how to drive them with an FPGA, as I did this to archive all the cartridges from the Xerox PARC library a few years back. Those contained code used on the Xerox Alto computers, the pioneering systems that developed the graphical user interface, ethernet, WYSIWYG and other concepts that made their way into the Apple Lisa, Macintosh and Windows. 

SIMULATING TO VERIFY THE UPDATED DESIGN

I changed the logic and then had to carefully simulate the behavior to be certain that my updated design conformed to the Diablo specifications and would work correctly. This was a long slow process as each rotation of the platter took 40 milliseconds to complete, with more than one turn required to be able to sync up with the SM and IM pulses to correctly mirror the sector number under the heads. This took a long time in simulation before I could observe the movement behavior. 

To fully simulate the archiving of an entire cartridge would require 120 ms per cylinder plus 15 ms for the one track seek. This would approach 30 seconds of simulated time, many, many hours of simulation time on the laptop.