Can't use floppy disks with Windows 3.1/95

[Kreeblah]

Whenever I try to access a floppy drive in Windows 95 or 3.1, the entire OS locks up. A similar thing happens in DOS after I've run and quit Windows 3.1, so the only way I seem to be able to use floppy disks with the core is to run DOS and do what I need to with floppies before loading Windows.

However, this is very cumbersome, especially since some applications assume that they're being installed from a floppy disk even if the install files are already on the hard drive, and as soon as they access A: to read the files they expect to be there, the system freezes.

In case it's relevant, I'm using PC DOS 2000 and PC DOS 7.1 with Windows 3.1, and the original Windows 95 release (not OSR2 or later). Is there a better workaround here than booting into DOS, copying contents of a disk to the hard drive, and then trying to use the files from Windows?

[sorgelig]

i remember floppy worked some time ago. need to investigate it

[dot-bob]

I just tried a floppy disk image that had worked in the past with windows 95 without issue and now I get the same OS lock up. I can access the disk and files when booting directly in dos but when windows 95 is running as soon as it accesses the drive either from file explorer or using the command prompt the OS hangs.

[Kreeblah]

I'm glad it's not just me on this.

I find the Windows 3.1 scenario to be really interesting for this one. If I run Windows 3.1, then even after I quit Windows entirely, I run into the same lockup issue when accessing the floppy drive in pure DOS. I need to reboot (and not load Windows) in order to be able to use the floppy drive.

[friendly-joe]

I am having a very similar issue with the latest core. However, for me the problem happens like this (I've experimented only with Win 3.1) :

1. Fresh install of MS-DOS 6.22: Can access A:
2. Fresh install of Windows 3.1, after reboot: Can access A:
3. Reboot into DOS: Can access A:
4. Launch into Windows 3.1: STILL can access A:
5. Install Sound blaster 2.0 drivers (incl. Win 3.1 drivers) by launching its DOS installer from A:, within Windows 3.1
6. After restart and booted into Win 3.1, sound (PCM/FM) works, HOWEVER A: magically becomes inaccessible and freezes the core.

I will update if I found anything more.

Thank you.

[sorgelig]

@friendly-joe thanks for useful info!

[sorgelig]

Win95 in safe mode can access A: but i still don't know what is causing the issue.. May be DMA.

[friendly-joe]

Dear Mr. Sorgelig,

Thank you for the valuable feedback!

I agree with you since even under Win 3.1, right after Sound Blaster 2.0 drivers have been installed, this happens.

Someone suggested to use Adrib drivers which are built-in to Windows 3.1; I will try but to be honest if this really a DMA's (DMA controller implemented in the FPGA) issue, same thing would happen since any sound card uses DMA.

For me, A: is always accessible under MS-DOS 6.22 even after the Sound drivers are installed and resident. But only within the Windows the issue happens.

I will tinker more and will let you know later.

Thank you!

On Sat, 28 Mar 2020, 01:44 sorgelig, notifications@github.com wrote:

Win95 in safe mode can access A: but i still don't know what is causing the issue.. May be DMA.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/ao486_MiSTer/issues/11#issuecomment-605207781, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO2N45DI5FGADEX454ITCTLRJTXZXANCNFSM4KWH2FIA .

[sorgelig]

Issue is also present in DOS after using the game with SB2.0 sound (not adlib!). For example after Doom, A: doesn't work.

[friendly-joe]

Dear Mr. Sorg,

Thank you for valuable info again!

Hrm so it more and more looks like Resource handling, or DMA handling issue which is present and may be related to the SB 2.0 portion in the core...

I am just curious; does this issue happen with original ao486 (before your improvement...) which uses lower 30Mhz clock?

Also, is there anything that I can specially test for you as an user?

Thank you.

On Mon, 30 Mar 2020, 02:14 sorgelig, notifications@github.com wrote:

Issue is also present in DOS after using the game with SB2.0 sound (not adlib!). For example after Doom, A: doesn't work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/ao486_MiSTer/issues/11#issuecomment-605685144, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO2N45ENPQCYSEOB2BAI3WLRJ6M2BANCNFSM4KWH2FIA .

[sorgelig]

I am just curious; does this issue happen with original ao486 (before your improvement...) which uses lower 30Mhz clock?

Original ao486 code left in 2 years ago and it's impossible to test on MiSTer without porting. So i can't answer how it was there.

Also, is there anything that I can specially test for you as an user?

You can help if you can debug the FDD access before and after the problem to see where exactly problem happens. This will help me to look specific code in HDL.

[friendly-joe]

Dear Mr. Sort,

Again, thank you for your feedback.

You can help if you can debug the FDD access before > and after the problem to see where exactly problem happens. This will help me to look specific code in HDL.

---> Ok, I try to find a way... May be combining with Floppy sector scanner/counter, I could find something. (Timing etc)

Besides, I think there is an characteristic/uniqueness for when the core freezes after this issue kicked in; at least on Windows 3.1 w/SB 2.0, right after clicked A:, the core keeps working just briefly (1-2 sec) but shows massive performance slowdown (example: mouse curser becomes really really laggy then completely freezes, as if the core is in the loop before it stops)

I hope this might be of any idea to you.

Thank you.

On Tue, Mar 31, 2020, 6:30 PM sorgelig notifications@github.com wrote:

I am just curious; does this issue happen with original ao486 (before your improvement...) which uses lower 30Mhz clock?

Original ao486 code left in 2 years ago and it's impossible to test on MiSTer without porting. So i can't answer how it was there.

Also, is there anything that I can specially test for you as an user?

You can help if you can debug the FDD access before and after the problem to see where exactly problem happens. This will help me to look specific code in HDL.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/ao486_MiSTer/issues/11#issuecomment-606570461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO2N45FX4EJV6HIVREQL54TRKHH5PANCNFSM4KWH2FIA .

[Kreeblah]

This seems to be resolved in the new core release today.

[sorgelig]

Under windows 95/98, in device manager simply delete the floppy disk driver and reboot. System will still provide access to FDD in compatibility mode (through BIOS).

[friendly-joe]

Thank you for your reply, I will definitely do!

On Sun, 16 Aug 2020, 03:35 Alexey Melnikov, notifications@github.com wrote:

Under windows 95/98, in device manager simply delete the floppy disk driver and reboot. System will still provide access to FDD in compatibility mode (through BIOS).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MiSTer-devel/ao486_MiSTer/issues/11#issuecomment-674444682, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO2N45GUGNKWMWRCH67UYNDSA3WRVANCNFSM4KWH2FIA .

[kblood]

This is exactly what happens for me when I try to use Daemon Tools for CD drive emulation. If I boot Windows 95 with a CD image mounted and I try to access this computer, it locks up the system completely. But for some reason it does work if I unmount image after booting, or before rebooting and then mount it again once the system has rebooted.

[sorgelig]

I'm using daemon tools in Win98. No problems so far.