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