80-Bus News

think about this one. Why did it only take 30 seconds to copy 200k from Winnie to RAM disk (and a little bit longer the other way round) and yet 45 minutes to copy 650 odd K from Winnie to disk?

The answer was very simple and easily forgotten, and goes way way back to the first disk systems for Nascom and Gemini (remember I had a finger in that pie all those years back). It’s called disk skewing.

All you ever needed to know about disk skew, and were afraid to ask!!

More often than not, customers new to Nascom and Gemini disk systems using the Gemini CP/M ask what the format routine means when it asks for a skew factor. Now I don’t know what the Gemini manuals say about skewing as, in common with most users, I havent read them. But the point is easy to grasp once you know what’s going on.

A virgin disk straight out of the box has nothing recorded on it so the first thing is to format the disk. This defines the way in which the data will later be stored on the disk. Think about what the format program does when it sets up the disk. The format program constructs an image of a disk track in RAM and then writes the image to the disk, a complete track at a time. The disk contains a number of tracks starting at track 0 at the outer edge and working inwards, track 1, track 2, etc., to the innermost track of the disk, be it track 34, track 39, track 76 or 80, depending upon the flavour of drive.

Now the disk is also split like the slices of a cake, radial lines from the centre of the disk to the outside. Where the lines cross the tracks, these become sectors, so each track is sliced up into a number of sectors. The data area of each sector will usually be in multiples of 128 bytes, 128, 256, 512 or 1024. Rarely more than this for reasons to be revealed. The first sector is indicated by the index hole in the disk. Note I said the data area of each sector, as a sector contains more than just the data bytes. The disk controller needs to be synchronized with the data on the disk, so the start of each sector contains some synchronization bytes. Next the controller likes to know were it’s at, so there are a few bytes saying the track and sector numbers (and also the ‘sides’ byte, saying what side of the disk this is, a real pain that one). This is followed by a checksum, the header CRC. Then a few more sync bytes and the start of data mark. After all that, then comes the data, the format program sets these to 0e5h, followed by another checksum, the data CRC. To polish the sector off there are a few more bytes, the sector gap, usually some 0ffh’s before the start of the next sector. The last sector perhaps has a few more 0ffh’s on the end, to pad the sector up to the index hole, as you can never be too precise as to the actual exact number of bytes on a track, as the whole process is at the mercy of the vagaries of the speed constancy of the disk drive motor and the controller clocking speed. Putting too few sectors on a disk is preferable to too many, as the format program which sets all this up in the first place starts and stops writing when it sees the index hole. Too much data and the last sector will be incomplete causing fatal disk errors. (This error occurs when formatting disks on a cold day with the drives running slower than usual.)

From all that, you can see the incentive is to make as few sectors per track as possible. The fewer the sectors the less space wasted on sync and track and sector headers, et al, and the more real data space available. So why rarely more than 1024 bytes in a sector? Well the disk controller is a phase locked loop device, and when receiving data (as opposed to sync bytes which it can recognize) the data transitions should appear in the right places keeping the loop in lock, but mechanical problems like sticky disks, cold (or hot) drives, etc., tend to cause the data transitions to occur out of step. The phase lock tries, but there must come a time when it slips a ‘bit’. The reliability of the system depends on the mechanical stability of the drive and media and the electrical stability of the controller phase lock. Tolerances in either direction must be allowed for, so the best way of keeping the whole thing in step is frequent sync pulses, which from a data storage point of view are a waste of space. So the trade-off is the number of sync pulses, hence the number of sectors, against the ability of the system to stay synchronized. For good reliabilty, this limits it to sectors of no more than 1024 data bytes. No doubt there are those who will argue that their machine can reliably read a whole track at a time. I don’t doubt it, but what about the next machine?

So having demolished the way a disk is mapped, what about this business of ‘skew’? Consider! CP/M is about to load a program. CP/M has a map of the disk internally (it’s stored as part of the directory information). The map CP/M has is not the same as the disk map constructed by the format program. Simply it consists of blocks numbered in sequence from the end of the system tracks and directory space, block 0 might be at the start of a track, or could even be someway through a track. Blocks may be 1, 2 or 4K in size, and CP/M makes a calculation considering the sector size of the disk, and then adding the system track and directory space offset to determine the appropriate track and sector. For the sake of example, CP/M has calculated that the first track/​sector of the program is 4/1. This information is passed to the disk controller to fetch track 4 sector 1. The disk head steps to the correct track, reads data until it recognizes the sync bytes, and reads the next sector header it sees. This header will tell it it’s on the right track (or not), and as this happened at some random time, like as not, the sector number will be wrong. The disk, of course, continues to