• Please review our updated Terms and Rules here

Sound Card / Serial Port Conflict

brassicGamer

Experienced Member
Joined
Aug 18, 2015
Messages
52
Location
UK
Hello folks.

I've done as much troubleshooting on this problem as I possibly could before coming here, so hopefully we can find a solution to this particularly odd issue. The system in question used to work perfectly and now there is a specific problem: the mouse does not track when an ISA sound card is installed. Specifically, I load a mouse driver on COM1 and it recognises it. I go into any program that uses the mouse (EDIT, MSD, Windows 3.11) and the mouse cursor is static. When I remove the sound card, the mouse works perfectly. The only thing that has changed inbetween it working and not working is that I have been benchmarking various CPUs but, aside from that, the system has been restored to the original state it was in before this (in terms of jumpers, CPU, etc.)

I have tried an AdLib, SB16, GUS, ESS - all do the same thing. My Voyetra MIDI card doesn't affect it, however, nor do SCSI cards, controller cards, game card, NICs. A different graphics card makes no difference and it also doesn't matter whether I use a serial port built into an I/O controller, or a standalone card. It almost seems it could be related to any card using an audio DAC, because an ISA modem had the same effect. I have tried nearly every combination I can think of and the same problem occurs each time. The only thing I haven't changed is the PSU and the motherboard / RAM. It is an EISA board, so I can't use the Intel PnP tools to track down a possible conflict. Using the EISA config tool allows me to load config files for the ISA cards but this also makes no difference - they are all hard-configured or configured in software at startup anyway.

I only have one serial port enabled, at IRQ4 with the default port of 0x3F8. The SB16 is non-pnp and is configured for IRQ5, while the GUS is IRQ7 and it doesn't matter which card is installed. I even tried a different CPU and tweaked the cache settings out of desperation, even though this makes no logical sense in relation to the issue. Someone suggested it might be linked to the -12V rail, but I have taken readings and it's stable. Thanks in advance for any suggestions - hopefully I haven't overlooked anything obvious.

Edit: new symptom. Noticed that when I use an ISA I/O card and install a sound card, the hard drive controller is not recognised also. If I disable the serial port on the card the same thing happens. When I move the slot the sound card is installed in, however, the hdd starts working again! The controller on my VLB card is unaffected and so is another ISA card I tried. So that just got weirder.
 
Last edited:
Is it possible to boot from a floppy created by another system and to start up your mouse driver and EDIT? If it is a corrupted OS, this is a way to find out.
 
The fact it is an EISA board is interestinfg as Each EISA device needs a seperate setup driver disk like the IBM PS/2 systems. I'd try a straight ISA mobo out and see if the error still occures.
 
Is it possible to boot from a floppy created by another system and to start up your mouse driver and EDIT? If it is a corrupted OS, this is a way to find out.
'Corrupted OS'? This is almost certainly a hardware problem - I thought that was obvious from what I wrote. I didn't include that I also booted from a different hard drive with a different OS installation
The fact it is an EISA board is interestinfg as Each EISA device needs a seperate setup driver disk like the IBM PS/2 systems. I'd try a straight ISA mobo out and see if the error still occures.
I can say with almost 100% certainty that it would fix the problem considering that the motherboard is the only common component at this point. But it also worked perfectly 6 months ago. I don't know at what point it stopped working because literally all the programs I've been using are DOS and keyboard-based. I don't have another working 486 board at the moment so I can't try this out. I can't see how it helps to troubleshoot the specific problem here.
 
There's DOS utilities that list what resources are in use, such as msd.exe that (I think) came with DOS. It lists the assigned I/O, IRQ and DMA for each card. See what it says.
 
There's DOS utilities that list what resources are in use, such as msd.exe that (I think) came with DOS. It lists the assigned I/O, IRQ and DMA for each card. See what it says.
Well, yeah I've done all that and that's why I've got the problem - there are no conflicts that I can detect because every device is accounted for. That's why I'm looking for some help that goes beyond the usual troubleshooting steps.
 
You could have a bus conflict, for example caused by some decoder chip going bad and randomly (or less randomly) activating some other chip. I also had seriously weird behaviour on a 386/486-ish board which turned out to be a broken crystal. The oscillator circuitry produced ISA frequencies all over the place, causing the clock to run erratically and benchmark results to fluctuate - but the system did (kinda) run.

edit: Another example: I noticed that my OTI-067 VGA card feels responsible for the UMB area at 0xD000 and beyond, every second byte of it. Never caused problems until I tried adding the XTIDE BIOS (to the NIC), because it simply did not load. The same card also broke EMS later for the same reason. And the reason I wanted to use the XTIDE BIOS was silent(!!!) data corruption when using some (not all) CF cards. Both problems took a long time to debug.
 
Last edited:
You could have a bus conflict, for example caused by some decoder chip going bad and randomly (or less randomly) activating some other chip. I also had seriously weird behaviour on a 386/486-ish board which turned out to be a broken crystal. The oscillator circuitry produced ISA frequencies all over the place, causing the clock to run erratically and benchmark results to fluctuate - but the system did (kinda) run.

edit: Another example: I noticed that my OTI-067 VGA card feels responsible for the UMB area at 0xD000 and beyond, every second byte of it. Never caused problems until I tried adding the XTIDE BIOS (to the NIC), because it simply did not load. The same card also broke EMS later for the same reason. And the reason I wanted to use the XTIDE BIOS was silent(!!!) data corruption when using some (not all) CF cards. Both problems took a long time to debug.
It does seem like this is the kind of problem I'm dealing with. It's just weird that it happens with literally every single sound card I own, even the AdLib which is a ridiculously simple design. Actually I just tried that again because it didn't quite make sense and - guess what - it *didn't* with the AdLib this time. It seems like whatever effect the introduction of a sound card is having, it can have a residual effect that stays even after the card is removed and the system is powered off. Thing is, when I power on without any of the cards installed, the mouse works perfectly every time. So it's only when a card is inserted not long after a problem card is inserted. Maddening.
 
Just change the irq setting then then. By jumpers or setup disks if it is a PnP one.


Sound cards usually are set at irq 5.
 
Last edited:
Just change the irq setting then then. By jumpers or setup disks if it is a PnP one.


Sound cards usually are set at irq 5.
When this system was working perfectly, it was setup as follows:

- QDI QD6580 VLB controller (IRQ14)
- Tseng ET4000 W32i
- Voyetra V-4000 (330h, IRQ3)
- Adaptec EISA SCSI interface (IRQ11)
- 3com Etherlink III 3C509B (280h, IRQ10)
- Gravis UltraSound Classic (240h, IRQ7, DMA3)
- Sound Blaster 16 CT1740 (220h, 300h, IRQ5, DMAs 1&5)
- COM1 (IRQ4)

Everything is still configured this way, just that the mouse won't work if a sound card is installed. Doesn't matter which and they both have different IRQs from each other and different IRQs to COM1. It's like a bus issue rather than an IRQ issue.
 
It's just weird that it happens with literally every single sound card I own, even the AdLib which is a ridiculously simple design.
Which means that it is probably not the sound card itself, but something else. You seem to have many cards installed, maybe your bus load is too high; it is possible that a capacitor or some other component is starting to leak current, overloading the bus. Also, a failing PSU producing unstable voltages can also cause all kinds of issues. Note that the serial port uses both 12V rails and supplies the mouse as well.

If you have access to an oscilloscope, look at all power rails and verify the voltage and ripple. Maybe try to replace the PSU temporarily.

If it is a decoding problem, you can also try to change your serial port to COM2 (0x2F8 / IRQ3) and use that instead of COM1 (0x3F8 / IRQ4).

It seems like whatever effect the introduction of a sound card is having, it can have a residual effect that stays even after the card is removed and the system is powered off.
Capacitor charges can last for a few seconds or minutes past power-off.
 
Change it any way.
The reason I didn't think it would make any difference is because the SB is IRQ5 and the GUS is IRQ7 so I have already tested different IRQs. I changed the SB to IRQ2 anyway out of curiosity but it made no difference.
Capacitor charges can last for a few seconds or minutes past power-off.
I had started to feel like this was going to need a scope at some point because the problem is giving me the feeling that it's electrical rather than a configuration issue. I've checked the voltages and they're all perfect, but obviously I have no way of measuring ripple. Also I did mentioned I removed every card I could when troubleshooting this and it hasn't been running for a significant period of time with all of them - most of the time it's just been a controller card and a graphics card, nothing else.

I already tried COM2 but I tried it again anyway and it made no difference, even with the SB at a different IRQ.
 
Do an optical check of the mainboard. Look for battery damage, rust, or capacitor leakage (electrolyic fluid on the surface). If moving cards between ISA slots changes the symptoms, you may have a (partial) short circuit somewhere. Also check the connectors.

Remove everything from the board except for the serial port and a single sound card (maybe a floppy controller to boot from). Do you still have problems?
 
If it were me I would be looking to see exactly what goes wrong when the mouse is not working. If you start up a terminal program and move the mouse around, does the expected gibberish data appear? If you unplug the mouse and plug in something else, eg. a null-modem cable or loopback connection, does the serial port seem like it is working at all? Data being transmitted? Received? IRQs happening?

I've never played with EISA before but I believe the connector has additional contacts at a lower depth? Is it possible that you're inserting an ISA card that goes 'too deep' and causes a short that way?
 
Do an optical check of the mainboard. Look for battery damage, rust, or capacitor leakage (electrolyic fluid on the surface). If moving cards between ISA slots changes the symptoms, you may have a (partial) short circuit somewhere. Also check the connectors.

Remove everything from the board except for the serial port and a single sound card (maybe a floppy controller to boot from). Do you still have problems?
There's definitely no battery damage - this board was pristine when I got it (and worked perfectly, remember), plus it uses a RAMified Dallas RTC with coin cell mod. I think it has got to the point where I should remove the board. Who knows - perhaps a screw or some metallic detritus is causing a short on the board somewhere? Stranger things have happened.

I did also remove everything except the floppy controller, a separate serial card and graphics card, and booted from a Norton Ghost boot disk. That uses the Microsoft mouse driver and, interestingly, it doesn't even detect the mouse (where CuteMouse does) when I installed a sound card. So it's consistent.
 
Well, what do you know. Removed the board. Was hesitant to until now because it's a PITA in this case, but there really wasn't anything left to try. Went over it with a magnifying glass and, what did I find? A sus-looking patch around some vias.

20230517_160755.jpg 20230517_160757.jpg

First thing I did was test conductivity on each side of the vias and it was patchy. Treated the area with some vinegar first, then rinsed and used some isopropanol, then a fine needle to clean out the vias. Tested conductivity again and it was much better. Plugged everything back in, minus sound card, and the mouse worked as normal. Tried it with a sound card and... the mouse still worked! Unbelievable. Must have been a single drop of fluid that fell onto that part of the board at some point (goodness knows what or when), calcified, and had enough conductivity to cause the problem.

Thanks to everyone who offered advice!
 
Back
Top