80-Bus News

rotate, until some time later, the correct track/sector header will pass the head. At this instant, the controller looks for the data start mark, and when that’s found it then reads the following data.

Having got the data, control is passed back to CP/M which now has to calculate the next track/sector required. CP/M decides that the track/sector will be 4/2, the next sector. An instruction is issued to the controller, and the previous process is repeated, except that the controller now knows that it is on track 4 (the last sector was on track 4, and nothing has changed, so the head must still be on track 4). Unfortunately, whilst all this was going on, the disk of course continued to rotate, so by the time the system has made up its mind that it is sector 2 it is looking for, the header for sector 2 has just passed the head. This means that the disk must make a full rotation before sector 2 again passes the head. As the disk rotates at 300 rpm, that means that 200mS must elapse before the next sector can be read. Considering that a typical Gemini system reads a 512 byte sector in 20mS, this hanging about is a real pain. It would take ten times as long to load a program under these circumstances as it would if we arrange the sectors to be in the correct places when CP/M wanted them.

So we introduce ‘skew’ in to the format program, we alter the way the sectors are numbered on the disk, on a Gemini system, a ‘straight’ skew of:

I say something like this, as I haven’t bothered to look at the actual Gemini skew, so I might have it slightly out, but no matter. This is a ‘skew’ of 2, that is the sectors appear in order in 2’s, read one, skip one, and so on. See what happens, having read sector 1, and then requiring sector 2, the longest wait would be 20mS whilst sector 6 went past. Plenty of time to calculate the next track/sector as being sector 2.

Lets suppose that some program we have written is required to read the disk and actually does some preprocessing between sector reads, or that the system clock is running at 2MHz rather than 4MHz. Then things slow up again as even with a skew of 2, the 20mS between consecutively numbered sectors is not long enough. In that case, to restore the speed to something like normal, a skew of 3 may be required.

So by now the business of skewing the disk has been taken care off, the only remaining question is if this problem has been known for a long time, why didn’t Digital Research do something to CP/M to correct the situation instead of skewing the disks on formatting? The answer is that they did, right from the start. This is called ‘logical to physical sector translation’. Inside CP/M is the sector translation table. It assumes that the disk is formatted in 1, 2, 3, … order, and therefore the CP/M calculation to get a certain logical sector must be translated into the appropriate physical sector.

Lets take the case of a skew of 2 illustrated above. CP/M calculates it wants logical sector 1, so it goes to the ‘logical – physical sector translation’ table and looks up logical sector 1 which comes back as physical sector 1. For the next sector, it calculates logical sector 2 which is translated into physical sector 3, logical sector 3 becomes physical sector 5, and so on. There are a couple of good reasons for not using the ‘logical to physical sector translation’ one is that you can’t alter it easily. But worse, if the disk were transported to another machine with a different ‘translation’ the sectors would be read in the wrong order, so data would become garbage and programs would crash. The advantages of using physical disk skewing is that you have control of it and even if a disk were transported to a different machine and the skew were wrong, then the disk would read slowly, but it would get there eventually and get it right.

The very early Henelec/Gemini GM805 had a ‘logical to physical translation’ of 6 which was originally intended for 8″ disk systems. (I think it was built in permanently to CP/M 1.4, so couldn’t be changed to something more appropriate.) This made the GM805 system slow, and I remember sitting down one evening with Eddie Pounce and playing with strips of cardboard numbered in sectors and sliding one against the other until an optimum skew was arrived at. As I remember, it ended up as a negative number, as we already had a positive skew of 6, we needed to skew the disk backwards to improve matters. The skew tables for 2 and 4MHz were then added into the format routine written by Richard Cowdroy supplied with the system to become Version 2.0 of the formatter. All great fun when you have both physical skewing and ‘logical to physical sector translation’.

Back to the problem

So, back to the beginning, how come my stupid copy routine took so long to write out its files to disk. Simple, the timing was all to pot. But not by the obvious skewing problem of the routine taking too much time between sectors. It was in fact a whole different can of worms called ‘sector deblocking’, something I’ll hold over until another time, but brief explanation is required.

CP/M was originally designed for use with 8″ systems conforming to IBM3740 spec. The disks had physical 128 byte sectors, so it was sensible to make CP/M work internally with 128 byte sectors.