Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disk change issues in DOS 6.22 with 3.42 on 3 devices #875

Open
boohyaka opened this issue Feb 26, 2024 · 8 comments
Open

Disk change issues in DOS 6.22 with 3.42 on 3 devices #875

boohyaka opened this issue Feb 26, 2024 · 8 comments

Comments

@boohyaka
Copy link

Hi keirf,

I'm scratching my head. I have three different Goteks (1 SFRKC30AT3 and 2 STM32F105) all flashed to 3.42 in three different DOS 6.22 IBM PCs, that I have modded with rotary+oled+speaker, I have S1 and JC jumped on every one of them, and all 3 do not properly detect disk change. Am I missing something stupid?

I tried to add a ff.cfg file with:

interface=ibmpc
chgrst=delay-3

but it doesn't change anything. I've resetted default config on boot, even reflashed bootloader+fw 3.42 on one just to test it, to no avail.

If I select a first image then dir, it's fine, then if I change the image, wait a bit then dir again, I will keep getting the first image content off cache. Pressing CTRL-C then dir works, I get the new content immediately, but this is not a very good solution as I can't do that when installing multi-floppy games or apps.

Any idea or things to try? Thanks a ton in advance.

@boohyaka
Copy link
Author

WhatsApp Image 2024-02-26 at 19 22 15

pic if that helps.

@keirf
Copy link
Owner

keirf commented Feb 26, 2024

Remove FF.CFG and reset cached config. You shouldn't need an FF.CFG to get this working, and meanwhile it can only confuse things.

It would be interesting to see if you get changed behaviour if you jumper S1 only (remove JC): Then I would expect a "Not ready reading drive A" error.

Do you have a real drive and disks you can test on one of these machines with the same ribbon cable?

On the STM32 based Goteks you could try a much older firmware version and see if that helps. For example v3.20.

@boohyaka
Copy link
Author

boohyaka commented Feb 26, 2024

Thanks for the answer.

  • Removed FF.CFG and reset cached config: same behaviour
  • Removed the JC jumper and left S1: same behaviour. Boots fine, no error at all. It's like JC does nothing.
  • Normal floppy drive: works fine
  • v3.20 on old devices: no difference

But in the meantime I found a working and viable workaround.

http://www.manmrk.net/tutorials/DOS/help/drivparm.htm

If /C is omitted, the drive is configured as not supporting disk-change signalling. So I added:

DRIVPARM=/d:0 /f:7

to my config.sys. (d:0 = drive a:, f:7 = 1.44MB)

And...everything works correctly. Tried on all 3 machines, and it's fine on all three. So at least I have a software workaround.

Some more info if that's useful:

  • All drives are set as A:, after the twist
  • Comp1: 386 DX-40, ISA IO card
  • Comp2: 486 DX2-66, VLB IO card
  • Comp3: Pentium 133, onboard IDE

If you're interested in the issue I'll happily run any test you require if it can help!

Cheers

@keirf
Copy link
Owner

keirf commented Feb 26, 2024

Yes this is all very weird. Without JC pin 34 is READY instead of DSKCHG. This line should then be LOW when an image is mounted, which should be interpreted by the host as disk ejected, and hence "Drive not ready" is expected. Thus I would assume pin 34 is misbehaving on all these Goteks for some reason.

Are you certain the cached config is cleared (button(s) pressed until display changes)?

Could these Goteks have all been damaged, say by connecting to the same untested host at some time?

Can you put a scope or logic analyser on pin 34?

EDIT: Even a voltmeter would do, testing with an image mounted versus ejected.

@boohyaka
Copy link
Author

Hello keirf, my apologies for the delay as I've had other real-life emergencies...after your message I did test with my multimeter and compared the behavior between a real floppy drive and my AT-based Gotek. With the Gotek, pin 34 would briefly go low during POST, then always stay high and changing floppies made no difference. With the real floppy, after exchanging floppy, pin 34 would briefly go low before going back up high. Then I left it at that for two weeks...

Today I decided to get back to it, and restarted from scratch in the sense that I prepared a new USB stick, and cleared all cache configs again as you suggested. For a reason I can't explain because I have tested it several times before, this cleared the issue on the two "old" Goteks that started behaving normally with floppy change detection! The most recent AT-based one still has the issue, though. But at least I can live with it with the DRIVPARM setting I mentioned earlier.

If you think there may be more to investigate on the AT drive, please let me know and I'll try to do it without a 2 weeks delay :) and if not, feel free to close. At least this issue may serve as information for other people with similar problems, and let them know about the DRIVPARM DOS setting to work around it.

@keirf
Copy link
Owner

keirf commented Mar 12, 2024

Thanks for the update. That is still pretty weird with the AT drive. If you have a USB-A to USB-A cable you could try a complete Mass Erase and reprogram of that drive, using the Firmware Programming guide (https://github.com/keirf/flashfloppy/wiki/Firmware-Programming)

Then you could jumper exactly as your older Goteks, and use exactly the same stick, and see how that goes. You could also re-check with multimeter.

@keirf
Copy link
Owner

keirf commented Mar 12, 2024

PS in the firmware programming guide you can skip the "disable protection" steps. And at the step of ticking "Verify after download" you would also want to change the Erase option to "Mass erase".

@boohyaka
Copy link
Author

oh btw - jumper JC made absolutely no difference on the pin 34 behavior on the AT drive.

OK thanks for the suggestion, I will try to reprogram it fully as instructed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants