[Coco] continuing to eliminate errors in the nitros9 build

Gene Heskett gheskett at wdtv.com
Sat Jul 20 05:47:57 EDT 2013


On Saturday 20 July 2013 05:03:40 Bob Devries did opine:

> Hi Gene,
> 
> > copy: error 248 on file dragonvtio.d
> > copy: error 248 on file startup
> > attr: error 216 opening 'nos96809l1v030209tano_40s_1.dsk,startup'
> > attr: error 216 opening 'nos96809l1v030209tano_40s_1.dsk,startup'
> 
> Did you do the change to IT.SAS in the makefile as we discussed? I
> added -sa=4 (per your suggestion) in file:
> 
>  /nitros9/level1/d64/makefile
> 
>  $(OS9FORMAT_SS40) -sa=4 -e -dr -q $@ -n"NitrOS-9/6809/Dragon Level 1
> Disk1"

I finally remembered to do that, after all the discussion it seems I 
hadn't.  Done now.


> It's all about making a few more sectors free on a very full disk.

Yup.  Thanks Bob.  The biggest single file, os9boot, should have the 
os9boot files FD sector looked at just to see how close we are to running 
out of FD.SEG's.

And this is for the 40 track disk 1?  The FD.SEG's aren't being used except 
for the first one!  The os9boot file, whose FD is at $1B, shows the whole 
allocation in the first FD.SEG, located at a starting sector of $00 00 1C, 
and having a size of $00 38 sectors.  There isn't anything sick bird about 
it other that its evidence the disk image was not created on the coco 
itself.  I just learned something new!
The FAT on that image, tells a lie about my theory explaining the SAS fix.  
Its clear from sector $425 to the end of the disk at $59F, so it is not 
borderline full in actual fact.  So while this -sa=4 works, its only 
putting a Guy Falks mask on the real problem.  Its interesting also that 
the hidden boottrack on the dragon/tano disks is not on track 34, but 
immediately follows the end of the fat sector. 

Still a "track" long but uses some of the next physical track on the disk 
to make that full track allocation. (or since thats a 40T DS image, some of 
the same track on the other side of the disk) The root directory's FD then 
is the next sector after the hidden boottrack.  This says the dos command 
in the d64/tano roms knows about the swapped locations.  Obviously would 
not boot on a coco.

That of course assumes this is correct for the d64/tano machines, if not, 
we've found a huge bug...
 
I wonder, do the Dragon/Tano folks have their own mailing list, we sure 
aren't rattling any cages here...

> Regards, Bob Devries
> Dalby, QLD, Australia
> 
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


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>
<liw> damn, the autonomous mouse movement starts usually after I use a
      mouse button
<wichert> don't use a mouse button then :)
<liw> yeah, right :)
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.



More information about the Coco mailing list