John Oliger‘s format predates Larry Kenney‘s, giving Larry the opportunity to build on it. As you can see, Larry added the IBM index mark which could make his disks readable using MSDOS, though only through ROM BIOS calls because there is no boot record recorded. Its value is questionable.
John Oliger had a similar advantage from another source, but did not improve on it. The decision was made to use 512 byte sectors instead of 1024 byte five sector ISO MFM. It seemed like a good idea at the time, but nobody who wanted to develop a 2068/Spectrum DOS was expert in disk drive technology. The 10 sector/track 512 bytes/sector format became a de-facto standard. It is really quite unfortunate that this happened, but consider what it would have been like without any 2068 DOS at all.
For reliability reasons, there is only enough room for nine 512 byte sectors on a double density disk. Gaps straddling data records build up splice marks with successive writes. Drive speed variations demand that gaps be a certain minimum size. Controllers need intact gap bytes before and after splices to allow them to detect and ignore them. Both formats above require equipment to be better than average. It is not unusual for available drives to give trouble, much more noticeable with LKDOS.
Using five sectors of 1024 bytes each would require only minor changes in machine code and be invisible to the user, however, it would not be easy to reformat existing disks. New EPROMS would be needed. This does not seem to be a good answer.
John has an updated EPROM which increases the DATA gap acceptably.
LKDOS uses software to FORMAT disks. I have revised this program for my own use for other reasons, so changing it so both system formats MATCH is “duck soup”. Actually, they need not match exactly. The new LKDOS format loses its IBM INDEX GAP, and ignores JLO SAFE’s track sector stagger. The only observable effect is losing CRC errors.
John originally used * to trigger the format editing error which he then used to bank switch his own ROM into low memory. Later he changed this to / because the 2068 partially supports * in relic code, changing syntax error sensing locations and messages. Forcing errors so they can be “trapped” is an ancient trick with programmers, but it is only a temporary way to add new features. It should never be used for permanent functions. The change to / was symptomatic.
Larry Kenney took a different approach. He created a bank switching command to replace error trapping. In a way, *, /, and RANDOMIZE USR 100 are equivalent bank switching instructions. They differ in convenience only as far as the user is concerned, though this is not true for special features each elected to supply in their EPROMs. Both systems work and have their followings.
After formatting a disk, it is necessary to build a disk directory and File Allocation Tables (FAT) in track 0.
Both systems combine the two, but in different ways (An expert would avoid simplification because of future problems). Both system authors pride themselves on this, yet both reap some of the problems caused by it.
John Oliger structures his directory so it contains a pointer to the disk location of the named file. With only one pointer per file, files must be stored without gaps between them so their lengths can be determined. It requires special attention when erasing files. Files must be rewritten to opened up space, and the directory updated. A file which expands enough to require another track must be renamed before it can be stored. These are the “wages of syntax”, a relatively small price to pay.
Larry Kenney structures his directory so it contains a list of pointers for each named file. This permits holes to develop where files have been deleted. The list of pointers is consecutive unless holes are being filled. When this happens, files become fragmented, just as they do in MSDOS.
Defragmenting and closing up holes requires disk to disk transfer, though one drive is enough to do the job.
LKDOS has a file header system which JLO SAFE does not. It decreases the amount of data which can be stored compared with JLO SAFE, though not by much. Header information is placed at the beginning of every track, and some space is wasted at the end. There is enough data to reconstruct a corrupted directory.
The header contains a CRC entry. Because disk controllers generate and check their own CRCs, there seems no reason to include this redundant feature. Larry explained to me that this is required for his RAMDISK, so the directory reconstruction ability is a convenient side effect.
It would be foolish of me to expound on the merits of program features of each system. They are different. It is nice to have both but switching between them isn’t easy — though L. Crawford of London Ontario has a setup you will find hard to believe. His MACRO keyboard deserves a review in itself.
In closing, the 1770 controller was designed to be a cheap replacement controller. It is … cheap. It replaces a set of chips and components without duplicating their performance.
A respectable disk drive puts out a READY signal as soon as it is spinning fast enough to function correctly. Most reach this condition in less than one revolution of the disk. Of course, functioning implies a capable controller.
The 1770 ignores this signal. It isn’t even attached. The reason is simple enough. It does not contain a phase-locked-loop to synchronize its clock with the disk bit rate.
Instead, it contains the equivalent of a UART used with serial ports. By chopping a “frame” into smaller parts, you can change the size of a window in which an event (bit) occurs. That’s why the 1770 requires a higher frequency clock. Like a UART it is set up for a nominal baud rate and cannot tolerate much deviation from that rate.
of nominal. Though this is no problem for a phase-locked-loop, it is for the 1770. The penalty is the loss of many seconds when you use your disk a lot.
Even though John Oliger has done a remarkable job getting the best from the 1770, it is slow with respect to an IBM clone controller card which doesn’t have to wait 5 revolutions before starting operation.