Mike_ wrote on 2026-02-15, 19:17:

Also, rio444's project is not open source as far as I know. I'm planning to publish this once its ready and I figure out what licensing scheme to use and so on.

https://github.com/Yftul/ps-2-mouse-to-isa-replica

maxtherabbit wrote on 2026-02-24, 14:16:

They types of KVM people generally use which give these sorts of issues are the "active" ones which emulate a mouse being connected even when switched away.

If the cheap KVM you got is just a passive switch it won't really help

Actually it's not a passive switch, although it was very cheap. I think I also managed to reproduce the issue.

When using KVM switch, data transition happens very close to the falling edge of the clock, which can cause errors with current implementation. This is different from behaviour of mouse itself, where data transition happens in the middle of the high period of clock cycle.

I guess many PS/2 hosts read data in the middle of the low period or something, even though *technically* according to spec data line should be stable at least 5µs before falling edge of clock...

Yftul wrote on 2026-02-24, 14:38:

Mike_ wrote on 2026-02-15, 19:17:

Also, rio444's project is not open source as far as I know. I'm planning to publish this once its ready and I figure out what licensing scheme to use and so on.

https://github.com/Yftul/ps-2-mouse-to-isa-replica

Oh, I wasn't aware that an open source replica existed. Good to know.

Btw, did you run into similar issues with KVM switches?

Mike_ wrote on 2026-02-24, 18:29:

Oh, I wasn't aware that an open source replica existed. Good to know.

Btw, did you run into similar issues with KVM switches?

Unfortunately, my hardware setup is quite limited. I haven't tried running KVM on this board, so I focused on making a version with full USB mouse support.

I think I managed to fix this. It was caused by much tighter timings in PS/2 start condition rather than data line not being correct value at falling clock edge, even though input setup time of 3µs is not within spec. The issue was that if microcontroller was handling some other interrupt while USI's start condition detector raised interrupt flag, it would not get to that interrupt until SCL was already down. So the counter would miss one clock edge, messing up the entire thing... I still think that it's probably safer to instead sample data at rising edge, as that seems to be quite far from data transition with any of the devices I have measured.

Btw, I wonder if other adapter implementations are using bit banging instead of utilizing Universal Serial Interface (or USI) module found in some ATtinys? I'd imagine that this would be a real pain in the ass to do without some hardware support, such as start condition interrupts...

Hi, @Mike_,
Very good project, but I have one question: Does the card work with passive USB-to-PS/2 adapter?

aVd wrote on 2026-02-26, 08:01:

Hi, @Mike_,
Very good project, but I have one question: Does the card work with passive USB-to-PS/2 adapter?

Do you mean a passive PS/2 female to USB-A male adapter? Yes, it does, I even tested this with a PS/2 only -mouse. I just used an USB-A connector, as I thought it would be more common to use an USB mouse with PS/2 support, than an vintage PS/2 mouse.

Mike_ wrote on 2026-02-26, 08:52:

Do you mean a passive PS/2 female to USB-A male adapter?

Yes, exactly.

Mike_ wrote on 2026-02-26, 08:52:

Yes, it does, I even tested this with a PS/2 only -mouse. I just used an USB-A connector, as I thought it would be more common to use an USB mouse with PS/2 support, than an vintage PS/2 mouse.

Thanks for you quick answer! So, maybe in a further release you can add a through holes for female PS/2 mouse connector and a jumper-selector for activating USB or PS/2 connector. I see, that there's enough "free space" on the current revision board for such a handy addition.

aVd wrote on 2026-02-26, 08:58:

Thanks for you quick answer! So, maybe in a further release you can add a through holes for female PS/2 mouse connector and a jumper-selector for activating USB or PS/2 connector. I see, that there's enough "free space" on the current revision board for such a handy addition.

Hmm, why not. It probably doesn't even need a jumper for selection, as you could simply have traces go to both connectors and when assembling you could just populate one you need. Or both, you'd just need to not use them at the same time. It shouldn't break anything, but it wouldn't work.

Mike_ wrote on 2026-02-26, 09:19:

... you could simply have traces go to both connectors and when assembling you could just populate one you need. Or both, you'd just need to not use them at the same time.

Yeah, that's the point.

Mike_ wrote on 2026-02-26, 09:19:

It shouldn't break anything, but it wouldn't work.

And that's why I suggested the additional jumper 😉

aVd wrote on 2026-02-26, 09:43:

Yeah, that's the point. […]
Show full quote

Mike_ wrote on 2026-02-26, 09:19:

... you could simply have traces go to both connectors and when assembling you could just populate one you need. Or both, you'd just need to not use them at the same time.

Yeah, that's the point.

Mike_ wrote on 2026-02-26, 09:19:

It shouldn't break anything, but it wouldn't work.

And that's why I suggested the additional jumper 😉

I don't understand the point. It's easier to just unplug mouse from one of the connectors than it is to open the case and switch jumper. Besides using a jumper to select which connector is used would require additional support chips, as ATtiny's USI module is hardwired to certain pins. Ie. it's not possible to change it with software.

Mike_ wrote on 2026-02-26, 10:50:

Besides using a jumper to select which connector is used would require additional support chips, as ATtiny's USI module is hardwired to certain pins. Ie. it's not possible to change it with software.

Wouldn't a +5V jumper-selector on the USB and PS/S traces do the job? USB and PS/2 mice don't work without +5V power supply, nothing software involved here.

aVd wrote on 2026-02-26, 11:38:

Wouldn't a +5V jumper-selector on the USB and PS/S traces do the job? USB and PS/2 mice don't work without +5V power supply, nothing software involved here.

I guess it would probably work, as PS/2 is open drain, ie. it works with pullup resistors. But I don't see the use case here. Why would you want to open the case and fiddle with jumpers instead of just plugging out the mouse you are not using at the moment?

If you can get this adapter smoothly working with a KVM, that would be awesome. I would definitely want to build one then.

I would prefer a ps/2 port over a USB port that isn't actually USB. While nearly harmless in this circumstance. I have seen what happens when someone uses inappropriate connectors, and cables are mixed up.

Mike_ wrote on 2026-02-26, 15:03:

I guess it would probably work, as PS/2 is open drain, ie. it works with pullup resistors. But I don't see the use case here. Why would you want to open the case and fiddle with jumpers instead of just plugging out the mouse you are not using at the moment?

L-shaped jumper or mini switch near the edge of the PCB + suitable hole in backplate:

Personally I'd say skip the jumper / switch. Just have two footprints and only populate one

maxtherabbit wrote on 2026-02-27, 02:44:

Personally I'd say skip the jumper / switch. Just have two footprints and only populate one

If there are through holes for jumper/switch, you can always use a soldered bridge-wire to one of the populated connectors (USB or PS/2) as non-switchable solution.

maxtherabbit wrote on 2026-02-27, 02:44:

Personally I'd say skip the jumper / switch. Just have two footprints and only populate one

I think I will go with this.

akimmet wrote on 2026-02-27, 00:17:

If you can get this adapter smoothly working with a KVM, that would be awesome. I would definitely want to build one then.

So far it seems to work well with the KVM switch I bought. Of course more testing with other KVMs would be needed to be sure, so it would be nice if somebody else wants to try it out.

akimmet wrote on 2026-02-27, 00:17:

I would prefer a ps/2 port over a USB port that isn't actually USB. While nearly harmless in this circumstance. I have seen what happens when someone uses inappropriate connectors, and cables are mixed up.

Vcc and ground are at same pins as with real USB and there are series resistors for SCL and SDA, so it shouldn't break anything. Most likely the USB device would just think that it's plugged to a charging port or something, but I guess I could test this...

Anyways, here's the code and PCB files of this converter: https://github.com/mniemela/PS2toSerial

I'll probably do version 2 of the PCB a bit later, in case somebody wants to try building this or just suggest improvements. I also have a couple of assembled version 1s that I can send to somebody in EU for cost of parts and postage. In particular it would be useful to test this more with KVM switches, as they have been problematic with other similar projects.