[Coco] Coco DSK Struct

Luis Fernández luis46coco at hotmail.com
Sun Sep 4 21:05:19 EDT 2011


Ok Understood
I do not want it is that cocodiskutil find records with more than 72 entries and not know what to do
the other is  to see that it proves DECB discs with more than 72 fictitious entries
Anyway, I think that will just cocodskutil to 72 entries
> From: robert.gault at att.net> To: coco at maltedmedia.com
> Subject: Re: [Coco] Coco DSK Struct
> 
> 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.
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
 		 	   		  


More information about the Coco mailing list