TOS patch for 1.44MB floppy support ?

[exxos]

http://www.wrsonline.de/pdf/HDKit.pdf

German, can't copy text to translate :( but that only seems to mention pin 19,20,21. It would have to mention pin 14..

[exxos]

The Elco module all I can find really is there was a CPX and ACC for it.

Capture.PNG

[troed]

http://www.wrsonline.de/pdf/HDKit.pdf

German, can't copy text to translate :( but that only seems to mention pin 19,20,21. It would have to mention pin 14..

I can read German well enough. But is that the ELCO kit? It doesn't say ELCO anywhere, but yeah, maybe that's the PSG connections it uses (too).

[exxos]

I can read German well enough. But is that the ELCO kit? It doesn't say ELCO anywhere, but yeah, maybe that's the PSG connections it uses (too).

Not elco no. Was just mentioned in the FCOPY docs about the PSG on the german forum.

I've not found anything on the elco.

[exxos]

I can only think the "simple" way for such a program to work, is if there was a patch in TOS floppy routines on the read fail retry count, in that it could flip the PSG bit then retry.

Still not sure how it behaves if formatting a disk after a disk change ..

So FCOPY seems confused. It switches to HD mode after loading from a 720K floppy. Selecting DD and formatting, FCOPY doesn't not change the PSG register even though its on AUTOMATIC mode :roll: Selecting LOW for BIT 7 does nothing.

TOS doesn't register the floppy change either. On desktop I have open a 720K, then change to a 1.44MB, save desktop, TOS doesn't switch into 1.44 mode.

No idea if the MSTE behaves this way @troed ? I can understand its switching mode when trying to read from a floppy, but not when trying to save to it.. I do not see how it could possibly know if it has a HD or DD disk in the drive ? Same with a unformated floppy, be it DD or HD.. TOS cannot read anything, so it can never know which mode to be in ?!

I'm starting to think this is all just getting to be more trouble than its worth :roll:

[troed]

No idea if the MSTE behaves this way @troed ? I can understand its switching mode when trying to read from a floppy, but not when trying to save to it.. I do not see how it could possibly know if it has a HD or DD disk in the drive ? Same with a unformated floppy, be it DD or HD.. TOS cannot read anything, so it can never know which mode to be in ?!

No the MSTE works fine. Atari's solution is actually pretty slick I think*. Try to seek to the specified track for a command (read/write/verify), if it fails, switch frequency and try again. If it fails in both modes, obviously there's an error with the disk anyway.

For Format I think it's handled by the GEM Desktop always doing Verify - which will perform the above routine.

*) It works on external drives too

[exxos]

Interestingly with the HDCOOKIE installer, I can format DD & HD fine and it switches.

But there must be a bug in the TOS patch as it doesn't detect a disk change properly :roll: One time it did, then next time it seems to corrupt the floppy.

HDCOOKIE.zip

EDIT:

Well that was quite a accomplishment. I cannot even quick format the test floppy on the PC anymore now :shrug:

EDIT2:

So it is repeatable every time.

1) Put a 720K disk in and open it on the desktop
2) Put a 1.44MB disk in and save desktop (without pressing ESC)

Then I just get the error message " data on the disk in drive A: may be damaged" and that floppy becomes totally unusable. Even though it has actually switched into 16Mhz mode.

[exxos]

It is odd because occasionally it does seem to work, but then if I tried a second time it trashes the floppy.

I would surmise that switches to the other density after a timeout. EG its in HD mode, times out after 4 seconds, then switches density to the correct one. But it's to late as GEM flags up a error. It Should not be coming up drive not responding, it should be switching state and retrying.

I would have suspected it would toggle between SD & HD several times before actually giving up. But it does not seem to actually do that. It is rather difficult to follow it all in the code.

EDIT:

For the hell of it, I tried just using the floppy HD wire. Annoyingly, same fault :roll:

There must be a bug in TOS relating to media change not working correctly. Like it needs to refresh the floppy contents at some point before doing any access and basically ignoring media change all together :shrug: Also annoyingly EMUTOS seems to suffer with the same problem :shrug:

EDIT2:

So something else is going on here, I cant save to a 720K in GEM for some reason now :roll:

EDIT3:

FFS! The IRQ wire I had testing the TF536 out had "fallen" onto the external floppy connector :pullhair: :headbang:

I shall start my testing over again now :roll:

[exxos]

So things seem to be behaving a lot better now in GEM :D

FCOPYPRO is acting a bit odd still.

Loading from a 720K disk, I swap to a 1.44MB, click format, it seems to read the disk and switches into 16mhz.

However, when I put a 720K back in, and click format ( after choosing DSDD to format) it does not read the floppy or change back to 8mhz.

If I click "scan disk" then reads and switches to 8mhz mode.

So I am not sure if this "bug" is in FCOPY or TOS at the moment.

[exxos]

GEM test formatting again.

Loaded HDCOOKIE from 720K:

Put in a 1.44MB, formatted HD fine.

Put in 720k, formatted to DD fine.

Put in a 1.44MB, formatted HD fine.

So I would surmise there seems to be a bug in FCOPYPRO :(