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

[Bill Barnes]

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.


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