AndyGeezer wrote:I think people are making DirectInput drivers for JVS I/O boards.
Thing is in theory it is possible to use a Com port - RS485 converter PCB, and then a JVS I/O board.
Then use a packet driver as an input controller, who knows maybe it's been done..
Would be neat as then you could use analog controls and IR Type 2 on anything that supports DirectInput
Wouldn't that be the same, hardware bits aside, as having analog support on the PS3 (HID) firmware of the jvs-pac? It would be REALLY trivial to implement, but not having access to the hardware it would be awkward as I guess pedals/breaks/wheels are a bit different on different cabs - not to mention different shifting schemes.
If someone with a cab would commit to some debugging, I could give it a go..
AndyGeezer wrote:I think people are making DirectInput drivers for JVS I/O boards.
Thing is in theory it is possible to use a Com port - RS485 converter PCB, and then a JVS I/O board.
Then use a packet driver as an input controller, who knows maybe it's been done..
Would be neat as then you could use analog controls and IR Type 2 on anything that supports DirectInput
Wouldn't that be the same, hardware bits aside, as having analog support on the PS3 (HID) firmware of the jvs-pac? It would be REALLY trivial to implement, but not having access to the hardware it would be awkward as I guess pedals/breaks/wheels are a bit different on different cabs - not to mention different shifting schemes.
If someone with a cab would commit to some debugging, I could give it a go..
you got 8 analogue channels on Sega I/O, they don't have to be wheel/pedal. They all do the same job, they take a resistance value from a 5K Pot.
So if your hardware is 5K pot, then it doesn't matter if it is a wheel, a pedal, a stick or an gun sensor.
AndyGeezer wrote:you got 8 analogue channels on Sega I/O, they don't have to be wheel/pedal. They all do the same job, they take a resistance value from a 5K Pot.
So if your hardware is 5K pot, then it doesn't matter if it is a wheel, a pedal, a stick or an gun sensor.
Yes, but those 8 channels have to be mapped to something half-useful on the PC side, I don't think many apps could make use of 8 "sliders" - the devil is in the details when you're trying to making something useful.
KI4SWY:
The values aren't always 8 bit. The normal sega I/O reports number of bits pr analog channel to 0(unknown), while the lindbergh and vewlix(7 channels instead of i/o boards report 10 bits pr channel. Spec specifies that you should get 2 bytes pr channel as a responese from the I/O regardless tough.
The tricky part is not dealing with the RS485, the baud rate, or the wiring.
JVS has an additional specification for "sense" that needs to be handled properly with some special circuitry and logic in order to work correctly.
By this I mean it's not simply a matter of drawing low or high at a particular voltage, it also has to be related directly to the JVS state as negotiated by the packets on the RS485 bus.
I've written an easy to use and somewhat complete JVS library in C++ which I'd be happy to release. However you'll still need to get that sense stuff right if you want to do anything beyond sniffing of existing JVS traffic or basic negotiation :)
It might be possible to get away with interfacing the JVS I/O board itself without going crazy on the sense stuff, it's the Naomi BD itself that is really strict about it. (I haven't tried however, so YMMV)
For some help, here is a short dump of what the initial negotiation between a NAOMI BD and Sega JVS I/O looks like. (So you can validate whatever tests you try against it)
The packets with NodeID 0xFF are from the Naomi BD/JVS I/O before IDs have been assigned. (Think of them like broadcast packets for the JVS bus)
The Naomi BD gets ID 0x00 and the JVS I/O gets ID 0x01. You can see it reply to the Naomi BD (With destination node 0x00) with some text info describing itself.
i/o boards report 10 bits pr channel. Spec specifies that you should get 2 bytes pr channel as a responese from the I/O regardless tough.