What's new
@Dion This is a little bit of information about the setup:

Computer working: Macbook Pro 2015 (Mac OS Mojave)
Computer not working: Raspberry Pi 2 (Ubuntu Mate)
Arcade Platform: Sega Naomi
Game: The Maze Of The Kings
USB to RS485 Converter: https://www.amazon.co.uk/DSD-TECH-C...26111&sr=8-13&keywords=usb+to+rs485+converter

Below is the trace of bytes (in decimal not hex as its a bit easier to read):

Code:
ON MAC
===================================================

GAME NOT YET RUNNING:

SYNC (The Sync Packet)
length 9 (This is the length)
byte 32 (First Data Byte)
byte 2
byte 2
byte 33
byte 2
byte 34
byte 4
byte 37
byte 1
check 158 158 (Checksum check)

GAME RUNNING:
SYNC
length 12
byte 50
byte 1
byte 0
byte 32
byte 2
byte 2
byte 33
byte 2
byte 34
byte 4
byte 37
byte 1
check 212 212

ON RASPBERRY PI
=================================================
GAME NOT YET RUNNING:

SYNC (The Sync Packet)
length 9 (This is the length)
byte 32 (First Data Byte)
byte 2
byte 2
byte 33
byte 2
byte 34
byte 4
byte 37
byte 1
check 158 158 (Checksum check)

GAME RUNNING:
SYNC
length 9 <- This is wrong so the rest is garbage.
byte 50
byte 1
byte 0
byte 32
byte 2
byte 2
byte 33
byte 2
byte 34
CHECK FAILED.
Thanks for looking - Now looking at it I'm wondering if its anything to do with initialisation of variables being different on arm?
 
i think there's something missing. how do you get these numbers? by program? or by sniffing device?
i recommend using logic analyzer to debug this.
 
Little project update / milestone.

OpenJVS now works successfully with a linux computer, and mostly successfully with a Raspberry Pi. Some games such as Crazy Taxi work with OpenJVS on a Pi, and others like The Maze Of The Kings don't. I think this is due to the fact that the USB bus on the Pi is used for everything, and so I don't think it is replying fast enough to the arcade system.

The project code is here: https://github.com/bobbydilley/OpenJVS

It currently supports a keyboard as the only input device, and reads the keyboard -> JVS input settings from a map file. Now that the project mostly works, I will focus on adding in more input devices (mouse, aimtrak, wheel, joystick) and getting more map files for different games added. Once joystick and mouse have been added, I will make a video detailing how to get it up and running.

It would be great if someone could give it a go (might have to be a technically minded person, as will require you to setup a Raspberry Pi with linux) and give me feedback on the setup process. I've got a Lindbergh coming soon, so will be good to test it out on that and see if it supports it properly.
 
Would a more powerful mini PC like an Odroid XU4 possibly be able to keep up with the USB traffic maybe? I would not be opposed to even using an actual mini PC.
 
My thoughts exactly - even an old thin client would probably suffice. Down the line I’ll do some proper testing with other mini pcs!
 
I'm not that familiar with the RPi architecture, but are the GPIO pins on the USB bus as well? Would there be any benefit to driving the JVS serial communication over GPIO (aren't there a couple of serial-specific pins at GPIO14 and 15?) and reserve USB for input devices? You'd probably have to use some kind of TTL to RS455 (ttl->RS232->RS455?) translator circuit, but it's probably not that complicated. Perhaps there's a simple way in your code to direct the serial traffic to this port?

pi3_gpio.png


In my experience with MEGA JVS, various JVS motherboards didn't like the amount of time it took me to reply to all 6 channels of analog values. I implemented a means of reading analog inputs faster than I was and got all channels working successfully on all JVS motherboards I have access to. I'm guessing if you're playing CT, that you've implemented analog. I'm not sure what your method for analog reading and replies is, but perhaps you can cut down on analog read times. CT would be using 3 analog inputs and Maze of Kings would be using 4 if you've implemented 2 player controls, correct? Does MOK work if you only read and report the values for the P1 controls and just zeroes for the rest?
 
The idea of using the GPIO pins has been mentioned before - I think @invzim (phone isn’t showing user list so can’t work out if that’s the username I mean) has a board that fits to the top of a Pi zero tha uses the GPIO. It’s a good idea and would be cool if someone could try it and send back the results!

That’s very interesting, thanks for the heads up. OpenJVS has one thread which replies analogue values strait from an array, so I’m not sure if I can make it any faster but I’ll have a try zeroing everything and see if that helps it.

While we are here, you don’t happen to have made a list of which analogue channels/button channels are used for each game? Instead of everyone doing some JVS thing, maybe we could try and create a public document with all the info about which games require what?
 
While we are here, you don’t happen to have made a list of which analogue channels/button channels are used for each game? Instead of everyone doing some JVS thing, maybe we could try and create a public document with all the info about which games require what?
I'm mainly focused on driving games and they all use channels 1-3 and map up the same for wheel, accelerator, and brake.

There is a list somewhere... @twistedsymphony, am I remembering a list you have?

Edit: an exception to the driving game rule is that F-zero has an added channel for the yolk up/down movement. It's on channel 4, IIRC, and I can't remember if everything else maps up the same as the other drivers.
 
You're probably thinking of this: NAOMI Net-Boot BIOS and I/O Board Compatibility Chart

but there isn't anything that compares analog channels.

while there is a lot of similar mapping between games, there's just as many differences.

for instance Club Kart I think has inverted steering and uses twice as many bits for it's analog steering signal, making it mostly incompatible with other driving setups.

Gun games usually map the X and Y the same but the trigger/screen out/alt fire functions aren't always mapped to the same buttons.

for analog stick games you have Zombie Revenge which has an analog stick and 3 buttons, the you have a baseball game which has an analog stick mapped the same but an extra analog "bat" control on the 3rd channel but it only has 2 buttons which means you can't use a baseball panel for Zombie Revenge. then there's Monkey ball with no buttons , but the axis are inverted.
 
@winteriscoming I was recently thinking about what you said about the analogue channels, and realised a really silly thing i've been doing. In OpenJVS I get in the entire JVS packet from the Naomi, process all of it, and then send it out as one big chunk at the end. If I just reply to each part the second i've processed it, rather than waiting untill I've got the whole response it will be much faster! Im really hoping this might be the final fix that makes it work properly on a Raspberry Pi! Edit: On further inspection I need to send the message length at the start, so processing+sending inline is probably a no go. In Mega JVS I'm assuming you send the entire response after processing all of the messages from the Naomi?

@twistedsymphony Thats a really useful list, I might copy it and try to add which buttons/analogue channels each game is using if thats okay?
 
The idea of using the GPIO pins has been mentioned before - I think @invzim (phone isn’t showing user list so can’t work out if that’s the username I mean) has a board that fits to the top of a Pi zero tha uses the GPIO. It’s a good idea and would be cool if someone could try it and send back the results!

That’s very interesting, thanks for the heads up. OpenJVS has one thread which replies analogue values strait from an array, so I’m not sure if I can make it any faster but I’ll have a try zeroing everything and see if that helps it.

While we are here, you don’t happen to have made a list of which analogue channels/button channels are used for each game? Instead of everyone doing some JVS thing, maybe we could try and create a public document with all the info about which games require what?
I did, and the basic stuff worked fine - but I needed to go to register level programming to get the UART stuff tight enough. With the RPI3, you also need to muck about with the kernel so the 'good' uart is exposed on the IO pins, as by default it serves bluetooth IIRC. I don't think a USB 485 adapter will cut it in all cases.

The thing that is tricky though, and needs special hardware is the sense line. As an io board, you need to sink it to two different levels. First "level" is when a cable is plugged in, second is when slave is initialized (0V). The sense coming out of a JVS master is 5V, which you should not feed the 3V3 pins on a raspberry.

My 'current' PCB for the raspberry does not do this properly, so it's on ice for the moment while other projects are being worked on.
 
@invzim Yeah I thought about attempting to do register level UART, but decided against it. I think there are lots of other cheep computers out there (such as thin clients) that could be used instead of a Pi so I'm going off the idea of spending ages and ages getting it to work with all games on the Pi. Interestingly I've never had any issues with the sense line. I simply wire the sense line to the ground line at all times and forget about it; it's worked for all of the games on the Naomi so far. Seeing as my emulator won't ever need daisy chaining, there doesn't seem much point to me to handle it properly?

@twistedsymphony That would be great - I'll PM you my google account.
 
I simply wire the sense line to the ground line at all times and forget about it; it's worked for all of the games on the Naomi so far.
I'm surprised that's working. It's more than just about daisy-chaining. The JVS spec, as far as I understand it, has the same requirements for the sense line on the first node.

Basically the motherboard (JVS master) is supplying 5v and measures it for changes. Nothing plugged in keeps it at 5v, and the master knows no node is plugged in. The node has a series of 4 diodes on the sense line acting as a voltage divider, so when the the node is plugged in, even if not powered, it will pull the sense line down to 2.5v, and the master knows at least one node is present and ready for initialization. Then when the node gets the command to do so, it sinks sense to ground, and the master knows that when it senses 0v, it has found the node directly plugged up to it.

If you were daisy-chaining, then your board would have to take on that same behavior to drive the next down-stream node.

Perhaps NAOMI isn't really focusing on the behavior of the sense line other than know it's grounded. Perhaps other JVS motherboards don't really care either. Perhaps there isn't anything about the process that actually measures for the 2.5v state.

MEGA JVS doesn't have daisy-chaining, but does have the voltage divider and a MOSFET to drive sense as I mentioned above. I recall initially wrestling with the behavior of the sense line to make pairing work, but perhaps it wasn't needed.

I would think the behavior would be consistent across all games on a given platform. So if you successfully pair with a motherboard for JVS input tests without a game, you're probably going to be ok with pairing with a game.
 
@winteriscoming Just got a Lindbergh today (very excited) and OpenJVS doesn't work at all on it. The only messages its getting are the RESET messages, so I'm thinking maybe my grounding the sync pin worked on the Naomi but doesn't work properly on a Lindbergh? Maybe it does the check for the 2.5 volts, where as the Naomi doesn't? So I'll have to think about a different way of making the dongles work :/

Also as a side note, the Lindbergh sometimes doesn't turn on and just sits at a black screen, other times its fine - and when it boots it stays on forever. Any ideas?
 
It's a pretty simple circuit. There's a schematic on a post somewhere in the MEGA JVS thread. I'm not sure what you'd do to drive it with a PC. An RPi could probably use GPIO. Maybe use a cheap Arduino variant to drive a sense circuit and communicate with it over usb?

Not sure on the Lindbergh behavior you're describing. I don't think I've seen that on mine.
 
Here's my implementation of JVS sense line :

Untitled.png

It's working, but not being made for those game platform, might be useful.
 
Here's my implementation of JVS sense line :

Untitled.png

It's working, but not being made for those game platform, might be useful.
What sinks it to ground for 0v state?

Edit: here is the schematic I use, where an Arduino output drives a MOSFET:
download.png
 
Last edited:
Uhm... the sense pin connected to arduino as input. i don't quite remember, but when i omit the diode, the protocol refuse to work.
 
Back
Top