[Color Computer][Coco] Tandy Hard Disk Controller
gene.heskett at verizon.net
Sat Mar 4 20:39:35 EST 2006
On Saturday 04 March 2006 19:18, George's Coco Address wrote:
>----- Original Message -----
>From: "Gene Heskett"
>> On Saturday 04 March 2006 18:32, Mark Marlette wrote:
>>>Test more than one CoCo on a SCSI drive?
>>>That would be a disaster.
>> It could be if the driver doesn't have collision detection, which
>> I'd bet the farm none of them do. I mean, this IS the coco we're
>> talking about here folks. :)
>> But the scsi specs themselves do have collision detection as a very
>> important function, for exactly that reason. For the coco though,
>> that would mean that the middle 16 wires in the cable would have to
>> be used as the handshaking to control that is in the middle of the
>> connector IIRC.
>> Does your tc^3 interface support that somehow?
> I betcha ... OS-9 will do it.
> I betcha ... Nitros9 won't.
I'd have to assume until shown otherwise, that anything os9 is doing,
will be maintained as a function of nitros9. Or re-added if its been
removed as related below.
The original os9 rbf.mn had some interesting features, such as the
ability to handle multiple-sector clusters in the fat. I have no idea
why Kevin D. pulled that out when he gave us that Christmas version, ed
28 way back then, that had that ability stripped out of it. Blows me
away in fact. Then when I volunteered to nitros9 rbf.mn, and started
compareing sources to make sure I wasn't destroying something, I
discovered that ed 28 was missing probably a whole page of code to do
that, but did have one obscure bug that fortunately wasn't encountered
in the normal code path because at that point, no one was using
multiple sector clusters. I put it back in, testing the heck out of it
for correctness, but since I only had one hard drive, it actually got
tested by building disks in an 80 track 720k drive by hand with ded,
for multiple-sector clusters up to 16, at which point I got tired of it
all working and published it back to the then nitros9 crew.
The only thing I didn't think thru was that somebody had come up with
the idea of a 'file has been changed' bit so backups could be done
efficiently, this being done by borrowing a bit in the fd.seg's last,
48th segment, something I never thought would be a problem... I knew
it *could* be a problem, but *I* knew how to prevent it and blindly
assumed everyone else would adjust their sas settings as I'd done long
Yeah sure, till somebody with a big hard drive left his sas at the
default of 8, ran out of fd.segs while writing a big file, and then
tried to delete the file to get some disk space back. That set bit
represented LSN0 and possibly a few more sectors too, I wasn't present
at the debacle. He deleted the file ok, but that also left LSN0
unprotected and marked unused as the fat was cleaned up, so the next
write destroyed the disks file structure.
The resultant hurrah & numerous calls for my head on a pike was of
course predictable and entirely my fault for thinking others would do
the sensible thing with their sas settings if they had the disk space.
After all, its truncated at the files closing, so the fact that you may
have had another 252 sectors allocated while the 3 sector file was open
was a non-issue unless there wasn't that much space left on the drive.
That "I've been changed" feature, has of course been removed in the last
version of rbf.mn, so its safe again I believe, but backups are once
again always made with a full level 0 backup instead of just the
changed files only. I did rather like the idea myself, but...
Anything else would have required a database file with the dates of
every file on the disk in it, code to compare dates and act
accordingly. Not impossible, but certainly a bit cumbersome to say the
least, not to mention it would probably take 2-3x the time to do a
backup. As that was a 3 day job of feeding a 765K disks to a floppy
about 16 hours a day for my Maxtor 7120s drive that was about 2/3rds
full, and over a week to do a test recover, its obvious that a more
capricious storage vessel than a 84 track ds disk can hold.
But this discussion has now rambled well off course so I'll shut the
So test it. But I have doubts that the original os9 drivers ever
contained the collision handler, blindly assumeing that the controller
would forever remain the only host on the bus. I doubt they even do a
disconnect while waiting for the drive to process the command since the
drive is probably ready before the disconnect protocol is even
underway. Hence its another why bother when every clock cycle counts.
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
More information about the Coco