[Coco] LIF util for OS-9?

[gene heskett]

On Wednesday, November 02, 2011 06:56:12 AM Willard Goosey did opine:

> On Tue, Nov 01, 2011 at 10:30:11PM -0400, gene heskett wrote:
> > I think that's seriously kewl Willard.  Unforch I only have coco, os9,
> > and messydos disks here.  At 77, I guess I am too new at this
> > computin game. ;-)
> 
> Naa, you're just more focused than I am.  Instead of hacking under
> OS-9 I'm off playing around with CP/M or HP-BASIC or whatever. ;-)
> 
> But do you know what I'm talking about?  With your background,
> I'd be surprised if you didn't work with hardware that ocassionally
> presented you with a LIF disk or tape.
 
We did have a I've Been Moved System 360 (or was it 36, it was a long time 
back), some sort of a 24 bit system I think, had the grand total of 128k 
words of memory in it, a pair of small 8" hard drives, and a pair of 8" 
floppy's used for backups.  Ran RPG-III IIRC.  That was for traffic and 
logs, billing and such.  I teased the GM that bought it, and the 
$2000/month software, that I had more memory, and possibly more cpu, in the 
coco I had setup in my office.  But I didn't really get involved with it 
other than stringing its twinax networking cables.  Any closer and I would 
probably have wound up involved with the operator of it, a very possessive 
of her man type, so I backed away, too big a diff in age.

> Besides, the real magic is the old ccdisk patch (and current NitrOS
> code) that allows non-OS9 disks that number sectors from 0 to be read
> from OS-9.  The rest is just grudge work.  LIF is, by design, a very
> simple filesystem.

As is os9's file system at the end of the day. So simple that without a 
whole new format for the FD sector, impossible to even add a benign archive 
bit anyplace in it.  Both the directory file, and the FD sector really need 
a complete rewrite, but as that is the guts of it, such would be totally 
incompatible with existing disks.

So what I see as warts, remains untreated.  I would like to see even longer 
filenames by changing from a 32 byte dir entry to a 64 byte version, and 
expand the FD sector address in the last 3 bytes to 5 or 6 bytes.   Then, 
for the same reason, shrink the number of FD.SEG's from 48 to 23, using a 3 
byte size and a 5 or 6 byte address.  The final change I'd make would be 
for DD.SAS to forever move from its default of 8 to at least $80, forever 
putting to rest the possibility of running out of FD.SEG's.

This does NOT mean that each file occupies that much space because the 
unused space is returned to the FAT when the file is closed.

But with the exception of DD.SAS, which I routinely run at $80 on the hard 
drives and $20 on floppies, all the other changes are complete breakage for 
the original format.  So we live with the limits of those warts, using 
large cluster sizes in order to use disks above 132 megs.  I formatted a 
2nd scsi drive of 1 gigabyte for use as a backup drive, but the cluster 
size is $10.  Most of the disk 'tools' work with it except dcheck is making 
a minor mistake twice in the first sector of the FAT.  Robert was looking 
for that sort of thing the last I knew.

{t2|07}/DD/NITROS9/dw3install/6309L2/SCRIPTS:free /s1

"Hesketts really big disk" created on: 2011/01/11
Capacity: 4,219,680 sectors (16-sector clusters)
3,390,640 free sectors, largest block 3,387,312 sectors

Which is AFAICS, correct.  And not yet fragmented to any great extent.

> Willard


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>
"Lead us in a few words of silent prayer."
-- Bill Peterson, former Houston Oiler football coach