matze79 wrote on 2020-11-25, 14:54:

This is just ISP Programming Header, there should be none onboard.
Don`t be confused.

Ah OK, thanks.

The D1-D3 red yellow and green LEDs? I would guess they are red = power, green = data from mouse, yellow = wheel presence maybe?

Also, this may be of interest for anybody (like me) who does not have a USB power source near the vintage PC. I have been running the board off a standard battery bank, while using a USB Safety Tester to monitor power usage. It is very low. I am using a new and cheap £6 optical mouse, and the power draw from the battery is very low. It is averaging 42mAh/hour. (That sounds like a very stupid unit, but I have run it for 7 hours, and it has used about 300mAh). It generally hovers about 5.09v at 0.03-0.05A. Of course this is a cheap usb tester so those figures are not going to 100% accurate. Still, I have no doubt that I can run this for a couple of days easy on a 5200mAh battery. I will test and report.

I'll have to get some kind of Frankenstein Molex -> USB A -> USB MiniB converter, and then I'll be able to power it off the PSU, but in the interim, a battery bank is going to do nicely given the very low power draw.

Tested mine today - working perfect. Found that it had issues with the mouse driver I had, but ctmouse works fine.

SmooBandit wrote on 2020-11-25, 18:59:

I'll have to get some kind of Frankenstein Molex -> USB A -> USB MiniB converter, and then I'll be able to power it off the PSU, but in the interim, a battery bank is going to do nicely given the very low power draw.

I have now managed to get the Frankenstein's monster power supply for the Adapter up and running in my 486 chassis. I went:

MOLEX from 200W AT power supply
to:
30cm Molex to USB A Female
to:
9-Pin USB IDC Dupont Male Header To Single USB-2.0 Type A Male Cable Replacement
to:
Dual USB 2.0 plus Game port motherboard expansion rear panel case bracket
to:
Generic USB type A to USB MiniB cable
to:
the Adapter.

It works great. My 486 now has built in USB power for the adapter and my USB speakers. The only bit that is external is from the rear USB panel to the adapter, which is fine with a 15cm cable. Internally, it's a birds nest of hideousness that I need to manager better. As a neat bonus, I get to connect the game port to the VLB IO card's game port header for non-soundcard joystick goodness.

Total cost is something like £15 delivered for all the bits and bobs for the power supply.

Pic attached of all the cable based madness with the connections highlighted for clarity. Bonus USB tester included showing a nice 5v power draw. (not shown is game port hooked to IO yet).

Is it too late for me to get in on this? I'd absolutely LOVE to get an optical mouse on my older systems (I have several)

I bricked my only PCI+VLB+PS/2-Header mobo about a month ago.. That was my only system with an optical mouse and I R SAD 🤣

I already have most (if not all) of the components on-hand to build one of these, I think. But buying one ready-made saves hours of work and debugging <3

What happened to the motherboard it might still be fixable?

Its time to get it updated for USB Mice to Serial hey 😀

What kind of microcontroller? There are a few with USB host support that could work at this point. I was thinking a Pi Pico would work well for it, people have that working with USB keyboard input and it's easily available.

No plans yet.
Ch559 is also interesting. 80C51 Core

And code snippets for arduino and usb mice already existing.

Matze79, not sure if you get notified of issues in your github repo. The brd files you posted can't be uploaded to oshpark. I submitted a service request, and they got back to me with the following information:

"This is due to some of the passive footprints: They contain near-zero sized polygons, which causes Eagle to fail in most cases. Eagle fills polygons by filling them with lines as wide as the Polygon width, which is ~zero. This effectively causes a divide-by-zero error, as Eagle winds up trying to draw hundreds to thousands of tiny lines to cover the area.

The more annoying part of it in this case is almost all of those lines are being generated over stop mask, so they don't even impact the board itself: They just cause a massive uptick in process time for anyone exporting gerbers from the file.

Changing those lines to having a width of 1 mil resolves the issue."

tech support did send me an updated sch file and it seems to work. Here's a public osh park share for anyone interested:

https://oshpark.com/shared_projects/kAAcvPKp

I assembled the device and programmed it using avrdude (avrdude ran in Windows 7, under VirtualBox on a Mac; yes it can be done!)

I think the only difficulty someone new to this project will find is the lack of PCB silkscreen of all the components. I had to load the schematics into an online viewer and verify the traces to figure out what pad is what.

I tested a real PS2 ball mouse and usb to PS2 laser mouse. Works amazing in Windows 3.1 running on my 486!

SmooBandit wrote on 2020-11-25, 12:33:

And bought one I have. Very nice product - works right out of the box.

I have encountered a bit of a tricky issue with the adapter as I have been using it this past year. I have tried three PS2 mice with it. One was a new cheap PS2 Optical mouse, one is an old bundled mouse branded HP, and one is an old, but new in box, Microsoft Intellimouse 1.3A (part number X08-70372). All have mouse wheels.

Only the old HP mouse works reliably. What happens with the other two is that they will be detected on boot, start working fine, and then stop working completely after up to 10 minutes. On the PCB the green light completely stops flashing in response to mouse movement. That is the only indication something has gone wrong, apart from the mouse pointer not responding of course.

This can only be fixed with a power cycle of the PCB. A soft reset of the PC does not help.

The symptoms seem identical in both DOS 6.22 running CuteMouse, and in Windows 95 running the native driver.

I have downloaded the software and drivers suggested in this post Re: PS2TOSERIAL : Connecting a PS/2 mouse to the serial port. PS2MASET.EXE detects the adapter and nothing appears wrong in any of the settings. However the modified drivers do not detect the mouse. I suppose I might have to set the baud rate too 19200 first?

Anyway, that's the problem. Some PS2 mice I have tested will not work on the adapter for longer than a few minutes without a power cycle.

Any suggestions?

SmooBandit wrote on 2021-10-13, 08:52:

I suppose I might have to set the baud rate too 19200 first?

I have now been able to do this, and it completely resolves the problem with the 1.3A mouse, in DOS 6.22, using the patched CuteMouse 1.9 drivers. The adapter kept working during testing over 3 hours or so. Given it could not make 5-10 minutes in 1200 mode, this is a result.

Of course, this does not work with Win 3.11 or 95, as neither of those detect the mouse at 19200 baud. I will try the patched Win 3.11 drivers and report back. Having now read this whole thread I see that no patched drivers for Win95 at 19200 baud have yet been developed.

I did have an odd moment in 1200 baud testing in Win 3.11. The adapter failed, as expected, after 5 minutes or so of use. I was able to exit from Win 3.11 and drop to a DOS prompt without rebooting. I then ran the PS2MASET.EXE program, which detected the mouse (/g parameter used). The green light started flashing on mouse movement as normal, and when I returned to Win 3.11 it was working again. (It failed again after another 5 minutes or so, as expected). This is the only time I have been able to recover the adapter from the crashed state without a power cycle. I could not replicate this in Win95. When it crashes in that OS, PS2MASET.EXE reports that it cannot find the mouse at all. A full reboot was needed to restore it.

SmooBandit wrote on 2021-10-14, 10:59:

I will try the patched Win 3.11 drivers and report back.

Working. After a fashion. I could not get the patched Win3.11 drivers on GitHub here to install. The installer kept complaining about an incorrect number of bytes in the readme.txt file, which was odd. So (to assist anyone breadcrumbing answers to a similar problem) thanks to this post earlier in this thread, I was able to extract the two modified files from the GitHub repo. I then simply installed the original drivers sourced elsewhere, and manually copied over the modified files.

I now have Win3.11 working fine with the 1.3A mouse in 19200 mode. It does not fail after 5-10 minutes.

Also - while setting all this up the mouse kept doing the usual crash in Win3.11 - I would say about every 60-120s of use. When that happened, all I had to do was open an MS-DOS prompt in Win3.11 and run:

1ps2maset.exe /g

Then it would restore the mouse for another 60-120s. Interestingly this would ONLY work with the dos prompt full screen. If the command was run in a dos window, it would not detect the mouse at all. Probably some complicated OS reason why that is the case.

Apologies for all the thread bombing here, but I have narrowed this down to the following:

The Microsoft Intellimouse 1.3A does not work for more than 60-120s on the adapter at 1200 baud, whether in DOS, Win3.11 or Win95.
This 60-120s period can be reset using ps2maset.exe.
If the adapter is set to 19200 baud then, with hacked drivers, the mouse works indefinitely.
No such hacked drivers exist for Win95.
The 1.3A mouse on the adapter DOES NOT WORK with Win95, as things currently stand.

Hope this is helpful.

There is a Error in Github Files, the Microsoft Intellimouse Driver for Speed Mode is corrupted (CRC)

If you had Problems installing it in Windows 3.x please Patience i will reupload fixed Version.

Here is working Package

leonk wrote on 2021-08-18, 02:06:

Matze79, not sure if you get notified of issues in your github repo. The brd files you posted can't be uploaded to oshpark. I […]
Show full quote

Matze79, not sure if you get notified of issues in your github repo. The brd files you posted can't be uploaded to oshpark. I submitted a service request, and they got back to me with the following information:

"This is due to some of the passive footprints: They contain near-zero sized polygons, which causes Eagle to fail in most cases. Eagle fills polygons by filling them with lines as wide as the Polygon width, which is ~zero. This effectively causes a divide-by-zero error, as Eagle winds up trying to draw hundreds to thousands of tiny lines to cover the area.

The more annoying part of it in this case is almost all of those lines are being generated over stop mask, so they don't even impact the board itself: They just cause a massive uptick in process time for anyone exporting gerbers from the file.

Changing those lines to having a width of 1 mil resolves the issue."

Thanks for telling, never run into a Problem with this.
As Aisler and Dirtypcbs had no problems yet with it.
Both accepting Eagle BRD directly so no Gerber Generation was needed.

The D1-D3 red yellow and green LEDs? I would guess they are red = power, green = data from mouse, yellow = wheel presence maybe?

Power On
Mouse Activity
Mouse Detected

Can I order this on Tindie or somewhere?

You can order from Serdashop.com