Ok, I removed the ISA serial card and enabled just the serial port 1 in the BIOS with its IRQ as 4. There is a PCI video card, no other cards are installed. A breakout 9 pin port is connected to the serial port 1 on the m/b (with the stripe on the pin 1 side). I made a loopback cable that connects pin 3 to 4 (and 7 to 8 and 1 to 4 to 6 to 9). I booted from an MS DOS 5 disk I had laying around and for now have just been using Checkit to test.
I asked you to only cross Tx/Rx and check with a terminal program to rely on as few functional pins as possible.
The board in question has two serial ports, do they behave identically?
I answered Y to 'is a loopback cable connected'. It recognised there was a COM 1 but it fails like the image shows. If I answer no to the loopback question then it passes all tests.
Assuming that the cable is correct, it sounds like the UART pretends to be functional, but its external interface is not. Electrical faults tend to hit the line drivers, and assuming that they do not pass the failure on, there is hope that the UART itself still works.
One way to test is to cross Tx/Rx between the southbridge and the line drivers (which carries the signals at TTL level and likely inverted) and check if echo works there. You might need to disconnect the line driver chips first.
If I load ctmouse before checkit, ctmouse does report that it has loaded a mouse to COM 1. And Checkit thinks a mouse is there on COM 1 but it simply doesn't respond at all to the mouse test (no movement, no button presses).
You should use "CTMOUSE /Y" when loading to prevent Mouse Systems mode. The Microsoft mouse protocol can be identified, the Mouse Systems protocol cannot. So if CTMOUSE reports the mouse in "Mouse Systems mode", then it has not found anything in the first place and just hopes for the best. In other words, without the /Y switch, it will always succeed (but not work).
So it must be something hardware related on the m/b, right? It did just stop working one day, so I suppose something randomly failed and as I've changed the GD75232's they can probably be ruled out. I've also de-oxit'd the headers on the m/b and also reflowed the solder on them. Traces are tiny and go under stuff so it's hard to inspect them properly.
You only have a small number of variables here: The southbridge chip with two ports, some traces, and two line drivers. It should be relatively easy to see if the southbridge outputs work at all. If they do, you can contrapt anything to fix the ports eventually; otherwise you are out of luck. Since you have two ports on the same chip, the failure could affect one or both equally.
