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

[Brett Heath]

> --- On Sun, 11/9/08, Brett Heath <bkheath at gmail.com> wrote:
>
>> From: Brett Heath <bkheath 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: Sunday, November 9, 2008, 1:47 PM
>> On 11/9/08, Darren A <mechacoco at gmail.com> wrote:
>> > On 11/9/08, Brett Heath wrote:
>> >>
>> >> ...
>> >>
> ...
>> Teaser2) using DSKCON. What I don't see how to do, and
>> what will
>> become critical as I implement functions that
>> modify the FAT and/or Directory sectors, is a way to tell
>> if the user
>> has changed the
>> diskette since the last time the drive was accessed.
>>
>> If I can't get this without Basic taking over on an
>> error I'll have to
>> implement secondary
>> buffers to hold the unmodified FATS and do a read-back and
>> compare
>> before any updates.
>> That's messy, slow, eats memory and will be another
>> PITA on top of
>> having to emulate functions that should be available as
>> system calls.
>>


On 11/9/08, Bill Barnes <da3m0n_slay3r at yahoo.com> wrote:
> While I won't say that this would be the ideal solution (Im unaware of the
> disk change signal being sent back to the disk controllers we are used to on
> the CoCo, let alone made available to an OS or user program) but as a
> typical RSDOS diskette, if memory serves me right, doesn't use all of track
> 17, what about one sector being used to hold a "disk ID"... only problem is
> the generation of one that is completely unique to a colletion of disks. I
> would imagine the overhead for reading one single sector, pulling an ID code
> from it and comparing it to one in memory for the "open" disk in that
> particular drive would be less than keeping multiples of the whole FAT
> table. This could lead to a "cache"ing of the who directory in the future.
>
> I reserve the right to be in complete error on the above statements in
> regard to efficiency, overhead, and overall function.
>
> -Later!   -WB-    -- BABIC Computer Consulting.

Yeah  pretty sure there's room for that on the disk but your
suggestion gave me another idea
that might be better. Maybe do a CRC of the original FAT instead of
buffering the whole thing.
I'd still have to reread the FAT to generate a comparison CRC but it
looks like that's
unavoidable anyway. In any case it would save some memory and the
overhead of keeping
track of multiple buffers, the CRC could be tucked into the control
bytes of the same buffer
that holds the ram FAT copy.

Of course I have NDI what the algorithm for generating a CRC is but
maybe it's time to learn,
it's the kind of addition to the language that's likely to come in
handy in other contexts.

Anybody know where I can find a crash course in CRC generation?

Brett K. Heath