well, good news. I found a tinyusb driver for x-input.
https://github.com/Ryzee119/tusb_xinput

it doesn't really work out of the box though, it took some figuring on my end and modding both the driver and tinyusb (more than the driver's read me says to do) but I got it to connect.
I tested an xbox one and xbox360 controller on it and they both worked. It claims to work with the original xbox controllers too. So thats handy.

Huzzah, now to make the pause key work right.

Also I've gotten some cables in for any testers, just have to find a decent cheap-ish usb hub for them too. IT would at least make for a reference kit for anyone making their own.

Wild, so I can now use a xbox controller over serial on my POD build that had no usb? Or over din/ps2?

Sphere478 wrote on 2022-11-01, 01:51:

Wild, so I can now use a xbox controller over serial on my POD build that had no usb? Or over din/ps2?

I'm just figuring things out and experimenting for the moment. Though some basic support for controllers would be fun.
Many questions about it to be answered, like mapping for example and which controllers to support, since with how tinyusb works it would have to be a white list.

It also gave a good opportunity to learn about hat/pov format and I hate it. I spent a while looking at the binary numbers it spat out trying to find some pattern for bitwise operations and couldn't find anything. So it's just a hard coded

1if number == 0
2then Up and Left Dpad is pressed.
3
4if number == 1
5then up is pressed
6
7if number == 5 
8nothing is pressed
9
10if number ==6 
11then right dpad is pressed

It applies only to the dpad btw
it's awful. though it does seem to mean that if you press up and down at the same time, then it's equivalent to not pushing anything at all.

but it's also slightly different based on different controllers? PS4 controller seems to take care of things for you and it just spits out 1 through 8 to tell you which dpad or combination of dpad buttons are pressed.
My ps1 classic controller spits out a constant 5, and either subtracts or adds either 1 or 4 to tell you which button is pressed.

Also to help deal with the problem of multiple keyboards and or controllers, i'll need to keep a global list of buttons being pressed and sent to over the ps/2 port. So if you press "i" on one keyboard and "i" on another before letting go of the first "i", then the pc won't beep angrily at you or should I just let it beep? I'd worry about some keyboard controller thinking it's smart just messing up if it got two button press down signals.

heya.

I don't have much major to say at the moment but heres something that might help someone else at some point.

Typematic, a word that my spell check says isn't a word. It's when you press and hold a key then that key is spammed after a short time. I thought that was an OS thing or a keyboard controller thing but it's actually something managed by the keyboard.
Adam Chipweske wronte an article back in 2001 about the at-ps/2 keyboard interface and he talks about various things in it. He does talk about typematic and that the keyboard controller sends typematic settings to the keyboard.
He explains the breakdown of what the keyboard says like this

bits 0-4 = is the value for the rate
bits 5-6 = is the value of the delay.
Keeping in mind that since this is binary, we count the digits right to left to bit 0 is the rightmost bit if you were to look at some binary.

(when I say value, it's more of a key for a lookup table but ignore that for now)

what is not noted, not that I saw anyway and this confused for a while, is that the value of bits 0-4 seem to be negative. So it gives you a DEC 5 as 11011 which is actually 27.
So I think you can just do a bitwise or, or subtract the value you're givin from 32 or do what I did and just flip the values in the lookup table, ie what was the last entry is now the first.

yay for learning all about the ps2 protocol.

I have also found a fairly reliable way to detect when the host computer is turned off, so that's a handy hook for a reset function.

Hopefully I grind out some progress over the weekend.

Hey everyone.

After some confusion,
I've found that supporting multiple keyboards is more than a bit tricky.

Getting keypresses from each keyboard is easy to do however the issues start to crop up when I try to set the leds. It seems if I'm trying to tell one keyboard which leds to light up while another keyboard is connecting, then tinyusb enters a weird panic state where it no longer will accept new keyboards (mice and other devices seem to be fine) and if it a current keyboard is disconnected and reconnected then TinyUSB panics with a crash, though if I tell it not to care about the additional keyboard it seems fine? I think it's a timing issue.
it's quite the headache. Ah, I'll try but if it's too flaky then I'll have to limit it to 1 keyboard.

I've also gotten some more skeletal code in place for handling typematic keys. So yay for typematic!

I decided to start uploading this project to github. The read me is a WIP but I corrected the PCB and fixed the LEDS so now they are rotated correctly (hopefully), edited photos and bleh. I'll just add to it as time goes by.

https://github.com/LimeProgramming/USB-2-232-KBD/tree/dev

I also made this thing for mounting older AT motherboards to the wall.
I'll probably put the stls up on thingieverse if anyone wants them.

Oh wow! Retro wall art!

Lol. That probably needs its own thread :p

Sphere478 wrote on 2022-11-08, 03:27:

Oh wow! Retro wall art!

Lol. That probably needs its own thread :p

well, it's just a one off

​I have a question.
​
​It seems like I can get multiple keyboards working decently but at one catch.
​I can't make every keyboard connected update its LEDS reliably, TinyUSB throws assertion errors and I have no idea why.
​
​So I can either limit supported keyboards to one or just have the leds update on the first keyboard connected.
​Maybe it seems weird to put so much effort into this subject but I do think it would be useful to have a fullsized keyboard and a small portable one connected at the same time. No other way you can really do that on most 386 or 486 systems.
​
​What do ye think?

Update on one but have support for multiple.

Just note the bug so people know. 😀

Hey

Sorry for being away, I've been having really bad headaches and not able to do much.
Getting better hopefully.

So I've decided to just have the one keyboard have indicate on its leds and any other keyboard just remain blank.

Theres also a little lock LED pattern for times when a host PC isn't connected on the ps2 port and there is a USB keyboard connected. It repeats the pattern forever happy put to itself just to let you know that it's connected and waiting for a host PC.

I got the idea from some old demo(?) software i was having some fun with in dos, the LEDs on my keyboard just started strobing and I thought it was really nifty.

AT and PS2 protocols should be working with half of the command set working. I read of non-intel keyboard controllers ignoring some commands and just sending back an ACK mimicking the keyboard ACK. So I'm not pressed to support them all.
Typematic works, enable/disable works, set scancode between set 1/2/3 should work

XT I'm still figuring out. It should send keycodes as an XT clone keyboard would but I'm convinced it does something on startup and i can't figure out what.
Tl;dr: i think the keyboard controller would spit out a keyboard error but would still get keycodes.

I did specify XTclone since ibm XT and non ibm XT are a little different. Ibm XT has the double start bit and holds the dáta líne low when idle, vs the clones which hold the dáta líne high when idle and lack that second start bit.
I think at2xt converters use the 2 start bits but leave the data líne high when idle. I don't think the data line should matter tbh since data is read on the falling edge of the clock so i might leave it high. It would make it easier to know when the host is disconnected anyway.
Plus the host can pull the data líne low to block incoming data.

Right, um ramble over for the moment. I can't believe how long this project has taken but hopefully it'll actually be good in the end.

Alright, I discovered in testing that I forgot to add a bleed resistor for the cap beside the reset button.
I think for the boards I have I'll just solder a resistor, that I'll have to order, to the side of the cap, but for my own PCB I just soldered a big resister under the PCB and that'll do for testing.

It's not very important, a connected host should have a bleed resistor that would drain the cap but if you plug out the PCB then the PCB would think it's still connected for a while. Assuming that you're powering the adapter from an external source. Not vital but still, it was a lesson to learn none the less.

I added that bleed resistor to the PCB, updated the gerbers on the github but the CPL and BOM files for JLCPCB. I set the bleed resistor value to 120k, a bit high but thats fine. The bleed resistor in my host pc measured in at 150R between power and ground. that seemed a bit low but eh.

Work has kept me busy this week, hopefully once the christmas rush is over there'll be more time.

Until then, I put this chart together to try to explain the cosine smoothing for the mouse. I think It does show what the smoothing setting actually does but ye let me know.

The maximum value a mouse axis can give is a signed 8 bit int, so that's 127 to -128 with zero being no moment along that axis.
If you follow the light blue line that is the maximum movement value of a mouse axis, each setting then "smooths" that out slightly to make the mouse less sensitive at higher speeds. Since each line has to cross the zero point I used a cosine curve to work out what the "smoothed" value should be. This is worked out on an update by update basis, not taking any previous movement into account, so it can feel a little jank at times but maybe it'll help in some application. This is as close as the adapter will get to proper mouse acceleration.

Does the graph make sense at all? I could imagine this in my head while programming in the functionality but that doesn't mean it makes sense to anyone but myself.

Thanks for the really cool project, Lime. Seems like it would be very useful for vintage troubleshooting using modern combo USB keyboard/trackpoint devices.

- Alex

ajacocks wrote on 2022-11-26, 01:37:

Thanks for the really cool project, Lime. Seems like it would be very useful for vintage troubleshooting using modern combo USB keyboard/trackpoint devices.

- Alex

You're welcome.
There are similar projects out there but I'm just working on this when I have the time to do so. Plus I'm aiming for decent compatibility and usability, so there's been a lot of learning and research.

Request:

Isa 8 bit form factor.

Use the pcb bracket?

I’m gonna need one for my 386 build and would like internal can you make it? :p Would like a internal option that slots into isa. Even if it is a blank edge connector

Usb kb support

Power from isa

Usb mouse support

Ps/2 keyboard support

Ps/2 mouse support

Suggest connection via internal serial ribbon to mobo/i/o card and external din if needed

Honestly, I've been finding it very hard to find the time to work on this. I still have controllers and even XT support to work out.

I just haven't had time.

Currently, it supports USB keyboard to ps/2 & AT and USB mouse to serial.
I've had a chance to use the device just normally, outside of the "debugging" mindset and it has worked surprisingly well.

One tip for anyone who would want to make a PCB like that, treat the 5v from the din separately from the 5v on the isa bus. The computer could pull the 5v din low to force reset the keyboard.
My adapter currently picks this up by either resetting when powered from the 5v din or by communication errors since clock and data would be low when the adapter knows they should be high.
If I knew that going into this I would have added something to tell the rp2040 if there's power on the din at all vs what I wound up doing which is playing the clock and data lines.

Well I got the main analog stick on the xbox controllers and potentially ps4 controllers (though I don't have one to test) controlling the mouse cursor. It's very surreal controlling doom guy with a 360 analog stick.
I'm still not sure about how to handle the dead zone but I'll just take some experimentation.