Found promising approach to finish my 1130 disk drive emulator project

2310 DISK DRIVE EMULATOR PROJECT GOALS

I designed FPGA logic to model the behavior of a 2310 disk drive, the internal disk of the IBM 1130. It uses a single 14" platter inside a disk shaped cartridge holder, inserted into the drive so that the 1130 can boot and access the cartridge. The drive has two heads, one for each side of the platter, which can move radially from near the outside to near the inside of the platter stopping at 203 locations called cylinders. The top or bottom of the platter at a cylinder is called a track. 

The drive records a bit over 512K words (16 bit long) on the cartridge, with each of the tracks holding 4 sectors of 321 words. Thus a cylinder holds 2, 568 words. A sector is a quarter pie shaped slice of the disk platter. The data is recorded with four check bits after every word, using an encoding scheme that is kind of like Modified Frequency Modulation (MFM). Each bit cell of 1.39 us duration has a clock pulse in the first half and the second half is the data bit. If the bit is 0, no pulse is emitted in the second half; for a 1 bit, the pulse is emitted. 

Each bit takes 1.39 microseconds to record. A sector has a starting pulse that informs the controller logic when we are rotating into the beginning of a new sector. The beginning of a sector has a sequence of 0 bits followed by a synchronization word (hex 0001), which allows the circuitry in the drive to phase lock on the clock bits to reliably separate bits and allows the controller logic to know which bit is the start of a new word. 

The time from the start of the sector pulse until the first data word of the sector is about 438 microseconds. Each word takes 27.8 microseconds, thus a full sector is a bit over 9.36 milliseconds long. At the rotation speed of 1500 rpm, each sector is 10 milliseconds in duration, the remaining space after the sector is filled with the data is unused.  

My emulator will pretend to have loaded the heads onto the disk platter surface when the drive is turned on. It will emit the pulses every 10 milliseconds to indicate the start of a new sector. It will respond appropriately when the controller requests a movement of the arm radially to a new sector. Then it will produce a string of bits that match what the real disk drive would produce if it was reading a sector. When the controller is writing to a sector, it will watch the stream, remove the 0 words and sync pulse, then grab each 16 bit word from the 20 bit stream produced by the controller. 

I store the contents of a disk cartridge in a file, organized in the same format as used by the simh based IBM 1130 simulator, thus virtual cartridges can be interchanged between simulators and real 1130 systems. The cartridge being accessed is stored in RAM on the FPGA board in my design, but transferred to and from an SD card on a processor board linked to the FPGA. The SD card can hold a library of virtual disk cartridges (IBM named these the 2315 cartridge). 

FIRST ATTEMPT WAS USING SYSTEM ON A CHIP (SOC) BOARDS

My first design used the Intel/Altera SoC chip, which has an FPGA, a couple of ARM processors, and interconnect logic all on a single chip. The board I used has DRAM connected to the processor side, but the interconnect theoretically allows the FPGA side to access DRAM as well. I developed the design to communicate over the interconnect to load or unload a 2315 image from the reserved 1MB of the DRAM where the FPGA holds the disk image. 

My problem came in when I tried to activate the interconnects. This requires boot loaders for the SoC chip and in spite of all the versions of compilers and toolchains I tried, and every single example and manual available, I was unable to get a bootloader which would bring up my Linux image on the processor side with the interconnects I needed activated. I banged my head for months on this problem.

WAS LOOKING AT THE ZYNQ SOC CHIP AS A REPLACEMENT

I had considered the AMD Zynq SoC chip and a board hosting it as an alternative. That would give me different documentation, different toolchains and therefore a chance I could boot up the processor with the interconnects between DRAM and the FPGA logic functioning. That was going to be a major effort, which I put on the back burner.

NEW APPROACH SUGGESTED BY GEORGE WILEY'S RK-05 EMULATOR

The DEC RK-05 is a product derived from the IBM 2310 disk drive, as were all minicomputer drives of the era. It operates at twice the bit rate and thus stores twice as much data as the 2310; it also divides the platter into 8 or 12 sectors rather than 4. However, the similarities are significant.

His approach used separate chips, one FPGA and one processor board, using SPI links to transfer the data from SD card to the DRAM on the FPGA chip. This eliminated all the messy SoC interconnect and boot loader issues. 

MY NEEDS IF I AM GOING TO USE PARTS OF GEORGE'S CODE FOR MY DESIGN

I can either modify George's design to suit the differences with the 2310 drive. These are not trivial. The RK-05 stores the words in a sector and accumulates a checksum which is written at the end of the sector; the 2310 appends four check bits on each word and has no checksum. The data rate of the 2310 is half that of the RK-05. The number of sectors, number of words per sector and other details are different also. However, the physics of the disk drive, such as its sector pulses, 0 word and sync word, two tracks per cylinder and 203 cylinder capacity are all identical, as is the encoding method. 

The other option is to use an FPGA board with adequate (1MB) onboard RAM, a Raspberry Pi board as the processor, and an SPI link borrowing the code from the RK-05 emulator. I have the proper boards in my inventory and already have FPGA code that matches the 2310 disk operation.