What sound card are you using ?

Tried ES1868 (with esscfg for pnp config) and Aztech AZT2320 (unisound 0.77 for pnp config).
For video tried Cirrus Logic CL-GD5420 and Trident 9000c.

All build permutations with these cards produced identically looking issue. Trying to reorder the cards in the ISA slots also had no apparent effect on the issue.

It sounds like you eliminated a specific expansion card as causing the issue. Now you have to check whether the motherboard or power supply is the issue. Besides checking things like the bypass caps, I'd first check the power supply. You can have a borderline power supply that runs a board with just video, but when you insert an audio card, or start pushing it with a game with audio & video, you start having issues. So is your power supply ok?

Same PSU (300W ATX) is ok with two another PC's - Harris 286@20MHz (running video+audio) and Pentium MMX @166 MHz (also video+audio+cdrom). This is where I know the cards are ok.
In all cases CF is used instead of HDD, so the load is even less than it would be normally.

But yeah, maybe it's worth probing the ripple on all rails in few spots.

I've bought another 386 motherboard (M326 V5.5), physically looking very similar to the one in question. It's built on PC Chips chipset, a SARC clone of the same UMC chipset. It did behave identically, same garbage on Pinball Fantasies launch, garbling sound and pixels on screen.

Also at the time I was testing the Trident TVGA8900D to see if it's really that fast as people say (oh yes, it is), and compare it with other Trident's/Cirruses. Different cards sometimes required different mutual locations on ISA bus to run smoothly, a typical issue would be the video not being detected, or hdd controller failure.

Anyway, carried away with running benchmarks on multiple ISA video cards I came along with Cirrus Logic CL-GD5422 which I never put in this 386 before. The Speedsys 4.70 reported video throughput of 23567 KB/s, which is clearly impossible with ISA bus. While poking around about this phenomenon, I launched the Pinball Fantasies - and it was all perfect.

So now I'm inclined to think it's not the broken chips, but some peculiarities of the chipset behavior with regard to the hardware that maybe isn't exactly period-correct - like PnP ES1868 or ATZ2320. And maybe both parties were violating some timing specs. The issue could be further exaggerated by the fast CPU (AMD Am386DX-40). Having faster video card could just resolve certain edge cases.

Another weird issue I was observing - while Pinball Fantasies menu was launched with any but CL-GD5422, the POST indicator was continuously updated with some codes, suggesting something is actively using BIOS services. This was not happening with CL-GD5422.

Try running your games with setting high and low dma channels both to channel 1 (so both use low dma) and/or change BLASTER variable if needed.

vstrakh wrote on 2023-03-08, 15:27:

Another weird issue I was observing - while Pinball Fantasies menu was launched with any but CL-GD5422, the POST indicator was continuously updated with some codes, suggesting something is actively using BIOS services. This was not happening with CL-GD5422.

POST card is just displaying whatever any software writes to port 80h
garbage on screen and writes to POST suggest broken address lines, like maybe cracked solder joints

Zerthimon wrote on 2023-03-08, 20:55:

Try running your games with setting high and low dma channels both to channel 1 (so both use low dma) and/or change BLASTER variable if needed.

It's not about game settings or blaster configration. It's about having the same setup - same disk/cards - everything except the motherboard, working ok everywhere (286/486/Pentium) except these two 386 motherboards. And having the issues on these 386 with any combination of other cards, except it works ok with CL-GD5422 for some reason.

rasz_pl wrote on 2023-03-08, 22:49:

POST card is just displaying whatever any software writes to port 80h
garbage on screen and writes to POST suggest broken address lines, like maybe cracked solder joints

Two unrelated motherboards, having in common only the base design and using different clones of the same original chipset, failing identically because of possible bad joints?
Anyway, this would affect the behavior much more severely than just show occasional problems between audio and video.
And if it really were the bad joints, it wouldn't be "fixed" by plugging the CL-GD5422. Replace it with any other card and the issue is back. Put the 5422 and everything is back to normal again...

I didn't go as far as probing the bus with the oscilloscope. The signal integrity issues can produce such effects, and the one "magic" video card could just have the "right" impedance of inputs that brings the bus into more stable region.

vstrakh wrote on 2023-03-09, 07:35:

It's not about game settings or blaster configration.

Just try to set the games sound config to use low dma on both channels, and you'll see, that they run without hanging. I have a few similar boards (m321) with the same SARC chipset and they all have the problem with high dma. It's the chipset what's causing this.

Zerthimon wrote on 2023-03-09, 14:04:

Just try to set the games sound config to use low dma on both channels, and you'll see, that they run without hanging.

I tried that in the first place, hoping maybe it was related to damaged DMA traces on the board.
Tried DMA 1 and 3 for main and secondary channels and swapped (i.e. "esscfg /D:1 /E:3" or "esscfg /D:3 /E:1"), and the Pinball is running it as SBPro 2.0 - only 8-bit sound, so only low DMAs. And the game never hung up, it worked, just corrupting the data in video memory and the played audio.
The issue is with the ISA bus itself. DMA reads could not affect the video memory. Unless the control signals on the bus are total mess, in which case the video card could treat the data flying by as something to be written in video memory. It all "fixed" itself only with one particular specimen from a dozen of other ISA video cards I have.

Have you tried talking out cache, tag chip, and fpu if you have those? Its interesting, if your issue is unrelated to the dma issue I'm having with all of my m321 boards.

vstrakh wrote on 2023-03-09, 07:40:

I didn't go as far as probing the bus with the oscilloscope. The signal integrity issues can produce such effects, and the one "magic" video card could just have the "right" impedance of inputs that brings the bus into more stable region.

something like floating IOW signal and only GD5422 card has pullups? or maybe GD5422 dgaf about /IOW signal and just decodes all addresses
ISA pin B13 is /IOW, should have 10Kohm pullup and probably go thru 245 buffer

rasz_pl wrote on 2023-03-09, 16:50:

something like floating IOW signal and only GD5422 card has pullups? or maybe GD5422 dgaf about /IOW signal and just decodes all addresses

It's not that it's all failing always with other cards. It's all working separately, and you wouldn't even know something is bad until you hit a certain access scenario in some games. The #IOW is unlikely to be totally broken.

#IOW has onboard 10K pullup to 5v, there are resistor arrays near the ISA connector farthest from the chipset.
I've tracked it to 10 ohm resistor near the 245 buffer, but the trace on the other side of the resistor goes under the IC package. It's not measured on any pin on this buffer though. There are vias under the chip, and I've managed to track that trace directly to the pin on the 82c3491 chip.

Probing it with the oscilloscope. Very inconvenient without having something to grab multiple individual lines simultaneously, so no multichannel waveforms at the moment.

The ALE signal (ISA pin B28) does not look particularly healthy. Severe undershoots, and spikes are too short to carry any useful meaning (unless it's only about falling edges). It looks more or less identical on both motherboards. It shouldn't be just a crosstalk on floating lines, surrounding pins are either quiet (TC, 5v, etc) or the address lines, and the observed patterns on the address lines does not look anything close to ALE to suspect a crosstalk.

Couldn't catch the exact moments when DMA transactions start up to see the ALE behavior (expected to be forced high), I need to find a way to clip multiple probes first.

On a Biotech MB-1333 the ALE is the output of the 74F32 OR gate, combining signals from 82C3491 and 82c3493 chips. I guess it's time to desolder that IC and check it...

On the other hand, the 286 on TD60C motherboard produces very much the same ALE, so this shape alone is not the problem.

So, I did suspect the 74F32 IC that forms the ALE signal. I wasn't quite sure how ALE supposed to look, but I know for sure how the OR gate should function.
I've made few springy posts to put the scope probes into, and soldered those to the 74F32 pads - two inputs, output, and a VCC to watch if there are dips in IC power supply.

Looking at ALE now it's clear the output is really bad.

But before going and desoldering the IC I wanted to know if it's really dead, or just loaded too much and is too old or degraded to handle that load.
So I started to pull out the cards, checking the signal after each removal.
It so happened that the last removed card was the multi i/o card (not touching the VGA yet) when the signal became correct. Ok, we have a suspect, same card was used in other failed 386 test.
The card is disconnected from everything, and gets thoroughly inspected. All seems ok, measuring ALE pad on the card against ground shows nothing at all, no connectivity, and some tiny capacitance, so it couldn't load it.

The card goes back in the motherboard with no devices attached, I start PC - and ALE is perfect.

Ok, plugging back all the devices - Gotek floppy emulator, CF card with IDE adapter. The ALE is dead again.
The ALE is present on the IDE interface, so unplugging the CF card in case it's somehow behaves bad - ALE is still bad. Unplugging the whole CF adapter - now it's alive again.

Hmm... You know these cheap chinese adapters.

They were always working ok for me, never had any issues except in this case of 386 boards.
Now let's look closer at the PCB, what do we have?

Holy crap, "The Chinesium Strikes Back".
See the pin 28 where ALE is delivered with IDE cable. They've grounded it!
Cutting the copper around that pin, plugging stuff back - everything works as it should have been.
Now I have to service all the other PCs where I have the same adapter and where I never had any issues.
The 286 ALE waveform I've sampled earlier - it's also bad because of the same adapter being used. How it was working, all those earlier builds with different CPU/mobo - no idea...
Maybe other multi I/O cards did buffer the ALE before exposing it to IDE, and it's just this unlucky one that passed through the ALE without buffering.

Bottom line - it was never the motherboard's fault in the first place. Cheap chinese stuff must be treated as unsafe until proven to be ok.

vstrakh wrote on 2023-03-13, 18:24:

Bottom line - it was never the motherboard's fault in the first place. Cheap chinese stuff must be treated as unsafe until proven to be ok.

Yeah, recently I bought another CF adapter, this time one of these "vertical" ones to plug directly into mobos with IDE headers and this one too has CSEL pin permanently tied to GND. Well at least it's not going to be connected to any older ISA IDE controllers...