[Coco] Coco DSK Struct

[Robert Gault]

Luis Fernández wrote:
>
> Hello everyone
> I have a question about the logical structure the directory of coconut DECB
> CocoDskUtil useful for me. (and read NITRO/OS9, next release)
>
> Directory entries are stored supposedly from sector 3 to 11 of track 17, giving a total of 72 entries, there are only 68 granules giving a maximum total active files of 68 (one granule per file), but there can always be deleted entries (inactive, no consumption of granules) by completing the 72 entries, part of the problem is that if a byte is 255 means the end of the directory, but not if all entries are full, there is 255 byte, I stop at the entrance 72 or (continue to the entrance 128 or find abyte = 255).
>
> The question I ask myself and the comment you is that prevents found 128 entries (Sector 3 to 18) = 16 sectors * 8 entries X sector?.
>
> Actually, this limited DECB or could create a disc with 64 real and 64 deleted files, or something?
>
> Another thing, I have a software that allowed copying the fat sector 2 to sector 1, for safety, only to remember, lol 		 	   		
>

A better question is why do you want to increase the number of deleted entries 
in the directory? This gains you nothing. There is no reason to have more 
entries in the directory than the number of files that can be placed on the disk.
Disk Basic reuses any entry starting with $00, so there is no waste.

The program that puts copies of sector 2 into sector 1 dates to the time that 
the disk controllers in use frequently trashed the directory track. The File 
Allocation Table (FAT) was the most difficult part of the directory to 
reconstruct. That program is not needed with modern controllers nor with emulators.
RGBDOS and HDBDOS make use of T17 S17 to store a name for the disk in question. 
If you fill the directory track with junk into T17 S17, you would have garbage 
printed each time you used DIR with RGBDOS or HDBDOS. That is part of the 
garbage seen when using DIR on an OS-9 disk.