06/15/10: Disk ‘skip factor’ explained please by remz, | Tags: , , , , | Category: General, Programming | 4 comments - (Comments are closed)

Disk ‘skip factor’ explained please

Hello all,

I would like to know more about the “Skip Factor” on CoCo disks. First, here’s what I know, please correct me if I’m wrong on anything. Basic’s DSKINI has an optional parameter allowing the user to format the disk using a specified skip factor.
The Skip factor tells the floppy controller where to find a sector on a given track. This was designed to allow an optimized access to sequential read. By default, Basic uses “4″ as Skip Factor.
A “track” is physically a ‘circle’ on the disk. This circle is divided into sectors.
To demonstrate this, let’s illustrate the physical sector on a track:
Physical sector (01 to 18, then it wraps around back to 01, etc..)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 (loop) 01 02 ..
When Basic finishes loading sector 01, by the time it has finished processing and gets ready to start reading sector 02, the disk has kept revolving so it is already on the middle of sector 03 or 04.
In order to read sector 02, the disk would have to complete almost a full spin and thus slowing down the read.
To this effect, the “logical sector” are interleaved, as I said for Basic the default skip is 4, so the layout might look like this:
Logical sector:
01 10 06 15 02 11 07 16 03 12 08 17 04 13 09 18 05 14

This means that after reading sector 01, the disk will be somewhere over sector 06 or 15. Waiting for sector 02 is very short since it is almost the next one.

I read somewhere that OS-9 uses a skip factor of 2, since it performs faster than basic.

Now my questions:
- Is using a skip factor of ’2′ the fastest possible disk access, since using a skip factor of ’1′ would leave no time between sector reads?
- How does the disk controller *knows* what is the skip factor on a given disk?
- Since ‘DSKCON’ routines doesn’t know or care about skip factor, it means that Basic’s ‘DSKINI’ has some special low level access directly to the controller hardware?
- Will any ‘skip factor’ work? i.e.: it would only be less than optimal, but it should no cause problem for Basic?
- How can I experiment with custom Skip Factor using Rainbow IDE, which creates a CoCo DSK using “DECB DSKINI” internally during build?
- Can a program detect what is the Skip Factor on a disk?
- About disk read speed: since a track is physically a circle on the disk, it means that outer tracks are longer than inner tracks. And since track capacity remains constant, it must mean the data on the shortest track will read faster?
- ..and if it reads faster, then sector skip time will be much shorter, thus the skip factor must be set according to the fastest sectors?

I did some quick test but I didn’t notice any speed difference between tracks, I am wrong?

This post was submitted by remz.

4 comments to Disk ‘skip factor’ explained please

  • DarrenA

    First of all, in CoCo terms, the Skip Factor is the number of physical sectors “skipped” between logical sectors. A Skip Factor of 4 looks like this on the disk:

    01 12 05 13 09 02 14 06 15 10 03 16 07 17 11 04 18 08

    A Skip Factor of ’0′ would be the fastest meaning that the track is origanized in sequential order. In fact, when DSKINI verifies the disk after formatting it, it reads the sectors in the physical order they appear on the track, not the logical order. There is enough GAP between each sector such that you can read them in physical order if you don’t do much of anything between each call to DSKCON.

    The controller doesn’t really “know” what the skip factor is. That is determined by the code that writes the format information onto the disk (such as DSKINI). When the controller is asked to read or write a sector, it just searches until it finds one with a matching ID field.

    A program can detect the Skip Factor on a disk by issuing a series of Read Address commands to the controller fast enough to read each ID field in order. This will tell you how the track is organized. This is similar to what my CoCoDisk utility for Windows 2000/XP/Vista does. It displays the detected skip factor when reading or writing to the disk. It uses this information to read or write in physical order for maximum speed.

    There is no difference in read/write speed between inner and outer tracks. The bit timing is constant. The bits on the outer tracks will be spaced farther apart due the larger circumference.

  • Robert Gault

    I’ll try to answer the questions that Darren skipped over and add more info on track timing.

    1) DSKINI does not have any special commands to send to the disk controller indicating a skip factor. DSKINI builds a track in memory and then writes that to the disk. When the track is built, the sectors are ordered in memory as indicated by Darren. When the track is written to disk, the sectors are sequential but the ID’s are not. That is how the the “skip factor” is placed on the disk.

    2) You can’t experiment with skip factors with emulators unless the emulator in question uses a disk image format that contains track and sector IDs. There is only one Coco emulator that creates these images, Keil with .dmk images.
    There is one stand-alone program that generate .dmk images, imgtool / wimgtool from MESS. RainbowIDE can use this tool to create images but far as I know, there is no method for telling RainbowIDE that a specific skip factor is required.
    If you want to build your own disk image, then you can request specific skip factors. However, you will not see any realtime effect unless you use actual floppy disks.

    3) Disks spin at a constant speed. That means tracks at the disk edge move past the head faster than inner tracks. However, since the same amount of track is seen in the same amount of time regardless of radial distance from the center, data flow is constant at any place on the disk.

    4) The use of “problem” in conjunction with skip factor depends on your definition of problem. If the skip factor chosen is far removed from optimal, then disk I/O can be very inefficient.
    If you want a demonstration of just how poor disk I/O can be, try this test with real floppy drives. Format a disk with a skip factor of 1 or 2 and DSKINI, then try to back it up with the Disk Basic command BACKUP. Compare that with a disk formatted under Basic the default skip factor.
    The speed of BACKUP should be maybe 3 to 4 times faster with the default skip factor.

  • remz

    Hi DarrenA, thank you very much for all the information, it is really appreciated. (Edit: Thanks Robert too, your reply arrived at the same time I replied)
    It all makes sense to me now.
    What I just realized is that ‘skip factor’ is not a part of virtual disk, since a typical 35 tracks .DSK file weight exactly 161280 bytes, there is no room for any information about format.
    So this means that emulator will internally ignore the skip factor and always use a ‘linear sector’ format. This also means that when I transfer the DSK to a real floppy disk for my CoCo 3, the skip factor is automatically set by the disk transfer utility. In my case, the PC tool is called DSKINI which takes a .DSK and dump it straight into a 5 1/4 disk. It appears to set a default skip factor, but it is not clear nor configurable.
    However, when I tried DSKINI 0,0 on my real CoCo in order to format the floppy with a fast 0-skip sector, and then copy my test program on that pre-formatted disk, the skip factor is preserved.
    And the result are absolutely amazing:
    I managed to read the whole floppy disk (161280 bytes) in approximately 15 seconds. This means about 10 KB/sec of effective transfer rate.
    I might be possible to load even faster: when the head moves to read the next track, the incoming nearest sector is probably 1 or 2 sectors away. This would require testing I imagine.
    For example, say you are reading track 0, sector 1 to 18. At the end of sector 18, you want to switch to track 1 and read it too. If you start reading at sector 1, the disk may have to complete a full spin.. Anyway maybe this is unneeded.

    • admin

      I think that during the stepping delay the first sector of the new track might have had time to pass by and be almost back to the head again.

      We’d have to see it all on a chart in order to fully realize what’s happening.

      Also, the speed of the motor can be a little off as well which would have an affect on the skip factor doing it’s job since the speed of the CoCo would be the same.