Mike_Z said:
...Can brand new disks be purchased?...
Yes, Athana below makes new diskettes as far as I'm aware.
...Is sector 'Skew' the same as sector 'Interleave'?...
Yes, but you must become aware of what DRI did in CP/M to make a mess of it.
Let's talk about normal interleave first to illustrate the basic advantage. Afterwards I'll explain the DRI implementation.
Interleave of 1:1, i.e. No Interleave, places sectors identified in their headers as progressively incrementing order around the track. This is easy to picture as the sequence of track sectors appearing under the read write head after an index mark would be, for example, 1,2,3... 26.
The reason you might want to interleave the sectors instead is that without expensive high-speed floppy controllers and without huge ram buffers, after you read a sector, you have a delay to transfer it to the host memory. While you're doing that, the floppy is still spinning and sector 2 has already rotated under the read-write head. If you now request sector 2 that passed by while you were busy, you must wait until comes around again, almost a full rotation away. This means you can only read 1 sector per revolution.
You can get around this by interleaving sectors for example at every other 5 sectors. When you format a track, sector 1 is written first, and then other sectors are written until the fifth sector position comes around and it is then formatted as sector 2. The idea is that when you read a sector and delay worst-case before asking for the next sector, that next sector should be pre-positioned to still be nearby so you seldom have to wait a full revolution. Makes sense.
So now the example becomes, read sector 1, delay during transfer as sectors spin under the read/write head, come back and request sector 2, but possibly three sectors have spun under the read-write heads while you transferred data, the floppy controller now looks for a sector 2 ID in every sector header it can now read, but a fourth sector spins under but as it doesn't have the sector 2 ID in its header, the controller waits for the next sector, when the next sector is found by the sector 2 ID in the header the floppy controller reads it in with very near minimal delay in contrast to waiting a full revolution.
Now consecutive sectors are 5 sector widths apart, so the delay to transfer, service interrupts and maybe search a sector buffer, doesn't force the floppy controller to wait a full revolution to find the next sector number. is just a fraction of a rotation away.
Roughly that's like waiting 3/26s of a revolution rather than waiting 24/26s of a revolution for it to come back around. The values of the example are illustrative estimates for a 26 sector example. Its faster because you can read 26/5 or 5 sectors per revolution instead of always waiting for the next revolution to get the next sector... about 1 sector per revolution.
That was normal Interleave.
Now we talk about the CP/M mess.
When CP/M started a lot of floppy controllers only offered 1:1 interleaving, i.e. No Interleave.
DRI wanted to have the advantage of interleave even though technology hadn't caught up for many floppy systems.
So
DRI took it as a given that floppies are always formatted at 1:1 (no interleave). So they called those "physical-sectors" and implemented their version of interleave by creating the concept of a "logical sector" too. The translation of logical-to-physical sector numbers implemented the interleave.
Thus to find out where sector 2 data was really stored among the physical sectors, you used a "skew-table" to translate the logical sector to the physical sector, and then use that physical sector destination to read or write that data for logical sector 2.
The "skew-table" was the logical-to-physical sector interleave created in the firmware, not in the individual sector headers on the track as the latter would be implemented under normal interleave. The fact that the track is dependent upon firmware for any particular system, to read the data correctly, is the weakness of DRI's implementation; particularly in the age of Vintage floppy recovery.
The DRI solution does the job of interleave nicely, but its media track reads and writes being dependent on firmware, is a bad complication. Now to find consecutive sectors on a track, you don't simply increment the sector number and wait for it to arrive as you can with normal interleave, you must now consult a translation used by the computer it was written with. In one computer system, logical sector 2 might be in physical sector 7, but another system might have it in physical sector 5. That means the data can't be extracted until you know the skew pattern used and that normally means you must know what system wrote the data.
As the system ID is not written on the floppy, it can only be identified through knowledge of where the floppy came from or with a little detective work reading unconnected track sectors of raw data from the floppy and then searching for pattern evidence of connections between disjoint sectors to thus reveal the interleave for the whole floppy.
Note it wasn't long before floppy disk controller chips could implement interleave correctly when formatting tracks. It would have been nice if the skew table disappeared as soon as possible. But if you deal in vintage anyway as is more the norm today, you can't get away from this mess. You have to know what system it was formatted for so the skew table can be found.
Had normal interleave always been implemented, all you'd have to do is increment the sector and tell the floppy controller to access it. That would work for all floppies no matter what system programmed it. Note that I'm leaving the directory system of blocking out of this simplifying illustration.
Note too that CP/M implemented for some later systems dropped the skew-table approach and switched to normal interleave. They're easier to recognize because unlike skew-table use, those floppies are not formatted at 1:1 (no interleave). A 1:1 interleave on a floppy almost always means a skew-table was used.
The exception would be a floppy disk controller so well designed that it can support 1:1 interleave without missing any sectors; usually implementing buffering or direct transfer into system memory. These latter designs were rare on CP/M systems during the period of CP/Ms peak use. That's just something else that vintage access has to sleuth out.
...I have been formatting my 8" disks as 77 track, 26 sector, 128 bytes/sector, 250k transfer rate and a 1:1 interleave. Looking at the example CBIOS, it appears that there is a skew of 6 to the sectors; 1,7,13,19. So must I format my floppies with an interleave of 1:6 instead of 1:1?...
That's basically the deal. You format at 1:1 so that physical sectors follow each other consecutively around the track. CP/M using skew-tables assume that floppy formats are always formatted that way. The CBIOS shows an example of a skew-table to implement interleave; in your example every other 6 sectors. So when the system needs to access the 2nd *logical* sector it uses that table to get a *physical* sector to read/write.
Skew-Table use: physical sectors go: 1,2,3,4,5,6,7,8 etc.
Skew-Table use: logical sectors go: 1,7,13,19 etc
So to find the second logical sector, the your table says to look for physical sector 7 to locate the correct data inside.
...is that I should format with an interleave of 1:1. Then in the CP/M CBIOS, the sector translation vector table will convert the physical sector numbers to the logical ones. In other words I do not have to interleave any sectors. The vector table and the software handle everything?...
Yes (almost)
One correction, "...will convert the
logical sector numbers to the
physical ones..."
Physical =
Floppy, a handy phonetic reminder.
Later you might want to convert to normal interleave because almost every floppy disk controller chip is capable of doing it. Its just more complexity you don't need now.
Sometimes its better to walk the path than to be shot from a cannon to the destination.
