[Coco] Dw4 and hdbdos

[Gene Heskett]

On Saturday 12 January 2019 12:36:31 Bill Pierce via Coco wrote:

> Yes, except use cobbler. It'll make a duplicate of the boot you're
> running. Someone was working on OS9Gen as it was having problems
> creating boots on HDs, but I don't know if it was fixed.
>
> cobbler /x1
>
> Note, cobbler will fail if track 34 is being used.

And thats a pita. And makes me wonder if the creation works like 
my /r0.dd and (my)ram.dr driver.  Thats where if you want to use it on 
your machine utilizing spare memory, (I have a 2meg disto kit in my 
coco3) the format operaion is part of initializing it for use. Building 
a usable os9, rbf compatible filesystem in a block of allocated memory, 
only takes about 100 milliseconds. on the first access the memory is 
allocated, and the disk image is created in that allocated memory. Most 
will not note the lag between the first access to /r0, and the results 
of allocating and formatting it for use as a ramdisk. Its actually that 
fast. Deinizing it when done actually takes a hair longer in perceived 
time lag. And it returns every byte back to the systems memory pool.

I'm not complaining because someone borrowed the idea, thats what I put 
it out there for. For folks to use.

And I just had an epiphany about the track34 problem, and the answer has 
been right it front of me for 25 years.

It could be addressed with Chris Burk's bd utility, which can clear the 
bits occupied by track 34 from the disk allocation map. Someone should 
can that up in a fixed executeable, to be added to the mb script so this 
is automatically done in front of the mb commands that assemble a new 
boottrack in the filesystem, then writes it to the now unallocated track 
34.  Voila! No error for either os9gen or cobbler.

Somebody should just do it.

I'm recovering from a pacemaker implantation and currently on an 
antibiotic that slows my reflexes enough its not recommended I drive or 
climb a flight of stairs, and could cause ripped tendons too. So I'm not 
going down my basement steps to check it out.

Sometimes one needs to step back and look at the forest from a different 
angle before seeing the birch in a grove of pine trees. One could even 
make a quick formatter by clearing the allocation map beyond the top of 
the map itself. But that would need to regenerate a root directory with 
the first two, . and .. entries. And don't forget that the first "root" 
directory is only 7 sectors long, the 8th being the directories file 
descriptor in front of it.  All other directories on a disk can be 
almost arbitrary in size.

The disk would have to have been successfully formatted once before 
however, something I cannot do on my machine so I actually have to 
delete everything on the disk, includeing track 34 before running an mb 
to make a new boot disk. With all the ^&$@ module splitups that were 
done, each of which needs another $27 bytes of system ram to track, I am 
out of system ram as a format needs 6144 bytes for the track image, and 
enough to run itself in, so I get a crash, at least a hot reset required 
after about 3 or 4 tracks have been written. The crash scribbles over 
all mapped in memory, usually requiring a cold boot.

Cheers, Gene Heskett
--