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

[Gene Heskett]

On Monday 10 November 2008, Frank Swygert wrote:
>Why not go one easier? Have the DOS write a unique disk ID the first time it
> does a disk read, then compare that ID every other time? Would be
> easier/faster than a CRC each time. Maybe date/time stamp the disk in that
> normally unused area? Of course that's assuming a real-time clock, or a
> time function in the DOS.

I just sent a modified copy of the nitros9 backup to Robert for checking, it 
preserves the (I was wrong, its only 16 bits) unique disk ID of the 
destination disk when it is used for a backup target.  If this works, then 
the problem should at least be solved for nitros9 in that we would have a 
unique disk ID preserved even if that disk is used to make a backup copy of 
another.  IIRC rbf.mn does check that, often enough is the question...

>-------------
>Date: Mon, 10 Nov 2008 02:08:54 -0800
>From: "Brett Heath" <bkheath at gmail.com>
>
>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



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I dote on his very absence.
		-- William Shakespeare, "The Merchant of Venice"