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

["Howard Chu" <chu@platinum.com>]

I agree with Konrad, current TOS handling of floppy disk-change is
primitive and wasteful. Unfortunately, without a genuine media-change
hardware signal (and corresponding interrupt) there's not a lot that
can be done to improve the situation. I also agree that floppy disk
access is already slow, and slowing it down further should be avoided
if possible. Currently TOS uses a VBL routine to poll the write-protect
status of the drives. It's inefficient, but it really ought to be good
enough to detect that a diskette was removed/inserted. In the default
case, where the write-protect status has not changed, I don't believe
it's necessary to re-read the boot block. Explicitly reading at every
directory operation would totally negate any effort to cache FAT info.

> -----Original Message-----
> From: Konrad Kokoszkiewicz [mailto:draco@mi.com.pl]
> Sent: Tuesday, May 19, 1998 4:22 PM
> To: Michael Schwingen
> Cc: MiNT mailing list
> Subject: Re: floppy disk change (was Re: 1.15 kernel)
>
>
> > > BTW. I always had troubles understanding why there are so
> many problems
> > > with floppy disk change (or media change in general, but it beats me
> > > considering floppies) on ST/TT/Falcons. Is there any reason
> for not using
> > > the most simple solution, as re-reading the bootblock and updating the
> > > internal filesystem data strucres accordingly (like clearing
> FAT or inode
> > > caches for example), if the bootblock differs from what was
> read before?
> >
> > No.
> >
> > However, you should only do this if you think the disk *might*
> have changed.
> >
> > The disk change on older STs works quite fine, and Falcon and
> newer machines
> > have hardware disk change detection which can tell you 100%
> sure if the disk
> > was removed from the drive (it can't tell you if the same disk was
> > re-inserted, so you should check and *not* clear open files etc. in that
> > case).
>
> 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
> tell you 100% that no change took place, no matter how many times you
> really changed the disk.
>
> > > Actually, any disk operation, like opening a file for
> read/write/update or
> > > reading directories could cause bootblock to be re-read by
> the system.
> >
> > Why?
>
> 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).
>
> > This is absolutely unnecessary and will cause a lot of extra
> seeks to track
> > 0. Just think about copying a lot of small files from floppy to harddisk
> > ...
> >
> > > Then we have the serial number there, the volume name and the
> number of
> > > free clusters to check if the diskette is still the same.
> Perhaps it will
> >
> > Number of free clusters? In sector 0?
>
> Yeps. Where you'd exspect number of free clusters?
>
> > 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).
>
> > 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?
>
> > > a) floppies aren't the main storage media anymore (harddisks are)
> >
> > Floppies are still used for data transfer - and they are slow
> already, so
> > there is no need to slow it down even more unnecessarily.
>
> 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).
>
> > > b) this perfectly works for SpartaDOS on 8-bit Atari, though XL serial
> > >    drives are 10 times slower than our floppy drives. I have no reason
> > >    to not using a working solution from 8-bit computers, if such a
> > >    solution works.
> >
> > It may work, but is it a good and efficient solution? I don't think so.
>
> 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.
> 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.
>
> Gtx,
>
> --
> Konrad M.Kokoszkiewicz
> |mail: draco@mi.com.pl                  | Atari Falcon030/TT030/65XE |
> |http://www.orient.uw.edu.pl/~conradus/ | ** FreeMiNT development ** |
>
> ** Ea natura multitudinis est,
> ** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
> *************************************************************
> ** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
> ** albo bezczelnie sie panoszy.
>
>