JVS Emulator

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • @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: amazon.co.uk/DSD-TECH-Converte…ds=usb+to+rs485+converter

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

      Source Code

      1. ON MAC
      2. ===================================================
      3. GAME NOT YET RUNNING:
      4. SYNC (The Sync Packet)
      5. length 9 (This is the length)
      6. byte 32 (First Data Byte)
      7. byte 2
      8. byte 2
      9. byte 33
      10. byte 2
      11. byte 34
      12. byte 4
      13. byte 37
      14. byte 1
      15. check 158 158 (Checksum check)
      16. GAME RUNNING:
      17. SYNC
      18. length 12
      19. byte 50
      20. byte 1
      21. byte 0
      22. byte 32
      23. byte 2
      24. byte 2
      25. byte 33
      26. byte 2
      27. byte 34
      28. byte 4
      29. byte 37
      30. byte 1
      31. check 212 212
      32. ON RASPBERRY PI
      33. =================================================
      34. GAME NOT YET RUNNING:
      35. SYNC (The Sync Packet)
      36. length 9 (This is the length)
      37. byte 32 (First Data Byte)
      38. byte 2
      39. byte 2
      40. byte 33
      41. byte 2
      42. byte 34
      43. byte 4
      44. byte 37
      45. byte 1
      46. check 158 158 (Checksum check)
      47. GAME RUNNING:
      48. SYNC
      49. length 9 <- This is wrong so the rest is garbage.
      50. byte 50
      51. byte 1
      52. byte 0
      53. byte 32
      54. byte 2
      55. byte 2
      56. byte 33
      57. byte 2
      58. byte 34
      59. CHECK FAILED.
      Display All
      Thanks for looking - Now looking at it I'm wondering if its anything to do with initialisation of variables being different on arm?
    • New

      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: 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.
    • New

      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 Stuff-
      Namco Sys 11 (Tek1&2 Ver.B, SE Ver.2 )
      Namco Sys 12 (Ehrgeiz, Tek3, TekTT, SC)
      Namco Sys 246 (Tek4, SC 2, some Gundam Games)
      Namco Sys 256 (Tek5 DR, more Gundam games)

      Sega Showcase (TTX2 Multi)
      NeoGeo (161in1)
      Burgertime (Dedicated)
      Capcom Big Blue (HyerSpin)
      Namco cab (2x6 Multi)
      Dynamo HS-5 (Taito F3 Bust-A-Move Again)
      Atomiswave (Ranger Mission)
      Atomiswave (Naomi2 NetBoot)
      Area 51 (Dedicated)
      Z Back (Empty)
      Space Invaders Cocktail (Empty)
      Capt America and The Avengers (Dedicated)
    • New

      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?



      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?
    • New

      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?
    • New

      bobbydilley wrote:

      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.
    • New

      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.
      Buy My 3D Printed Parts: bit-district.com
      Follow my projects: instagram | blog
      My PCB list: VAPS
      My Cabs: VOOT | RFM | Vewlix F| FiF Jr. | KI2 | UMK3 | E29 | E29| Net City | DDR
    • New

      @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?
    • New

      bobbydilley wrote:

      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.
      FOR SCIENCE ! I make and sell the JVS-PAC & other stuff, irkenlabs.com
    • New

      bobbydilley wrote:

      @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?
      if you want I can give you editing rights and you can just add it to the current list.
      Buy My 3D Printed Parts: bit-district.com
      Follow my projects: instagram | blog
      My PCB list: VAPS
      My Cabs: VOOT | RFM | Vewlix F| FiF Jr. | KI2 | UMK3 | E29 | E29| Net City | DDR
    • New

      @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.
    • New

      bobbydilley wrote:

      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.