Capturing disk writes with emulator easier than expected

RK-05 DISKS WRITE STREAMS MUST BE TREATED LIKE INCOMING SERIAL STREAMS

Incoming streams clocked by some remote hardware, asynchronously to the receiving system, are typically detected by sampling through a window of multiple time periods looking for the point when the one bit will be present. Since a zero bit is the absence of a pulse, one has to wait to be certain that we are not just dealing with a bit of jitter delaying a one bit.

Serial receivers watch the start bits to select the best sampling point, midway inside the one that arrives as the start bit. It then uses its oscillator, set to the expected (baud) rate, to sample for subsequent (data) bits. At the end of the character, everything is reset and we wait again for the start bit. 

The disk stream from the RK-05 disk controllers is clocked in the controller, not the RK-05 disk drive. The data bit pulse if one, or absence of a data bit for zero, has to be detected based on the expectation for when it will arrive. The RK-05 emulator checks across 27 clock intervals looking for a pulse. It is designed to expect jitter from the controller and wants to see the pulse in the range of 200ns to 500ns with the double data rate 2.88MHz clock of the RK-05. Our 2310 equivalent would be 400 to 1000 ns. 

IBM 2310 DISK DRIVE CLOCKS ITSELF AND EMITS KEY SIGNAL TO THE CPU

The design of the 2310 disk drive is different enough that this is no longer needed. An oscillator onboard the disk drive provides the 1.44 MHz rate at which flux reversals are recorded to produce the clock and data pulses. Further, the drive will divide this in half and therefore indicate which half of the bit cell it is dealing with - the clock or the data bit. 

WRITE DATA LINE TO DRIVE IS NOT SENDING PULSES, JUST LEVELS

The way the drive writes is to toggle the current flipflop for the heads at the rising edge of the 1.44 MHz clock when the -Write Data line is low. It is also producing -Write Clock Phase B which identifies the half of the bit cell being processed. The actual creation of a pulse is done in the drive, so the controller just sets a steady level for the data bit value. 

The controller logic in the CPU uses this circuit below to output the value of -Write Data which then flips the head magnetic flux at the 1.44MHz clock edge. The circuit will always cause a flip during the clock portion of the bit cell, but the remaining gates determine when a flip (signifying a one bit) should occur during the data portion of the cell. 

Each word on disk is 20 bit cells long, the first 16 of which are the values of the bits from the IBM 1130 and the last four are a check bit method that writes a 1 it until the total count of 1 bits in the 20 bit field is an even multiple of four. Bit Counter E is on when we are processing the four check bits. As long as the total count is not yet zero modulo 4, a one bit is written out. Once the count gets to zero, the remaining bits are zero. 

When we are not in Bit Counter E state, we are shifting the 16 bits from the CPU out of a shift register, the low order one is bit 15, so when +File Bit 15 is on we write a one bit in the data part of the cell, otherwise zero.

The data is shifted in the register when in the clock part of the bit cell, right when the -Write Clock Ph B signal goes high at the start of the data part. This is occurring while the clock pulse is being toggled in the write head, the next rising edge coming almost 700 ns later. This is plenty of time for the data to shift and be steady at +File Bit 15 before the -Write Data is sampled again to flip or not flip the flux. 

I have to capture the state of the -Write Data line after the shift has occurred but before the -Write Clock Ph B goes low again to start the clock part of the bit cell. All I need is to wait for about 400 ns, which is 16 clock cycles of the FPGA. This is much easier than trying to find the pulse amid a window.