I'm on a role with these cheap little boards. I picked up an stm32f4-discovery board, which is the cortex-m4 version of the stm32f0-discovery board I'm using for my PS2 to pre-ADB and ADB projects. I picked this one up because it has a USB OTG port to allow plugging in a keyboard or mouse. Anyway, they're about $15 from digikey plus shipping, so not quite double the cost of the stm32f0 board, but still pretty cheap for something with USB OTG.
I took the ADB code from the stm32f0, and pieced together a bunch of sample code from ST, and am able to use a USB mouse on a Mac SE, using ADB. I put the code here for the time being.
Mouse was relatively straightforward. Keyboards have a little catch: most keyboards are USB hubs with the keyboard as a device hanging off its internal hub. Supporting hubs in USB OTG host is not straightforward. A keyboard without a hub would be fairly straightforward to setup, but I can't seem to find one in my stash of keyboards. All my USB keyboards are also hubs.
The stm32f4-discovery board is unfortunately a different formfactor than the f0 board, so the cape/shield deals I made for PS2/RJ11 don't fit and can't be used. Oh well.
Yup, that's it exactly with the USB OTG to female USB-A, commonly sold as a cable to use USB flash drives with mobile phones.
I don't have a pic handy, I'm traveling this week, but I can probably get one when I get home.
I've kind of shelved the USB part for the moment, and am focusing on the PS2 adapter. I've got new PCBs arriving soonish that will do PS2 keyboard/mouse to both pre-ADB and ADB in one adapter. Then just some hammering out of merging the pre-ADB and ADB support, and any refinement of the ADB implementation.
The big disappointment with the USB support above is only being able to use either keyboard or mouse with the adapter, and not supporting hubs.
Sounds good. Even just plugging one USB device would be really useful. I would like to be able to use an optical mouse with my ADB mac for games that require good mouse movement.
I worked on a hack to take the quadrature signals from the optical sensor of a mouse that has the older style chip that outputs quadrature (to support legacy mouse designs) and soldered them into the points where the light sensors for an Apple ADB ball mouse are soldered to. It worked... so I would like to be able to have a chip that can communicate to the ADB port and send the quadrature signals from the optical sensor. Basically a modern replacement for the ADB Logitech chip. But being able to just plug in a USB mouse would be cool too...
For optical mice, I use the Microsoft IntilliMouse that is compatible with both USB and PS2. They have a USB connector, but a passive USB to PS2 adapter works. That's kind of my primary mouse for all of these. It's optical, and although at the moment my adapter doesn't utilize the additional buttons, it could use them for macro operations at some point.
For the mouse hack, it sounds like what you're looking for is a pre-ADB mouse to ADB mouse adapter, since the original pre-ADB mice were just the quadrature signals and a line for the button. The main thing is sizing. Realistically, I'm not going to be able to make anything small enough that fits inside an ADB mouse. It's probably possible, just I'm not going to be able to pull that off. On the software side, I don't currently have any code that reads the quadrature signals, only generates them for the pre-ADB machines.
It's all from scratch, in C. I'm not sure about the question on outputs, there's no USB to PS2 here. This was based on the USB to ADB, which just toggles GPIO pins to output the ADB signal. On the USB side, it gets relative movements, and on the ADB side, it feeds those relative movements to ADB. It does swap right and left I think, since USB and ADB seem to be reversed (left is negative on one, right is negative on the other).
Yeah, I should have clarified... What signals does a PS/2 mouse send to the PS/2 port? I am wondering if the optical mouse chips send out a compatible signal. Not that it would be that practical, just brainstorming...
Looked into the STM32 platform a little more... I need to read up on programming in C for embedded apps, I only took one class on C++ in my engr training =( But I have been doing some SW dev recently so maybe it will click. =)
FWIW, I've ordered some PCBs for this project, since I've already got the code working, and all the ADB improvements I do with the PS2 version apply mostly unmodified to this, I figured I should do the last step and make some PCBs. It's still only one keyboard or one mouse, not both. But I've added both ADB and pre-ADB keyboard/mouse connectors, so ideally it'll work with both.
It's been a couple years, but I was messing with this again recently.
To fill in the gap on what happened the last couple years, I had the stm32f0-discovery board working with PS2 to ADB and pre-ADB. That worked well.
I ported that ADB code over to the stm32f4-discovery with the hopes of doing USB HID host support with the stm32f4's USB OTG port. It kinda sorta worked, but USB enumeration and device recognition was never very reliable. I ended up shelving the project for a couple years.
I then started messing around with arduinos, and tried porting the original PS2 to ADB code from the stm32f0-discovery that I had done. I found the code was far too slow for the arduino because I was using a very fast timer interrupt to drive the ADB signalling rather than a purely polling based implementation, and the arduino wasn't keeping up with the timer interrupt. It worked fine on the stm32f0 because that processor was so ridiculously overpowered for the problem, the slower code was fine. So that was shelved for a bit.
A couple weeks ago, I redid the ADB implementation as purely polling, and got that working on the arduino just fine. That made the board far smaller and cheaper than the stm32f0-discovery based version, but dropped the pre-ADB support (I'll be messing with that on a separate board rather than doing both on one).
Since I had a new polling based ADB implementation, I decided to revisit the stm32f4-discovery board and the USB host support. It occurred to me that since the original ADB implementation was so poor, the USB problems I was having could have been attributed to it interfering with the USB code, and the polling based implementation may work better. So I ported it over to the stm32f4, and got it working with mouse only, and only over ADB not pre-ADB, and it seems to be working substantially better. Hopefully I can finally get that project working with only a software change.
I look forward to seeing if you can get this to work. An ADB client that hosts a (possibly restricted) USB tree is on the list of projects I would be working on if I had made any progress with the ones I am already doing. While it’s always embarrassing to be ninja’d, in this case I don’t think I will mind. :¬)