BitWrangler wrote on 2023-06-20, 13:46:

So that post, since older mice you had to hold a button to set Mouse Systems mode, makes me think that one of the control lines DSR or DTR or one of those is stuck.

Unlikely. Drivers that auto-detect the mode will use MS mode if the mouse identifies itself as such, otherwise they use mouse systems mode. All it means is that the driver didn't get a response.

Btw, i remembered that i tried the Mr.BIOS available on TRW.
That didn't help.

weedeewee wrote on 2023-06-20, 16:49:

There will be more circles because hardly anyone will read this whole thread. So to recap : […]
Show full quote

pshipkov wrote on 2023-06-20, 16:34:

I know. We went in circles few times, but that's fine. I appreciate all the feedback. This is a puzzling issue for sure.

Speaking of puzzling issues - i know very well what you mean about DMA not functional in DOS, but working fine in Windows.
LuckyStar LS-486E revisions C2 and D are exactly like that.

There will be more circles because hardly anyone will read this whole thread.
So to recap :

The cards works on another mainboard
All voltages are present and accounted for +12,+5,-5,-12
Both floppy & harddrive work, also tested with different video card.
Card fails serial I/O, no matter what settings are used for address & IRQ, yet work ok on another mainboard.

Really? wow thanks, first I hear about it. mine's an ADI F4DXP-UC5D-I , different chipset from the lucky star

Confirming your that conclusions are 100% in line with what i see.
This points to a specific issue with this particular motherboard i have here.
---
About the DMA - yes.
Feipoa has the same problem with his LS rev:D board.

FYI, i wasn't kidding about adding a summary to every reply from now on.

The cards works on another mainboard
All voltages are present and accounted for +12,+5,-5,-12
Both floppy & harddrive work, also tested with different video card and tested with different bios
Card fails serial I/O, no matter what settings are used for address & IRQ, yet works ok on another mainboard.

pinpointing what particular issue is at play here would be nice.

edit: looking at the jumpers on the photo of the cards, the only thing I would change is set serial 2 to com2, though that will likely not make any difference whatsoever.
do you have any idea what JP8(7)&(8) are for ? they're not listed on the th99 page. (st-ad-son) nevermind, they're just listed wrongly.

yes, i will follow your suggestion, it is a good one.

btw, i am uaing the green card for testing.
only com1 is enabled, which is the connector on the back of the assembly.
i had com2 enabled and tested both the soldered connector and connecting mice to the pin header using two different cables for the two serial port standards.
also tried with ctmouse and microsoft drivers.

was kinda looking into reading out the uart registers.
I guess easiest way would be to use debug and read them all manually.
Best setup would be plain dos boot without any drivers whatsoever.
then start debug and type
i 3f8
i 3f9
i 3fa
i 3fb
i 3fc
i 3fd
i 3fe
i 3ff
each i xxx line should return a byte.
Do this on a working computer and the non working one that uses the similar io card (same chip)
I assume the output on both computers should be identical.

Values match between this board and another one (where mouse works), same controller.

3F8: FF
3F9: 00
3FA: 01
3FB: 03
3FC: 00
3FD: 60
3FE: 00
3FF: FF

When I had the problem with the socket7 board, the onboard serial didn't work, though some hardware diagnostics (Norton?) were passing it, and io card with onboard disabled didn't work... for com 1/3 ... com 2/4 were still working. I needed to use the board with mouse, modem and serial sync for a device, so 2 shared ports were a pain in the butt. The internal modem didn't work set to 1/3 with onboard disabled either. BIOS flashes were appearing successful until I gave a switch to verify BIOS against image and then it showed an error, so it was a hardware fault on BIOS chip. Anyway, some long time after, I put another chip in it by hotflash and all the com 1/3 problems disappeared. (Actually can't quite remember if win 95 gave me a clue on this board, remember one time the com port detected as Com(garbage character) not remembering if that was another system or this same board before the BIOS chip swap cured it.)

There are one or two "high speed" serial communication or file transfer programs that skip BIOS and DOS routines and hit hardware directly with their own code, if that kind of thing works, then there's something wrong at system level.

So, various IRQs etc have been tried, but the DTK card will accept a Com4 setting with IRQ 3 for the onboard 9 pin port, so I would be testing that specifically with the mouse, to see if it's a problem that has only taken out Com1/3 somewhere.

Another couple of things in this brain dump of all possible weird things I've seen happen with serial ports, are...

Maybe it's something the cable of the mouse is picking up, as an antenna and backfeeding the board with that it doesn't like and is screwing things up. Something other boards tolerate, because enough stupid little tantalums or disk caps are doing their job, whereas one here has gone dead and is not filtering, so the noise gets through and messes with the wrong thing.

Winbond chips... found a few occasions where these have lifted pins a little and looked grungy, like maybe over decades the factory tinning on the leads didn't agree with the solder used to solder them to boards, metallurgy black magic. Just flux and reheat fixed them. I guess this is probably not your problem, unless there's some way that this system stresses the board slightly differently than the other systems you've plugged it into, i.e. separate 16bit ISA slots from the 8 bit part instead of 1 piece slots, so they can be very very marginally out of line (Also could possibly happen if the 8 bit part of a slot is more worn/loose than the 16bit part, but would prolly take a big, ass heavy card hanging in it for years or something)

Run a CheckIt3 test with serial port pins connected like this 1-4-6-9 | 2-3 | 7-8.
Pins are labeled on the adaptor which removed the chance of me wrongly connecting them (mirrored).
This is the result:

And how is in a working system:

Also, rerun the test with Terminal + pins 2-3 connected.
I see the signal changing [EDIT]in the oscilloscope[/EDIT] when typing something.
That is obviously in the problematic motherboard.

The Microsoft bus mouse i ordered arrived early today.
Works just fine.

pshipkov wrote on 2023-06-21, 18:11:

Also, rerun the test with Terminal + pins 2-3 connected.
I see the signal changing when typing something.
That is obviously in the problematic motherboard.

By signal change I take you mean you see it on the scope? So that would mean the transmitter is working, receiver is not. Since we know the card itself is good it could still be the interrupt - I don't trust the Checkit result in that matter, it's difficult to make a proper test case if the receiver is not actually working. But it also can be a weak bus transciver chip, like a '245, I think I see one on the mobo. The theory is it's too slow switching the direction of signals so I/O writes work but reads only work with enough software delay - which the VGA and SB code could use.

So, assuming you want to dig further into it, first check what is connected to the lower 8 data bits of the ISA bus, we are looking for a '245 or maybe a pair of '244 chips. Then you'd need to desolder it, put in a socket and a replacement chip to make sure. A lot of work and frankly in the dark, it could be something else. But that would be my next step. Well actually I still owe you a testing program but I didn't have time to write anything, but when I do I will try to test the possible slow chip response issue as well.

I wonder if the AT bus reference clock is unstable or something.

Which Microsoft bus mouse and InPort card did you order? Got photo?

@Deunan
TBH, i don't know how much more time i want to invest in this motherboard.
This thread and the effort around it was mostly out of the unusual case.
I will eventually get back to it (starting from your last suggestion), but for now i am going to pencil down.
Time is tight and i already burned too much of it on this subject here.

@BitWrangler
It is something with the motherboard for sure.
Btw, i tried a dedicated 8-bit Serial/Parallel ports card - same issue.
So the problem is for sure somewhere in the 8-bit bus.

@feipoa
It is a new old stock - crisp and shiny.

Glad to hear the quick workaround checked out. That was a very common Microsoft mouse. I know the serial variant had a scroll wheel option, but not sure if the bus mouse variant did. Anyone know? I prefer 3-button mice since the middle button comes in handy with games and scrolling pages in Internet Explorer, Excel, Word, etc.

I still think spending time on a native PS/2 keyboard controller adaption will be worth your time in the long haul.

I think there was a 3 year gap between last busmouse and the scroll wheel appearing, could be wrong. Busmouse saves you slots if you have a VGA card with a mouse port... though you'd mostly want those on 386sx and prior, speed wise. There were some with a 9 pin D mouse port, IDK if you can plug the serial/bus dual protocol mice straight into those or not. (The ones with a default 9 pin and 9 to DIN adapter, rather than the DIN native and 9 pin adapter)

pshipkov wrote on 2023-06-21, 22:00:

TBH, i don't know how much more time i want to invest in this motherboard.

Instead of writing a more complete test program I created just a simple version to test the ISA I/O. So there is no need for any loopback dongles to be attached (in fact having one might trip the last test). Just run the program and report what was output to the screen. If you have neither time nor interest in doing any more with this mobo, it's OK, I have little free time as well. One last thing, the default IO port is 0x3F8, if you want the program to use a different port run it like this: serial 0x2F8

All tests pass with your executable on the system where mouse is not working.

That's good, at least we now know the I/O seems to be fine, and in general the serial port registers seem to be mapped correctly. So I guess I'll have to write that loopback test after all - problem is, that needs to be tested on real machine with serial port pins 2 and 3 tied together, so again I'll need some time.

Thanks.
Btw, I tested this already with terminal. It does not echo.