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

[Konrad Kokoszkiewicz <draco@mi.com.pl>]

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

The point is that this lower reliability is not sufficient. And OK, I
believe that Milan has 100% reliable disk change detection, and Falcon
perhaps would have, if no bugs in TOS were made. The point is what
to fix that on other machines also.

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

Yes, perhaps it is not good considering speed, but so far I haven't heard 
about any other proposition (for ST and TT TOS).

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

OK, so sector 0 plus FAT. But to calculate this reliably you have to do a
seek to track zero as well.

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

What if it does not exist? Or perhaps TT has that circuit also, but
broken?

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

Yes, I realize that and I think I personally could pay that price.

The *efficiency* here means, that the floppy could work a bit slower
but I wouldn't waste time to convince the system that I swapped disks.
So in general the whole operation would go faster (esp. if you're copying
large amount of data via floppies - e.g. the KGMD, 13 or 14 HD disks :-)).

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

Ok, that was only a concept derived from the fact that I've NEVER had
problems with disk swapping on 8-bit system (65XE plus SpartaDOS 4) and
I know how it works there, though the SpartaDOS DOES cache some filesystem
information.

Anyways, what do you think, how to solve that on ST/TT another way?

BTW. if you're involved in Milan OS development, you could perhaps tell
us what is going about Milan MiNT. If you guys develop yet another own
version of MiNT, that may mean a severe desync between FreeMiNT and
Milan MiNT. Not good IMHO.

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