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

[Michael Schwingen <rincewind@a-tuin.dascon.de>]

On Fri, May 22, 1998 at 12:28:54PM +0200, Konrad Kokoszkiewicz wrote:
> perhaps would have, if no bugs in TOS were made. The point is what
> to fix that on other machines also.

Right.

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

OK - I talked about this with Uwe and we came up with a possible solution.

The problem really is that the BIOS won't see a change in the write protect
line when write protected disks are swapped. A possible solution would be to
install some kind of 'floppy-idle-loop' which does a 'read ID' (or whatever
the command is called on the 1772) whenever there is no other command
pending for the 1772 (or for the ST-DMA). When you do not get a sector ID
for 1 disk rotation, you either have an unformatted track or the disk was
removed, so you can set the 'maybe changed' flag.

After a timeout of some seconds, the motor is stopped as usual. When turning
it back on, we have to set the 'mayba changed' flag, too.

This should work, but I guess it might be a bit too much programming effort
for the old machines. Maybe some mechanism by which disks are mounted (or by
which the user simply tells the system 'I did change disks') might be the
easier solution.


When the 'maybe changed'-flag is set on a disk access, we have to check not
only sector 0 but also at least the FAT - because there is one common case:
you take a disk out of the drive, put it in another computer and copy files
on, and put it back into the drive. This must be handled liek a changed
disk, otherwise you will overwrite these newly copied files when copying
anything onto this disk.

To do this 100% perfect, even the FAT might not be enough: think about
renaming a file in a subdirectory while the disk is in the other computer.
Sector 0 and FAT will not be changed by this. However, I think this risk
might be OK.

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

I would rather press ESC after switching disks and have decent speed
instead (you have to press ESC anyway - neither the desktop nor Gemini read
in a changed disk automatically, so the only difference is whether to do a
normal re-read or a forced diskchange).

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

If you want it *really* fast, you could connect a button to the write
protect signal to manually cause the BIOS to recognize the disk change. I
wonder if it might be possible to do this automatically when a disk is
changed with some small logic circuit ... 

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

Agreed. I don't do that part - but Rainer told me the needed changes are
minimal, so I guess you will be getting diffs as soon as he is finished.

I definitely want the 'normal' mint binary to run on Milan without needing
additional patches.

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