Re: floppy disk change (was Re: 1.15 kernel)

[Michael Schwingen <rincewind@tubul.dascon.de>]

On Wed, May 20, 1998 at 01:21:39AM +0200, Konrad Kokoszkiewicz wrote:
> A very nice theory, but it has actually nothing to do with the practice.
> Actually your "100% perfect hardware disk change detection" can only
> detect if a floppy is changed, if the floppy (or both floppies you swap in
> the drive) are write protected. If both are writable, the TOS 3.06 will

No.

I was talking about Falcon and newer machines when I said "100%" - STs may
be lower.

Modern floppy drives have a "disk changed" signal, and both Falcon and Milan
(don't know about Hades) use this signal - and this works quite well (not
sure about bugs in 4.04 here - on my current TOS it works great), and does
not depend on write protect status.

> To not screw up the filesystem on a changed diskette when you copy
> something to it while the system doesn't even know you changed it. Which
> occurs actually quite often (or: would if you weren't aware that disk
> change detection is broken in most ataris).

The the detection should be improved. A seek to track 0 is the worst
solution I can think of.

> > TOS uses a checksum for sector 0-6 (IIRC) to decide if the disk was really
> > changed or not. Sector 0 alone is not a sure indication, as it may be
> > identical on different disks.
> 
> Yes, I know the theory about TOS behaviour (I read the doc for FLOPFIX).
> The problem is that it DOES NOT WORK. And it is quite unlikely for the
> sector zero to be identical on two diskettes (each has 32 bit random
> serial number generated while formatting).

Only on newer systems. Old DOS versions did not do this - there are quite a
lot of disks which are *not* guaranteed to have different bootsectors. Older
disk copy programs on the ST also did not create a new serial number on the
copy. A checksum about some more sectors (the ones with the important
information about the disk) seems a bit more safe to me.

> > Why not use the hardware to tell you if the disk drive door was opened or
> > not?
> 
> Hardware? Why to build a hardware, if it may be solved by software?

I was not talking about building hardware, but about using the hardware that
exists.

> One more seek to track 0 doesn't hurt anything; I am even not sure if it
> would cause an additional seek, because track 0 is read anyways (the FAT
> is on the track 0).

The FAT is cached after the first read. Your system *will* cause an extra
seek to track 0 for every file operation.

> You may think anything you want, but you didn't see that it really worked.
> I saw both solutions in action, hence I know what's more efficient.

*Effiecent*?

It may be more reliable, but do you really want to tell me that slowing down
floppy access is more *efficient*? What definition of efficiency is that?

And yes, I have tried quite a lot of disk changes when writing the code for
Milan - and it *does* work without seeking to track 0 unnecesarily.

> Actually all that behaviour of ST series (considering floppy disk changes)
> I find as one of the most sad things in TOS boxes in daily usage.

We may talk about fixes for pre-Falcon machines - however, I think we should
first see if we can't make the disk change detection work better, instead of
using the brute force method you propose. Only fix those parts that *are*
broken!

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen