INMC 80 News

This information must also include the synchronization bytes along with each track/sector header. If we want to record in small amounts, we can divide the tracks up into small sectors, each one say 128 bytes long. After subtracting all the bytes used (in the above example) we are left with only 161,280 bytes on our disk. With a format that divides it up into 18 sectors per track, and 35 tracks per side with two sides.

FM and MFM Recording. Each byte is recorded as a series of pulses, between each is a clock pulse so that we do not lose synchronization. This system of recording is called FM and bears a strong resemblance to the CUTS system when run at 2400 BAUD, where only a single cycle of 2400Hz carrier is used for a 0 or a 1. Now MFM fs a slightly different way of recording. It is possible to leave out the clock pulses, since they do not carry information, and still recover the data. This removal does not work if all zeroes are sent, so the clock is not removed if a zero was transmitted last time and will also be transmitted next time. Thus there are 2t, 3t, or 4t periods between pulses where 2t is the clock rate. For FM recording there are only 1t or 2t periods. Given MFM recording at the same data rate, only about half the information is recorded, as the majority of clock pulses are skipped, thus halving the recording density. If we double the data rate, there will only be the same number of pulses recorded on the disk as with FM recording. So by using MFM recording techniques the data density can be doubled and the drive (or the media) will not notice.

The MFM double density system of recording is more fragile as it has not got so many transitions per byte, but is widely used so must be reliable. It is necessary to restore the missing clock pulses, so a data seperator circuit is employed and write precompensation to improve the chances of recovering the data correctly.

Addressing the disk. The disk is addressed by first positioning the head on the right track, a task performed by the controller chip, and then reading a sector header. The controller reports that the correct track has (or has not) been found and then, if the track/sector header was as required, proceeds to read or write the sector as instructed. When writing, the CPU sends the data to the controller chip byte by byte, the controller converting it to serial data and providing the necessary clock pulses, then feeding it to the drive. When reading, the controller chip receives the data pulses from the drive, re-inserts the clock pulses, sorts it out, and feeds each bit into a shift register. When a byte is complete, a ‘ready’ signal is sent, and the CPU comes and grabs the byte.

Controlling the controller chip is a piece of software known as the ‘disk primitives’. This software is concerned with the mundane business of reading and writing a sector. It requires to know which drive is required, whether you wish to read or write, which track/sector is to be read or written to, where the data is to go to/come from; and other things such as reporting errors, keeping the drive motors running etc. In all this piece of software is usually about 1K long, very involved, and a perfect example of using a CPU to control and supervise the goings on of an external device. An interesting exercise is to try to understand the ‘disk primitive’ source listing supplied with the Henelec FDC kit.

Of course, the ‘disk primitives’ in turn require to be told what to do, and this is the function of the ‘Disk Operating System’ or DOS. A DOS may be as simple or as elaborate as you wish. The simplest in common use for the Nascom is D-DOS, which is nothing more than (nor does it pretend to be anything more than) a number of keyboard routines which accept instructions as to how many sectors are required, which track/sector is the start, whether it is a read or write command, and where the data is to go to/come from. No