[Coco] continuing to eliminate errors in the nitros9 build

[Gene Heskett]

On Thursday 18 July 2013 20:33:17 Bob Devries did opine:

> OK, Gene,
> 
> I have changed the SAS to 4 on my build, and it still builds without
> error 248 on the single-sided tano and d64 disks.
> So the new instructions are:
> 
> In file /nitros9/level1/d64/makefile
> 
> under $(DSK180K_1):
> 
> change:
> 
> $(OS9FORMAT_SS40) -e -dr -q $@ -n"NitrOS-9/6809/Dragon Level 1 Disk1"
> 
> to:
> 
> $(OS9FORMAT_SS40) -sa=4 -e -dr -q $@ -n"NitrOS-9/6809/Dragon Level 1
> Disk1"
> 
> Regards, Bob Devries
> Dalby, QLD, Australia
> 
This is a bit of a what if, for a very special situation, and that 
situation happens when you approach the disk full state, and there is not 
enough room in the FAT to allocate SAS sectors.

Looking at the disk image by mounting it in drivewire to one of the /x# 
descriptors, then running ded /X#@ to look at it.  IMO there shouldn't be 
any gaps in the FAT till you get to the end of the allocation used.  Each 
new allocation SHOULD start allocating at the end of the previous file. And 
in the one I am looking at, does. 

So until I know better, I believe your failure on vtio ($93F) bytes long 
boils down to out of FAT, no SAS contiguous sectors left after the first 
$700 is written (the first $100 is the file descriptor sector, so the first 
$800 allocation only gets you room for $700 bytes of data, but the next 
allocation request for that same file will get you $800 bytes of room for 
data), and it cannot allocate another $800 to write the last $23F bytes of 
the file, where a smaller SAS might let the file be written, albeit in 
smaller pieces, needing more FD.SEG entries by using the smaller SAS.

Even on floppy drives, I have used default SAS=20 and have for 2 decades, 
and usually $80 for hard drives, gets rid of 99.99% of the file 
fragmentation at the expense of having holes in the FAT where a file has 
been deleted, but the resultant clear spot is not SAS sized so it never 
gets re-used.  When you have a couple of 1Gb drives the sparse spacing 
tends not to be a problem. :)

This SAS thing isn't carved in stone at format time, except for the root 
directory, format fixes that at $800 bytes regardless of the SAS, so you 
will never see a root directory that is more than 8 sectors, including the 
FD in the next sector after the FATs last sector.  You can change it in the 
descriptor on the coco at any time, with nitros9 on the coco being happy as 
a clam.  It gets re-read from the descriptor anytime a file is opened for 
writing.  For reading, the chain is to look at the dir entry to get the FD, 
it gets the size from the FD and then follows the trail of FD.SEG's to 
locate all the pieces of the file. SAS for a read is simply not considered.

Those kingsquest4 disks are strangely organized.  The root dir is NOT 
immediately after the FAT, but it seems to work anyway.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Q:	Why did the germ cross the microscope?
A:	To get to the other slide.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.