Yes, yes, it's really me (grin)--hadn't wandered through these boards in far too long, and I saw a few questions, etc. So to clear up any confusion, I thought I may as well give a re-statement of the status of hidsporb, the good ol' confusing serial-to-HID driver for the SpaceOrb 360. Hopefully this will clear up a few things.
First: No, I haven't stepped in to make a grand announcement that I have solved all the orb's problems and the new version of hidsporb is out. Sadly, I haven't worked on it in years; I just got tired of beating my head against it and life got VERY busy about that time--major career change, major family issues (my parents, not my wife and I), just a lot of thrash which took me away from coding. One can't have everything.
The current release of hidsporb only works with orbs that have a certain firmware revision. The reason is actually fairly simple--these had a firmware which responded to powerup by transmitting a string across the serial port which identified it as a PNP device to Windows, so it was easy to hook into the "pnp hardware detected" system of WinXP. Unfortunately, older orbs (and desktop spaceball models) did NOT automatically identify themselves, so we had to find some way to manually query the serial ports, which meant hooking into the hardware enumeration system by creating a "bus driver" which would do that work for us.
Yuri did that, and it worked wonderfully. In fact, it worked so well that we were able to add support for at least one desk-mounted spaceball (the 3003? The thin one with one button on each side of the orb), and serial-to-USB adapters actually hot-plugged orbs. I was in hog heaven, and even produced a screenshot of Serious Sam in 4-way mode with screens played by mouse/keyboard, serial orb, serial-to-usb orb, and Spaceball.
Only one problem--you couldn't UNplug an orb. Something was going wrong in the device stack where something wasn't being released properly and the driver would just hang waiting for input. And since it was running in driver privilege, it would hang the entire system immediately. Worse, when you power down the machine, it "unplugs" devices from the device stack, and so an XP installation running the new driver could never be shut down properly; even UNINSTALLING the driver was problematic.
For obvious reasons, that one was never released to the public, though it's still available if you want to give it a whirl and are willing to accept a "this may chew up your hard drive and spit it out" product (I had to reinstall XP at least once during development. Driver development isn't as fun as it sounds).
Unfortunately, Yuri lost interest and I ran out of time, so the project is pretty fallow by now. I see that a couple of folks are interested in taking it for a spin, which is great--that's what open source is all about. I'd be glad to help out or hand the reins over.
I've also decided that there is probably a Better Way. One possibility is a generic HID device driver that isn't attached to a real device, but presents itself as a hideous FrankenControl with lots of axes, buttons, etc. User-space programs then send messages to this device to set axis/button/whatever values. That way, a user-space program could read the orb and push the device around, leading to all kinds of neat ideas (like gluing together multiple controls into one, controlling a desktop orb with one hand and a pile of buttons with the other, whatever).
The other idea--and this one is really exciting to me since it's totally new ground--is a hardware driver. No, really, I mean a driver implemented IN hardware. Recent "inexpensive" microcontrollers have been used to implement HID devices with ease, usually of the "attach potentiometers to these pins and buttons to these pins" variety. But recently several companies have come out with microcontrollers attached to USB controllers; Atmel in particular has a couple of parts which look very nice, and I have a couple of their USB demo boards (about $30) on backorder; they have software available which, uploaded to the board, turns it into a keyboard or joystick HID device, so I'm pretty sure I can find a way to attach a serial port and hack the thing into a SpaceBall/SpaceOrb interface board (hey, you could even have actual buttons to click it into chording mode, or a rheostat to turn to modify the sensitivity--although mapping axes might be trickier so I may have to still intercept HID packets from the machine). It would be expensiveish to get all the hardware (in the $40 range if I still have to use their dev board, and I can't very well do the kind of fine soldering these compact chip packages need), but the idea of having a box that you could plug your orb into and then plug it into ANYTHING with a USB port (Windows, Linux, OSX, heck, even USB-equipped consoles!) sounds pretty freakin' awesome. I know it's possible (heck, I found someone who made a converter box for the old gameport-based MS Sidewinder joystick), and as long as I know it's possible, I can probably find a way to do it.
So anyway, that's what's on the docket. I wouldn't hold my breath, since I've never played with microcontrollers before in my life, but that's where I'll be exploring. Pretty much the only reason I even have a Windows installation these days is for games, so it's hard to get excited about doing Windows drivers work again, I'm afraid--but if other folks are interested, I'd love to try and help where I can.
I'm still available at my old old old email address; username is still vputz, mail server name is still nyx.net (hopefully that will throw the spambots off).
Good to see the orb going strong even at this late a date!
SpaceOrb drivers and software discussions
1 post • Page 1 of 1