mkarcher wrote on 2021-05-29, 21:01:

Theodinator wrote on 2021-05-25, 16:55:

I'm still trying to figure out what causes the screen corruption during reading from a floppy drive. To me it seems as if the IO controller is writing to the video RAM (if that's even possible..)

Data from the floppy is transferred to main memory using DMA. The mainboard (the DMA controller) asks the floppy controller to put a byte onto the bus by asserting DACK2 on the ISA bus, and puts the address where the data from the floppy drive should go to to the bus at the same time, and it asserts the MEMW# line to tell any ISA card that might contain the destination memory to pick up the byte from the floppy controller and write it to its own memory. If you read a floppy disk normally, the address on the ISA bus during floppy reads should not be the address of the video RAM, but it seems your VGA card still responds to that cycle.

This might be an incompatibility between the mainboard and the VGA card regarding ISA bus timing. You might want to check your BIOS setup, whether you have some "fast DMA" settings like "ISA Type-F DMA" enabled, or you use DMACLK=ISACLK instead of DMACLK=ISACLK/2, i.e. you run the DMA controller at 8MHz instead of 4MHz (which is the usual frequency it runs at, for compatibilty).

Since it's also possible to get rid of the dma and use programmed i/o instead (e.g., linux floppy driver has a nodma option) I wonder if there is some driver out there that can be stuck in config.sys and trap int 13h and interface with the controller that way, to make sure this is the issue.

Or, the OP could boot into Linux from floppies and try out that option even.

Thanks for your insights! I don't recall there being DMA related settings in the BIOS..
I figured the easiest thing to try first was to try another I/O controller and/or another VGA card. And last week I came across a 16 bit ISA I/O controller through a local market place for only €5.

This is the controller that was in the system when I got it:

And this is the 'new' one:

Googling the part number did not result in finding any manuals but I've found the card on stason.org: https://stason.org/TULARC/pc/hard-disk-floppy … ves-PM-520.html
It looks period correct to me and it has the exact same ports and functions so I've tried it out and it totally solved the problem! No more screen corruption during floppy reads.

Another thing I've noticed is that Wolf3d used to have some garbled audio (like opening doors that sound distorted), this also seems to be resolved by changing the I/O controller! Or it's an intermittent thing and a total coincidence, not sure.

Theodinator wrote on 2021-07-01, 21:24:

No more screen corruption during floppy reads.

Theodinator wrote on 2021-07-01, 21:24:

Another thing I've noticed is that Wolf3d used to have some garbled audio (like opening doors that sound distorted), this also seems to be resolved by changing the I/O controller! Or it's an intermittent thing and a total coincidence, not sure.

That is most likely no coincidence. Both the audio in Wolf3D (assuming you use soundblaster mode) and floppy access use DMA, and there seems to be some problem on your board with DMA and video access. Maybe the Wolf3D problem is the "screen corruption" problem in reverse: While floppy reads unintentionally end up in video RAM instead of system RAM, Wolf3D might unintentionally play data from video RAM instead of system memory.

If both of these problems are gone with the new I/O card, I presume that the old I/O card was bad, and disturbed some ISA control signals even if it was not accessed at all.