[Color Computer][Coco] Tandy Hard Disk Controller

[Gene Heskett]

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.
>
>Gene said......
>
>> 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 
ago.

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 
heck up.

>  Well?

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.

>George

-- 
Cheers, Gene
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.