[Coco] "Mini DOS" in early CoCo disk programs...

[tim lindner]

Robert Gault <robert.gault at worldnet.att.net> mostly wrote:

> It provides functionality that did not exist in the standard DOS [ROM].

I'd like to expand on this. The Kilgus DOS provided file I/O and that
includes record management (with support for variable length records).
This type of file I/O was provided to BASIC but never officially exposed
to M/L programs. All M/L programs "officially" got, was disk sector I/O,
and documentation on how the disk directory was layed out.

Kilgus DOS also provided overlay support. This is used by programs that
need an overall size that is larger than the amount of RAM provided.
Programs can ask Kilgus DOS to overlay portions of the program on top of
where code already resides. Each overlay must be pretty independant of
each other, because every time a program jumps from one overlay to
another it must be loaded from disk.

EDTASMOV is an example of this. It doesn't include ZBUG but can load it
in as an overlay. All they share is a symbol table so it is quite a
natural arrangement.

Also note that the Microsoft DOS ROM for the Dragon line of computers
did expose file I/O to M/L programs. 

...

> The bug is that emulators do not make the 2nd 16 bytes of a directory
> entry all zeros.

I don't think you mean the emuators, themselves, are at fault. But the
authors of the programs that attempt to move files to and from disk
images.

> This bug strikes primarily with a newly created .dsk image when PORT 
> or a similar utility is used to load the image with files. The second
> sixteen bytes of the directory entries are left as $FF $FF $FF etc.

As you know, Robert, Kilgus DOS loads in the entire 32 byte directory
entry, then uses the second sixteen bytes for variables associated with
the file. The Color Computer Disk System Manual only refers to these 16
bytes as "Reserved for future use." And doesn't mention what they should
be initialized with.

The Disk BASIC ROM appearently initializes them to zero, and then
doesn't touch them.

-- 
tim lindner
tlindner at ix.netcom.com                                            Bright