What's new
1. Hard code all mappings and have a dedicated button to cycle between profiles.
Definitely option#1 should be the best.
I only just remembered that during initialization there's a Set Main Board ID command (0x15).

This command is supposed to send information to the I/O about the game. I've just never successfully interpreted the data and sent it over USB because I was doing so during the time the motherboard expected a quick reply.

The example in the manual is:
”NAMCO LTD.;TEKKEN2;ver1.6; TEKKEN2 ver B”

If I were able to interpret these, I might be able to have it mostly automatic. :D

Do the Atomiswave2Naomi games issue a command over JVS like this?
 
If I were able to interpret these, I might be able to have it mostly automatic.
4419850.jpg
 
1. Hard code all mappings and have a dedicated button to cycle between profiles.
Definitely option#1 should be the best.
I only just remembered that during initialization there's a Set Main Board ID command (0x15).
This command is supposed to send information to the I/O about the game. I've just never successfully interpreted the data and sent it over USB because I was doing so during the time the motherboard expected a quick reply.

The example in the manual is:
”NAMCO LTD.;TEKKEN2;ver1.6; TEKKEN2 ver B”

If I were able to interpret these, I might be able to have it mostly automatic. :D

Do the Atomiswave2Naomi games issue a command over JVS like this?
Nope. The answer is always the same, but that can be changed.
 
Nope. The answer is always the same, but that can be changed.
Well, we're just looking at 2 drivers anyway, and fortunately their mappings align, so no worries here. The only difference is that Faster Than Speed has a boost button where Maximum Speed doesn't. So they can have the same mappings and the boost button just goes unused in MS.
 
Ok, so plugging USB in while powering the Arduino through the Vin pin with 12v? BAD IDEA!

In spite of me reading information to the contrary about auto switching power between the USB and power ports, I seem to have killed a Mega 2560 and maybe an RS-485 module in the process of doing so...

So there's no way I can recommend doing this.

I uploaded the code to another Mega and everything else (including the NAOMI 2) seems to be ok.
 
Ok, so plugging USB in while powering the Arduino through the Vin pin with 12v? BAD IDEA!

In spite of me reading information to the contrary about auto switching power between the USB and power ports, I seem to have killed a Mega 2560 and maybe an RS-485 module in the process of doing so...

So there's no way I can recommend doing this.

I uploaded the code to another Mega and everything else (including the NAOMI 2) seems to be ok.
Ouch. This is good to know. It's odd that on the Uno it states auto switching is possible as well. I'm taping off that external port. :)
 
Ouch. This is good to know. It's odd that on the Uno it states auto switching is possible as well. I'm taping off that external port.
To be fair, I'm using a knock-off clone from a company called OSOYOO, so maybe theirs doesn't auto-switch? I'm not going to test it on my genuine Mega, though!
 
Ouch. This is good to know. It's odd that on the Uno it states auto switching is possible as well. I'm taping off that external port.
If you look at the official schematics for the MEGA 2560 there is a circuit which does auto switching. Search for USBVCC in:
https://www.arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf
I'm not really sure what went wrong.

I suspect there IS auto-switching on these clones because with the cabinet powered off and the 12v connector, albeit powered off, still plugged up, I got odd behavior where the board would turn on when USB was plugged in and then slowly fade and die. With that 12v connnector removed, it powered on fine. I'm not sure if that's expected behavior, but it's certainly not desirable in my case.

I admit I could have screwed something up prior to my dual power source fiasco. At one point I powered on while the JVS cord was plugged into the USB port of the MEGA (my main reason for wanting to migrate to the DUE since it has a different USB port), but that didn't seem to affect operation once I corrected it.
 
Ok, so plugging USB in while powering the Arduino through the Vin pin with 12v? BAD IDEA!

In spite of me reading information to the contrary about auto switching power between the USB and power ports, I seem to have killed a Mega 2560 and maybe an RS-485 module in the process of doing so...

So there's no way I can recommend doing this.

I uploaded the code to another Mega and everything else (including the NAOMI 2) seems to be ok.
ouch. probably the usb is drawing power from the 12v. glad the naomi is still intact.
 
I only just remembered that during initialization there's a Set Main Board ID command (0x15).
I feel like I'm going crazy... because I could swear it was this command tripping me up when I booted a game, but now I'm NEVER seeing the command!

Edit: I must have screwed something up in my current code. When I load up an old sketch, I'm seeing the Set Main Board ID command again. :whistling:
 
Last edited:
Edit: I must have screwed something up in my current code. When I load up an old sketch, I'm seeing the Set Main Board ID command again.
Ok, so interesting discovery. I think the reason I was ever even thinking I was receiving a Set Main Board ID command is due to an error in the TeensyJVS code.

In that code, the case for 0x14 is missing a break, so the code for the next condition (0x15) executes as well... I must have put the the break into my code at some point along the way and never realized, due to taking out a lot of debugging, that I wasn't actually seeing the 0x15 command.

This throws a wrench into my plan for auto control mapping. I'm not seeing where the I/O is ever issued this command in order to know what game is booted. :(
 
I have push-button control profile swapping in place now. The profiles can be swapped on the fly, so even in the input test menu you can push the profile swap button and immediately see the changes to the reported switches. I think this is probably going to be the easiest route to ensure the selected profile is correct for the given game without complicating things by implementing an LCD or requiring a computer plugged up through USB at all times.
 
how many profiles you looking at storing. might be an option to uses a 7 seg display or even a small led array.
 
how many profiles you looking at storing. might be an option to uses a 7 seg display or even a small led array.
I'm not sure how many there will be at this point. Definitely there are display options, but it would require having whatever you're displaying being somewhere visible from the front of the cabinet. In OR2SP, the I/O board is mounted in the back of the cabinet, so any kind if display method will need to be visible from the front. Sure, a 7 segment LED could be remotely mounted with wires run to the back, but it may be more trouble than it's worth.

I do have the lights for the start and view change buttons at my disposal as indicators. At the moment, I've got it flashing the start button when the profile is cycled. I suppose, if the number of profiles doesn't end up being too large, there could be some kind of blink sequence to indicate the selected profile. However, then you'd have to commit the profile number to memory for which games need it.
 
I have push-button control profile swapping in place now. The profiles can be swapped on the fly, so even in the input test menu you can push the profile swap button and immediately see the changes to the reported switches. I think this is probably going to be the easiest route to ensure the selected profile is correct for the given game without complicating things by implementing an LCD or requiring a computer plugged up through USB at all times.
Sweet. Me and @freddiefiasco are working on picking up those Max. Tune 3 cabs with the 6 position gear shifters. We know you need data dumps. Standby.
 
alot of people have pi also in teh cabnet. it can be used also for this if needed in place of a pc with profiles
 
I feel like I'm experiencing about every potential issue that can happen with this project!

I've got it so that the board takes 5v from the cabinet to supply voltage to all of the 5v cabinet peripherals that run through the 60-pin connector on the I/O. I believe this would mainly be lamps, but could also power something like an opto-sensors used in the WMMT shifter, for example. The reason I did this was because I didn't want to overload the current being drawn from the Arduino.

That's all well and good, except yesterday I reversed the 5v connector and powered on... To my surprise, it didn't break much. It seems to have exclusively killed the RS-485 module and nothing else. The Mega seems to be no worse for the wear.

At any rate, I seriously need to put some reverse voltage protection in, and probably a more appropriate header that restricts the connector from being fully seated unless it's oriented correctly.
 
probably a more appropriate header that restricts the connector from being fully seated unless it's oriented correctly.
For the 5v and 12v connectors I need JST NH headers as seen here.

The bad news is it seems these are seemingly impossible to source in the US. The good news is that they are relatively simple, so I can easily craft a base for my existing header pins out of plastic on my CNC machine. I'll play around with that.


I seriously need to put some reverse voltage protection in
I may just go with simple, appropriately rated blocking diodes. Voltage drop on both isn't an issue, and I doubt current draw is too high to be of concern. The 12v is being regulated down to 5v anyway, so voltage drop across the diode doesn't matter. 5v is mostly just powering lamps, so I don't think a voltage drop will matter.

Or I nix reverse voltage protection if I have appropriate headers, and just don't try plugging them in when powered on. If the connectors can only be seated in the correct orientation, then this shouldn't be an issue.
 
Back
Top