Interface Supermodel with original SEGA hardware

[bigpanik]

It will be fabulous if a Supermodel3 option allow to transmit the FFB signals directly the the original SEGA FFB boards.

Same thing to interface Race leaders and VR lamps.

[Bart]

An interesting idea. I don't have an original FFB board, however, so I'm not sure how the board is connected to the CPU board. The other Model 3 PCBs snap together via a custom bus. This sort of feature would likely require custom connectors. If someone wants to try it, it would be pretty neat.

[bigpanik]

Original FFB board is connected via 8 "INPUT" wires and 8 "OUTPUT" wires plus a GND. I will be able to test in a few months. A USB I/O interface, like USBMicro, will be required.

Thanks a lot Bart

[RetroRepair]

This would be quite interesting indeed. I've always thought emulators make good semi-drop in replacements for game boards that go down but seeing something like this would be a welcomed new development. Drive boards etc commonly fail on Sega drivers and replacements can be hard to find and expensive.

I'd be interested to see lamp outputs emulated
too. Me and ramjetr actually just got done getting elsemi's model 2 emu to output data via lua scripting we could use to simulate lamp outputs with our cabs. It'd be great to do the same with supermodel but with real lamp data.

[Bart]

I'm not sure what sort of protocol you would want to use to hook up lamp hardware to your PC, but I'm pretty sure the lamp data would be relatively easy to find (if you know what the state of the lamps should be at any given time) by examining the system register region (F0100000-F010003F). The board LEDs are in there, too.

[RetroRepair]

At the moment we are literally writing games states to a temp file in lua and reading them with autohotkey to then animate the lamps depending on what the game is doing and send the data to a pacdrive via the pacdrive dll calls. This is obviously far from ideal though and a way to call the pacdrive dll directly from the emulator would be more ideal with the output ports configurable in the supermodel ini or a pacdrive ini. Maybe I can take a look at the source and see if I can integrate that (though I wouldn't hold my breath).

Thanks for the info on where the data would be though, I'll take a look now and see if I can lock down the various outputs. It's a shame that model2 emu didn't have this data available to exploit. Really interesting that even the board LEDs are there too

[AndyGeezer]

I'm not sure what sort of protocol you would want to use to hook up lamp hardware to your PC, but I'm pretty sure the lamp data would be relatively easy to find (if you know what the state of the lamps should be at any given time) by examining the system register region (F0100000-F010003F). The board LEDs are in there, too.

Those board LEDs are very important to diagnose faults.

Shame Sega haven't made it public what all the LEDs do, but they do tell you when the GPU is processing, if there is a invalid opcode etc.

As far hooking a drive board, isn't a simple packet interface - same as Model 2 hardware.- the drive board has it's own cpu and will convert the received packet data into whatever the servo controller needs to make the servo motor work.

Sega sure like to re-invent the wheel though, US companies are fine with a simple reversable DC belt driven motor, but not Sega.

I can tell you know that the "Grid" 2010 game has an undocument feature where you can hook up a Sega servo motor onto COM1, instead of the Happ wheel which is hooked via Parallel port.

Result is night an day, with the happ motor board the feedback is limp, with the 500W Servo it is nice and strong - on the M3 wheel setup, Grid is more like Scud Race 2

[Bart]

Interesting. Thanks for the info, Andy! By the way, Supermodel already emulates the drive board and force feedback thanks to Nik and your drive board ROM dumps

[bigpanik]

work in progress... I'm currently make some test with Model 3 panel and logic analyzer.



One question: How Nik find the different values (command) send to the FFB board and actions associated? Just by checking the FFB board ROM?

Thanks

[Bart]

One question: How Nik find the different values (command) send to the FFB board and actions associated? Just by checking the FFB board ROM?

Yup, no hardware was involved, just a disassembly of the Z80 ROM code.

What are you attempting to probe with your logic analyzer? Looks like a fascinating project...