[Coco] f83 for the CoCo, Update and a laundry-list of questions.

[Brett Heath]

>> From: Benoit Bleau <benbleau at gmail.com>
>> Subject: Re: [Coco] f83 for the CoCo, Update and a laundry-list of
>> questions.
>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>> Date: Monday, November 10, 2008, 8:02 AM
>> Bruce W. Calkins wrote:
>> >
>> Or, you could create a zero-length file that has a serial
>> number as the filename, and an unused type for the file ( S
>> for serial or something similar). That way, it would not use
>> any tricks that could be incompatible with an enhanced dos
>> rom. You could then check for a file of type S and compare
>> the name with what f83 has in memory.
>>
>> -Benoit


On 11/10/08, Bill Barnes <da3m0n_slay3r at yahoo.com> wrote:
> Simple and elegant. It would also help to avoid the problem, at least first
> time around, of switching out the disk for an exact copy.
>
> Ah the things we programmers need to do to "idiot proof" a user's
> experience. Most of us know not to switch out a disk with open files... but
> some may have a "blonde moment" about it.
>
> -Later!   -WB-    -- BABIC Computer Consulting.


It does look like the best of the "tagging" schemes (with the
exception of OS9's, which is well
enough established that the compatibility issues don't really apply)
but I'm hesitant to use such
an approach (mainly because that type of thing should be handled at a
different level, as part
of a an archiving/backup/inventory application for example).

Also, I'm not overly concerned with detecting the difference between
blank (or even cloned)
disks. First of all, there are no pretensions that this is going to
function as a stand-alone DOS,
it just needs to safely simulate the system functions necessary to
support f83's file I/O calls
which are actually pretty minimal. Secondly, as long as it get's
written correctly, it doesn't really matter where it ends up. I'm not
going to even try to avoid all cases where a user can
shoot themselves in the foot, but it would be nice to help them avoid
doing so while holding a
howitzer or a shotgun;-)

A mitigating consideration that most people are unlikely to be aware
of (unless they've spent
the past few weeks wallowing in the f83 source) is that f83 functions
which lead to
modification of the FAT/Directory tend to be atomic. That is, they
only occur in response
to an explicit user request and control is not returned until all the
updates have been
written out to disk. There's nothing to prevent someone from adding
"non-atomic" I/O
primitives in the future of courxe, but at the point where they start
modifying the
kernel source they're on their own anyway, and if they just try to
tack an "improved" whatever
on top of a system they don't understand they deserve what they get.

I think I'm gonna go with a CRC of the FAT concatenated with the
active directory entries. It really would be handy to have a CRC
function available. There's an old copy of Forth Dimensions with an
article on XMODEM that includes source (which will run as-is) with an
easily extractible CRC routine that can run stand-alone. It also
includes enough discussion
of the algorithm used that converting it to 6809 assembler should be
fairly simple (thanks for the suggestion Bob!).

Thanks to you, and everyone else, for the suggestions. Even the ones
I'm not going to use
really helped me clarify my thinking.

Brett K. Heath