Hi djfitzgerald,
I read your descriptions and it sounds like a problem with your serial mouse which I have experienced with my prototype designs while testing them.
Previously I built several XT revisions and I came across the same problem you have been experiencing several times.
Lately I am working on ATs and I tested a 486 recently, it was even more weird with that ALI mainboard. When I tested with a 486SX, I got the serial mouse detected and working, however when I changed the CPU to a 486DX2-66, suddenly I could not move the mouse anymore, same as you.
I am reasonably sure that your problem is the same phenomenon that I have been seeing in certain situations.
What I have found as one possible cause is that UART chips are extremely sensitive on their RESET input pin.
Unfortunately, they made this pin in positive active logic, which means that a "0" level means that there is no reset happening, and a certain positive voltage will register as a "1" and will reset the chip. This type of positive logic control signal is sensitive to signal noise caused by reflections and crosstalk on the PCB.
What you can do is two solutions for this first cause, one solution is to put a 2,2nF capacitor on the ISA slot "RESETDRV" pin to GND.
This will greatly reduce the noise on the RESET line.
Another solution would be to find the RESET pin on your UART card, and simply disconnect it from the ISA slot and connect the pin to GND on the card.
If it's a separate UART chip you could raise the RESET pin and tie it to GND as well.
So that covers the most likely cause of this problem I have seen. UART chips are extremely sensitive.
I have another thing you can test out, just out of interest and for your own reference.
Just start the PC normally as you would and load the serial mouse driver with a mouse connected. Without fixing anything yet.
Then start the program MSD.EXE, the diagnostic program which comes with DOS.
Quite possibly this program will be controllable by serial mouse, while other DOS programs are not.
Very strange stuff I have seen.
And you know, in the old days when I was actually using DOS PCs, I have never seen this problem happening!
Another thing you can test is to put the serial card closer to the CPU, and put some other card on the end of the ISA slots, furthest away from the CPU.
That card may act as a "terminator" and reduce crosstalk and reflections on the RESETDRV line. Which may make your serial mouse suddenly function fine.
You can experiment with different cards as a "terminator" in that outer position.
I remember asking questions about this problem as well but no one responded to them so I thought it is "unique", but later I found it is not that unique.
The problem happened with various serial port cards and the mouse. The mouse was detected fine but didn't do anything, until I discovered the MSD.EXE fluke.
Possibly that software is doing some kind of reset or initialization which is solving the problem. But after leaving MSD.EXE the problem still exists in all other software I tested, including windows 3.0.
So the other occurrence I have seen was on a 486 mainboard when changing to a DX2-66.
I changed the timing and frequencies but no difference.
I believe it could possibly be the chipset not translating 8 to 16 bit or 16 to 32 bit IO properly.
My solution was using a SiS mainboard which didn't experience the problem and this mainboard also supported 8MB SIMMs.
Please remember, if you do anything with your system, it is always at your own risk and responsibility.
I can't know people's soldering, troubleshooting and repair experience, I am merely telling you what I did.
What you decide is purely your own choices, I must add this.
Any repair if it goes wrong could kill the system.
Talking about serial mouse control, I always want to mention LimeProgramming's USB to serial solution which lets you use a modern USB mouse with any PC that supports serial mouse control. That solution raises the mouse control to a comfortable level the same as any modern PC, which is a huge difference to the old serial ball mouse! LimeProgramming(Adam) published his project on GitHub.
I integrated his USB mouse solution on my latest AT mainboard project, where the UART operates directly in TTL level with the RP2040, not needing any RS232 logic level shifters.
If you are not comfortable soldering anything or don't want to risk it, which I understand(!), you can try swapping the cards to see if the termination effect could be achieved.
I hope this info is possibly useful for you!
So it's not an error in the PC persé as you also commented, where a chip or connection is faulty, but more a strange occurrence in the mouse function which is not completely unique. I traced it back to at least a sensitivity on the RESETDRV line which is quite noisy. I measured around 500mV of noise in my situation.
The UART doesn't need RESET to be applied for its normal function, RESET can remain inactive on the chip and it will work fine.
Kind regards,
Rodney
