MiSTer FPGA Forum

Hi, was playing around with with the new CPS1 cores with this device that I make, and couldn't get it to work properly.

https://irkenlabs.com/jvs-pac2/introduction

I'm not 100% what the link between the ARM and the FPGA is, but I got as far as https://github.com/MiSTer-devel/Main_Mi ... /input.cpp

It seems there is an 'impedance mismatch', and that the number of quirks and mismatches will only grow in the future.

Instead of trying to map physical input to either a virtual keyboard or virtual keypads, which again is mapped to whatever the game requires - I would suggest looking to the JVS standard for inspiration to avoid future head-aches.

I.e. have the ARM core keep a state for digital switches, analog channels, coins, LED's etc. The JVS standard has this already defined, and in my experience covers pretty much everything. Example of input switches:

Now that the race is on to provide arcade support via JAMMA, I wonder if a few more cabinets could be supported by revisiting this topic. Has anyone considered doing RS485 JVS over the SNAC port?

I would assume a base level of support could be established in the same fashion that cores already support DB9.
https://github.com/antoniovillena/MiSTer_DB9
https://github.com/MiSTer-DB9
https://github.com/MiSTer-DB9/Menu_MiST ... joydb9md.v
https://github.com/MiSTer-DB9/Menu_MiST ... /joydb15.v

Exhaustive list of changes to enable DB9 support specifically.
https://github.com/MiSTer-devel/Main_Mi ... les_bucket

Example of DB9 core support.
https://github.com/MiSTer-DB9/NES_MiSTe ... Support.md

Alternately you could likely hack up Input.cpp, and use a USB to RS485 adapter, and read from /dev/ttyUSB0.

I'd much rather see JVS via RS485 over SNAC though. I'd be completely content with the console cores that are supported!

hostile wrote: ↑Wed Feb 24, 2021 7:04 am Has anyone considered doing RS485 JVS over the SNAC port?

Before anyone else jumps on your for that, it's the User I/O port. SNAC is the name of a peripheral made for it

If the original core supported JVS it would certainly be a potential option, though if not (and I'm going to assume this covers all cores at present), the JVS layer would need to be added in. I'm not sure how much overhead this would add to the LEs but IIRC JVS is quite a comprehensive protocol.

I wouldn't hold my breath is what I'm getting at.

Supporting JVS-PAC over USB however is definitely possible. I'm not sure if the issues there have been worked out but I think this would be your best bet.

Still waiting for someone to use the User I/O for arcade core outputs, like Neo Geo's credit counters and EL marquee. Outrun will be fun to play with when that's done too

Thanks for the correction on lexicon. I am indeed aware that it is the user I/O port, and that Serial Native Accessory Converter is a peripheral specifically to handle the 5v vs 3.3v line levels. To be clear when I said "SNAC port", I was actually talking about the female USB A port on the SNAC converter board itself, as opposed to connecting it to the user I/O port.


Both RS232 & RS485 (JVS) use 5v of course, as opposed to the 3.3v provided by the user I/O port itself.


I'm not at all trying to hold any breath. I'd rather work with capable people as I know the original poster is. Parsing JVS is trivial. This has been solved long ago, and is well documented. If an Arduino can handle it, I'm gonna guess the Cyclone can too.
https://github.com/OpenJVS/OpenJVS
http://daifukkat.su/files/jvs_wip.pdf

Similarly folks do RS485 on Altera FPGA boards all the time, so there is no magical voodoo here.
https://www.design-reuse.com/altera/?q=RS485

Alternately you could use a MAX485 on the fingerboard / adapter used with the SNAC converter, and break the signals down to RS232 levels again, potentially requiring less code rewrites, and allowing reuse of some of the DB9 code perhaps.
https://datasheets.maximintegrated.com/ ... MAX491.pdf

I'm not gonna lie, the thought of using JVS-PAC really turns me off. I have no desire to convert signals to USB before using them. It seems pointless. I am indeed aware of the community propensity to gravitate to and defend USB, but I'm not willing to debate those semantics. Of course this is an exercise in academics, but that is part of why some of us are here. It isn't all about playing games for me, as it is finding solutions, and learning in the process.

JVSPAC, at NOK850.00 is about $100 USD, a USB to RS485 adapter is $15 https://www.amazon.com/DSD-TECH-SH-U10- ... 078X5H8H7/, and a 5 pack of Max485's on a breakout board are only $7 https://www.amazon.com/Max485-Chip-RS-4 ... 00NIOLNAG/. Obviously the most cost effective route would be a minor code change, or fork to support RS485, although it may not be the most simple route at a surface glance.

Once the base level support was figured it, it seems trivial to port the JVS parsing code to the other cores that support SNAC or DB9, I could be wrong of course.

My original post was not about JVS, but rather how the HPS/Arm core communicates with the FPGA cores. The use of a a standardized bit field, like JVS does was suggested as an alternative to virtual game-pads and had nothing to do with RS485 transmission.

It seems now that MAME keyboard layout is defacto standard without doing a lot of remapping, merging/unmerging etc, and is something that works well, https://github.com/jotego/jtcps1/issues/36

yeah I was not intending to hijack the post, they are related concepts obviously, and tinkering around with Input.cpp also directly related topic.

I'm also sure you know that the JVS-PAC firmware has been updated to support MiSTer properly since you mentioned it as well.
"2021-02-15 MiSTer compatibility, changed default player 2 button 5 from I to E (MAME standard)"
https://irkenlabs.com/jvs-pac2/firmware-update
https://irkenlabs.com/images/jvspac2/fi ... -02-15.zip

Regarding the "link between the ARM and the FPGA", I thought you may find the .v files used in DB9 support pertinent in understanding that link. The "how the HPS/Arm core communicates with the FPGA cores" was actually explained in the meat of what I posted if you read between the lines a little.

Look at spi_uio_cmd(), and spi_uio_cmd_cont() if you are still interested in how the link works.
https://github.com/MiSTer-devel/Main_Mi ... i.cpp#L105
fpga_spi() is called through spi_b()
https://github.com/MiSTer-devel/Main_Mi ... /spi.h#L22
https://github.com/MiSTer-devel/Main_Mi ... o.cpp#L674

Cheers.

hostile wrote: ↑Wed Feb 24, 2021 4:07 pm I'm also sure you know that the JVS-PAC firmware has been updated to support MiSTer properly since you mentioned it as well.

I wrote the firmware, so yes I'm aware