What's new
A web interface has the advantage that the pi is less critical to build in. (You don't need a visible display and buttons you can access).
It also has the advantage of no additional hardware costs. (If you have a pc or tablet or smartphone) (who hasn't?)

It has the disadvantage that it's more complex to program and more complex to setup.

A gui that can be used over a vnc connection can work as well. There are vnc clients for most platforms.
It might ease the programming work.

If you take the display road, you might find some cheap ones with buttons on aliexpress or other chinese sites.
They shouldn't cost more than 5 bucks. The annoying thing with lcd displays is the contrast adjustment that changes with the temperature.

Oled displays don't have that problem but are still more expensive.
 
@obcd Good suggestions. I'm torn between the ideas. In terms of screens I've found OLEDs that cost around £1, so cost wise it would only add maybe £2 to each board to include a little screen and some buttons. The issue with this is that some of the setup is quite complex, such as setting up maps etc. and it might be better to have a web interface which would allow you to fully customize. But on the other side, people might find it hard to setup the Pi with Wifi / Ethernet and so a black box setup with a little screen would probably easier for others to use.

OpenJVS runs as a service on the Raspberry Pi all the time, and so its config files can be modified and then the service restarted to make changes. Although OpenJVS needs to be written in C, I can write the menus and web interface in Python which should make it much easier to program, and could possibly include both a screen and a web interface together.

Took me about 5 minutes to setup a map for this steering wheel - hoping to get started on the proper force feedback drivers soon!

 
Last edited:
Think of Apple products and make it as user friendly as possible for the average person (me).. I am very sure that people would pay whatever amount for that.. I am not sure why this tread is not on fire,what you are doing is incredible, very exciting stuff and I was looking for this solution to play theses games with a standard steer wheel and a light gun.. You adding force feedback is jaw dropping.. keep up the good work:)
 
If a screen is as cheap as you said, then I wouldn't mind paying for that. I was thinking it'd be more like 20 Euros.
 
I'm currently a bit stuck on the Force Feedback portion of the code. I've got a small test script running that attempts to reply to Outrun 2 SP on the Lindbergh's force feedback connection, but I always seem to get an 'Original point error.' come up.

I believe this is something to do with the reporting back the position of the wheel (which OpenJVS does constantly), and it looks like the wheel needs to turn in a specific way for the tests to work.

I was wondering if anyone had any thoughts about how to get passed the initialization phase, and if anyone else has had an original point error, and how they fixed it.

These are the dumps of the codes I'm getting, and replying:
  1. Lindbergh -> OpenJVS: FF 00 00 7F [OK]
  2. OpenJVS -> Lindbergh: 11
  3. Lindbergh -> OpenJVS: 81 30 7F 4E [OK]
  4. OpenJVS -> Lindbergh: 11
Stages 3/4 repeat many times, until the entire process runs again and then fails. During this time I've tried turning the steering wheel, leaving it at the center, moving it to the center quickly and everything else you could imagine!

The two posts that I've been using for reference are:

Force Feedback Board (FFB) adapter
Force Feedback Translator - Sega MIDI, Sega RS422 and Namco RS232

I'd be more than happy to hear anything from anyone about what they might think is going on, or any suggestions to get it past the init stage!
 
Admittedly I don't own a ton of Sega racing games, but the ones I do have initialize the wheel by turning full left, return to center, then full right, back to center. I think the timing is critical.
 
There are a couple of modes for OR2SP in the Lindbergh. I believe for a single wheel FFB, it's supposed to be set to standard mode rather than deluxe, which may be the default.
 
Thank you both for your replies.

@nem For Outrun 2 on the lindbergh, it seems to just move about 90 degrees to the right and then goes back to the center. I get 1 command from the Lindbergh to say initialize and then it seems that maybe it watches what the wheel does, so I am worried you are right and that the timing of specific parts of this sequence is critical. Might be time to open up the outrun2 exe in IDA and see if I can follow what its looking for!

@winteriscoming Yep 4 modes I think - Standard, Upright, DX and SDX. I'm running in the standard mode at the moment which I think is the right one.
 
It is EXACTLY what i was looking for since more than 1 year...
if i can finish the "consolization" of my Naomi 2, i'll put some picture of the setup, but all of this seems to works well.
thank you !
 
@tawy You're welcome mate. Feels free to message me with any questions, as the setup is a bit tricky. I'd love to see a video of you using it if you get it working!
 
Managed to borrow a Ninja Assault cart from a buddy, and gave it a test with OpenJVS. I can get into the game and use all the buttons but unfortunately I can't get the guns to function (analogue/screen position), so something must be wrong. Waiting to do some debugging with a real Ninja Assault Cab and I/O to hopefully get it fully functioning. The game looks really well made, and I'm really excited to play it properly.

 
Last edited:
I can get into the game and use all the buttons but unfortunately I can't get the guns to function (analogue/screen position), so something must be wrong. Waiting to do some debugging with a real Ninja Assault Cab and I/O to hopefully get it fully functioning.
Ninja Assault doesn't work the same way as other NAOMI gun games.

It uses CRT guns and has a special IO board that syncs up with the video output to make the CRT guns work.

It's possible that it doesn't use the Analog data at all for gun positioning.

I'd love to know if it's possible to make it work with Analog guns as I'd love to be able to play this game with the other NAOMI Gun Games on my shooting setup.
 
The machine has a few little boards that make it work:

HVBUF - Basically is a VGA pass through and break out, to take the sync signal out of the video to send it to the I/O board
The actual gun I/O - Connects to the guns, JVS line, and the HVBUF (sync signal)

I'm thinking this layout means that calculation must be done in the actual gun I/O, otherwise it wouldn't need the sync signal?

The possible ways to communicate analogue data through JVS that I can think of is Rotary/Analogue or Screen Position data. I was under the impression that it used the screen position data type, but it doesn't seem to do anything with it. I've tried analogue, and rotary but they where both a no go. I only really messed with channels 0-4 though, so may be useful setting all the channels just to check that they didn't use a really high up channel for some reason.

I can't think of any other way it might be communicated to - I really doubt that the actual Naomi would do the sync signal processing itself as i'm pretty sure it would make development really hard, as the system would have to run really tight to be able to process properly.

I do actually have access to the real machine at an arcade, so hopefully the Naomi JVS test menu and/or a logic analyser will tell us something about it!
 
IIRC when I looked at this a while back there was no data being sent on any of the analog channels so it was using some other method to communicate the screen position.

I don't know what input method it's actually using but I think having access to an original machine will help for sure.
 
Nice sleuthing :thumbsup:

Now can anyone here tell me what type IC7 on the V222 JYU PCB is ?

And the second question, what is the easiest way to sniff the DATA+ and DATA- on the JVS line ?
 
The reicast emulator project is making things too easy!

github.com/reicast/reicast-emu…aple/maple_devs.cpp#L1597
so, according to that the "837_13844" also has a "light gun" input type.

I'm thinking this is the JVS Serial touch-screen input since that's one of the features of the 837-13844
 
Yeah I think you're correct, this is what I was referring to when I said 'screen position data type'. I'm not really sure what its official name is, but I know its feature 0x06. It's used in this game and Mazan Flash of the Blade. It seems as though Namco where the only people to really use feature 0x06 the way it was intended in the JVS manual.

This was already what I was spoofing, but maybe it doesn't like the fact I told it I had a 8 bit gun, and not a 16 bit one - or realises that the name I supplied for the I/O is wrong and so doesn't listen to the gun data properly. I'll have some time this evening to try it, and hopefully will be able to report back exactly what the I/O needs. Reicast also has a strange calculation to work out the X/Y values, and i'm unsure if this is due to the fact they're converting raw mouse data, or that Ninja Assault expects some strange numbers not from 0x0 -> 0xFFFF.
 
Back
Top