Validation of drive modeling in FPGA by simulation is well underway

TWO OF DRIVE MODELING READY TO DEBUG

In order to inject the proper bits into the read circuitry of the physical drive or to snag written bits to update my virtual cartridge, I have to model the position of the read/write head very precisely. This involves two dimensions of movement - radial and rotational. 

The radial modeling captures which of the 203 cylinder locations the arm might be positioned at. This involves sensing some feedback signals and capturing the control signals which cause the arm to move in or out. 

When the arm is fully retracted to the location of cylinder zero, the home cylinder, there is a microswitch that activates and generates the +Home signal. As the arm moves, it turns off the +Access Ready signal until it is settled into its target cylinder position. 

The drive is given a direction of movement and a step size. The arm can move towards the home cylinder or out towards cylinder 203, depending upon the direction signal. Movement takes place in either two cylinder or one cylinder steps per movement request, controlled by the 10mil/20mil signal. Whenever the Access Go signal is seen, the mechanism moves according to the direction and step size.

My logic tracks the cylinder by accumulating the various movements, such that I should always know where the arm is positioned on the real drive. 

The disk surface is rotating continually under the heads. The disk drive picks up sector mark and index mark pulses to know what part of the circular path is under the head at any instant. My modeling is following the rotation of the real cartridge so that my virtual cartridge can access the data word associated with that spot.

A comparatively trivial part of the modeling is to watch two signals. One, the track signal, selects either the bottom or the top head on the arm since data is recorded on both surfaces of the physical platter in the cartridge. The other is the control that keeps the heads loaded on the physical cartridge and the disk drive ready for access. I don't allow the drive to actually load the heads into contact with the platter but I keep track of the signal. When it switches off, we must stop simulating disk read or write activities. 

There is a complication because the physical cartridge has eight sector marks evenly distributed around the platter, each providing an approximately 160 us pulse. In addition, there is one index mark that occurs shortly after one of the sector marks, which defines the 'start' of the track. The IBM 1130 instead treats the disk as having four equally spaced sector marks, which it accomplishes by blocking every other sector mark during operation. 

My circuitry sees the eight SM and one IM signals, at all times generating the sector number where the head is currently passing. This is used as part of the RAM addressing for the current word, which is an amalgam of the cylinder number, top or bottom head (track), sector number and then which of the 321 words in the sector is under the head. 

A related part of the circuitry has to model the sector in detail. As each sector begins, at the falling edge of the SM pulse, we will have 250 us of zero bits, a specific pattern which is the sync word, then 321 words of 20 bits before we pad the remainder of the sector with zero bits again. My circuit times from the sector mark and moves a state machine through the stages - zero bits, sync word, the 321 data words and final zeros. It generates the word number at the proper time to match what the real cartridge would have passing under the head

STATUS TO DATE

The head (track) selection and head loading signals worked properly. I moved on to the rotational modeling, which is now clearly working as it should. I see the stages in a sector occur at the proper time and the word number increment every 28 us which is a valid timing for a 20 bit word. The entire sector of 321 words fits nicely in the sector with a bit of zero word padding at the end. 

The sector numbers are generated correctly and synchronize properly based on the first index mark pulse received. The programmer issues an IO command which includes a two bit sector number. The drive controller logic in the CPU watches the SM and IM pulses to track the sector coming up, beginning input output operations at the sector mark after an equal compare of target and actual sector numbers. 

The cylinder movement engine is still getting some tweaking, to ensure that I properly interlock to always count the same number of steps as the real arm traverses. There are subtleties - behavior when the arm attempts to move inward past cylinder 202 or outward past the home cylinder. The mechanism reports a successful movement but in fact the arm stops either at home (0) or 202. The +Home signal helps detect this on the cylinder 0 side, but no feedback exists to indicate this for movement attempts beyond 202. 

I should be able to finalize the operation of the arm movement modeling tomorrow and move on to the coding and testing of the bit generation itself - the delivery of the 16 bits of a data word in the proper order and the subsequent four check bits that provide error checking. These have to be timed to coincide with the data separator in the disk drive.

The separator will entrain on the long sequence of zero bits at the start of the sector - a word of all zeros consists of alternating 1 and 0 bits which are the clock and data respectively. This is cemented by the sync word pattern so that the drive is now diving each bit cell into two phases - A and B - that represent the clock bit and the data bit. 

When phase B is active we either inject a bit if the data value is 1 or stay inactive to assert that the bit is 0. Thus, my logic watches the 700KC B signal to time when it produces the raw data stream. We always inject a 1 bit when in the midst of phase A then selectively inject the bit in B based on the data value.