[Coco] NitrOS9 build errors

[Gene Heskett]

On Monday 20 January 2014 21:42:25 Kip Koon did opine:

> Hi Tormod!
> Oh sorry, I didn't read the last line.  I would like to see it
> complement the TPI.  Thanks for asking.
> Kip
> 
> -----Original Message-----
> From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com]
> On Behalf Of Tormod Volden
> Sent: Monday, January 20, 2014 4:48 PM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] NitrOS9 build errors
> 
> On Mon, Jan 20, 2014 at 12:33 AM, Tormod Volden wrote:
> > On Sun, Jan 19, 2014 at 6:56 AM, Bob Devries wrote:
> >> Hi Tormod.
> >> 
> >> One remaining small (trivial?) issue I have is with the index.html
> >> file which is created in the DSKS directory, in which 80 track
> >> double-sided disks are listed as 48TPI. They should be either 96TPI
> >> or
> 
> 135TPI IMHO.
> 
> > Hi Bob, the format string is generated with "os9 id" from Toolshed.
> > The documentation says it "is intended for RBF disk images only" and
> > "displays information about an image from the identification sector
> > (LSN 0)". From the code it seems that the disk image format byte only
> > has one bit for 48/96 PI, one bit for DD/SD, and one bit for DS/SS.
> > 
> > The index.html is created by 3rdparty/utils/aaw/mkdskindex based on
> > the "os9 id" output, so maybe it has to look at the "Total sector
> > size" as well and adjust the format string? What would be the most
> > helpful format string? TPI or capacity in KB?
> 
> Let me ask again, all of you floppy disk fans. What is the useful
> information you need when you look at that disk image listing? How do
> you normally classify those floppies and drives? TPI? Or tracks?
> Capacity?
> 
> See the refreshed http://nitros9.sourceforge.net/latest/ where I have
> calculated a number of tracks from the "os9 id" output. Would it be an
> idea to replace or complement the TPI with this?
> 
> Tormod

When looking at the .dsk from a dw perspective, its a single sided, 
nominally so many tracks file, that just happens to have an os9 directory 
formatted header.

If concerned with the empty space, one can use "free" on it to see how much 
empty space that could be used is left.

And from what I have been told, you can write an additional file into that 
.dsk that would cause it to expand the file itself, even the directory 
structure should be ok, up to a point, and that point would be reached when 
the new length of the FAT exceeds the remains of the last sector presently 
used by the FAT.  To extend the FAT beyond that would normally extend it 
right into the root directory's FD sector.  I have not actually tried to 
exceed that, so I've now clue how it might behave in that event.

Moving that FD sector out of the way would take mods to the format command, 
which covers the disk with the format byte from end to end, then verifies 
the disk, building up the FAT image as it does the read scan, writes the 
FAT sector and continues the surface scan, writing the next, sector 3 with 
the rest of the verify.  Then it moves to the next sector and writes the 
FD, and writes the std names into the next sector for the root directory.

> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> --
> 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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Required reading: 
<http://culturalslagheap.wordpress.com/2014/01/12/elemental/>
We are Pentium of Borg. Division is futile. You will be approximated.
(seen in someone's .signature)
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.