What's new
Experimenting with some past V1 sketches, I've got a V2 sketch that now seems to be working with the RE. At this point I'm going to start introducing the newer functionality one-by-one and see if I can figure out what breaks it... ?(
 
I don't know why this is an issue, but RE seems to not like it when I report more than 6 active analog channels, or rather it doesn't like the amount of time it takes for the MEGA JVS to process more than 6 channels. I had it defaulting to a 1-to-1 SEGA Type 1 profile where all 8 channels are being used.

I don't mean # of channels reported in features, but rather the odd behavior comes when I'm actually polling more than 6 channels and reporting the values in the analog reply. As soon as I have a 7th channel, the issue with apparently ignored communication comes up.

I'm guessing something about the turn-around time for processing all 8 channels is taking longer than what the RE is willing to wait, and apparently the other JVS motherboards I have don't think it's taking too long.

I'm not sure what I can do to speed up analog polling/processing. A potential work-around is to do a phased approach where I store the values for all 8 channels, and only update half of them during each polling command. For most mapping profiles, though, I doubt 8 channels need to be used, so a RE game with 7 or 8 analog inputs may be an edge case at best (or non-existent), so perhaps I'll just make sure my default profile only uses 6 (or less) channels and any profiles I use on RE don't exceed 6.
 
I'm not sure what I can do to speed up analog polling/processing.
Found it: http://forum.arduino.cc/index.php?topic=6549.0

Using this, I'm able to get all channels working on RE. It will hopefully also make for a better overall I/O with analog being reported faster than it was. However, there would still be a speed increase, probably imperceptible to a human, for reducing the number of channels being used in a given profile.

There's still something in my original V2 code-base that's choking things on the RE, but my updated V1 code made to work piece-by-piece on a V2 is working. I'm not sure where the disconnect between the 2 is at this point. I believe I have implemented all newer features back into it and it's still working on RE. It's going to drive me crazy, but I guess I don't HAVE to know what was wrong in the original code...
 
There's still something in my original V2 code-base that's choking things on the RE, but my updated V1 code made to work piece-by-piece on a V2 is working. I'm not sure where the disconnect between the 2 is at this point. I believe I have implemented all newer features back into it and it's still working on RE. It's going to drive me crazy, but I guess I don't HAVE to know what was wrong in the original code...
Is your timing for V2 based on the Type 1?

The V1 matched more closely with Type 3 especially on RingEdge. I did not get to try on Lindbergh but I don't think it will be any different.

Even on the Digital I/O there was a slight lag in receiving a signal. Not sure if that helps the difference in both but it was something I noticed between the two.
 
Is your timing for V2 based on the Type 1?

The V1 matched more closely with Type 3 especially on RingEdge. I did not get to try on Lindbergh but I don't think it will be any different.

Even on the Digital I/O there was a slight lag in receiving a signal. Not sure if that helps the difference in both but it was something I noticed between the two.
The thing is that I never really had a means of measuring timing for a stock I/O, so nothing was done to ensure my timings matched. Even within my V1 code iterations, I eventually introduced something that made the RE stop working, because I had to go back pretty far for a version that worked. When timing started being a concern is when Lindbergh testing (I purchased a Lindbergh well into development of the Mega JVS, iirc) started showing that it wasn't pairing.

I noticed the failure happening during the initialization commands, so I started messing with adding delays to some of those replies and got it working. The introduction of a delay variable came about from that (I had this in some V1 sketches), and really only got applied to some of the initialization replies, and not the regular digital read, analog read and coin replies.

Functionally the V2 is mostly the same as V1 except for a major reassignment of pins. There was an addition of SD card reading and a header for a display (though display functionality was added in V1 code), but neither of these should have added any processing time to the JVS protocol because the cycles needed for driving both of these is done outside of JVS communication (unless switching profiles once communication has already been established).

Then I added software debouncing to the V2 code, which likely would have added some additional time to the digital switch reading, but I'm honestly not sure what negative impact that might have had.

Once I started building out profiles with the profile editor (this DID come about in the time of V2 boards) and I added in mappings for analog channels, I ended up leaving a lot of my profiles with all 8 channels mapped. I suspect that the the Lindbergh was having a similar issue to what I'm seeing in RE, but somehow the initial delays did something to make it work, in spite of potentially overlong responses for analog polling.

At any rate, with the current code I have for the V2, where there are no artificial delays added in, I went back and tested on the Lindbergh and it seemed to pair with it just fine.

A prior odd issue I was having is that Mario Kart Arcade GP2 would sometimes boot with 99 credits. I isolated the issue to the MEGA JVS, but didn't know why. I went back and tried Triforce with the new code and am not seeing that issue in the few times I reset MKAGP2.

I'll do some more testing on all the platforms I have, but I think I may have landed on what's going to work for all of them.
 
My current V2 code appears to be working on all platforms including NAOMI 2, Chihiro, Triforce, Lindbergh, and Ringedge. All with the same code and no modifications to get it working on any specific motherboard.

At least they're working on the bench. I haven't tried in a cabinet yet with analog controls. I'm not sure what impact the analog change has, but I suspect it may need some tweaking because I think the result might have been analog values with fewer bits than before and I might need to compensate when translating those into analog replies. We'll see. I'll try to test that today.
 
Look what just occurred to me! I know where the display is going.

Coin screen.jpg
coin slot screen.PNG

My arcade projects end up being so multi-faceted that it's sometimes difficult to see an end. I'm approaching the end of this particular piece. The same coin slot face plates are used on my OR2SP and WMMT cabs, so the great thing is that one solution will cover all of my driving cabs.

The 3 buttons will be profile, test and service. I'll likely need to implement some kind of control lockout so that the buttons don't inadvertently get pressed by my daughter and kick me out of a game or throw off the controls.

I've printed out a couple of drafts and think this will end up working quite well for my purposes. I can finally clean up the switches and wires hanging out of my coin door. :)
 
Can't wait for this to be ready. So count me in for 2 pcs. :D
Planning to build a Supergun Just for JVS systems, this would the best addition to map controls.
 
I'm going to go ahead and go open source with my code, so I'll just drop this here:
https://github.com/winteriscomingpinball/MEGA-JVS

I'm not currently offering any boards for sale because I don't have time.

If anyone wants to contribute to the code to improve it, I'd be more than happy to share write access to the repository, and try to get a board your way.

The kind of interest I've seen from some people makes me think they'd be more interested in @bobbydilley 's project. JVS Emulator
 
I have submitted MEGA JVS V3 designs to pcbway.

I wanted to adapt the MEGA JVS to my WMMT cabs and was going to have to come up with some ugly and tedious wiring adapters. Doing one might have been ok, but the thought of doing it for 2 cabs has been too off-putting.

That's where the V3 design comes in!

I added headers to match up with the Namco FCA I/O's power input and its 60-pin connector that manages digital inputs, analog inputs, and outputs. So a V3 should be SEGA Type 1 and Namco FCA compatible (at least for games using exclusively the 60-pin connector - there are apparently rotary encoders and analog outs that I assume are on the other connector that are not taken into consideration with the MEGA JVS).
 
there are apparently rotary encoders and analog outs that I assume are on the other connector that are not taken into consideration with the MEGA JVS).
I don't know about the FCA but the Sega Type 1 has no rotary encoders nor any analog outputs.

Neither does the Type 3, the only difference between type 1 and type 3 is type 3 has additional digital outputs.
 
there are apparently rotary encoders and analog outs that I assume are on the other connector that are not taken into consideration with the MEGA JVS).
I don't know about the FCA but the Sega Type 1 has no rotary encoders nor any analog outputs.
Neither does the Type 3, the only difference between type 1 and type 3 is type 3 has additional digital outputs.
I was referring specifically to the FCA board. It reports having those features and I only bothered figuring out the pinout of its 60-pin connector because that's the only connector used by WMMT (and Mario Kart). I honestly don't know what other games use the FCA I/O, but this project all along has been geared towards driving cabs, so I think I'm safe excluding the more obscure features.
 
And when can we buy you some of your MEGA JVS? ;)
 
And when can we buy you some of your MEGA JVS? ;)
I don't know. It's probably not something I'm interested in selling myself.

@Darksoft added it to his list of projects, so if he ends up making an improved version, it would be available from him. Otherwise I would potentially be willing to partner with someone to manage the sales and assembly (or DIY kits) on my version.

Selling them myself is just not something I have the capacity for currently.

I'm in no rush either way, but I do want others to be able to have one at some point.
 
Back
Top