- Thread starter invzim
- Start date
TritonDrew
Enthusiast
Received mine as well. Works right out of the box! Thanks!
lol... the Viewlix IO doesn't even properly support 6-buttons per player.
In-General though the proper way to wire up a 7-button panel is that the top row of buttons is wired to buttons 1-4 on the JAMMA edge and the bottom row of buttons is wired to buttons 4-6 on the kick connector.
That way the game properly supports 4-button JAMMA edge only games AND 6-button games that use a kick harness.
I'm not entirely sure how it's supposed to be wired on a Vewlix but the Vewlix IO boards have a bug in that it only reports 5-buttons per player, which causes some 6-button games to not function properly.
If you wire up 7 buttons, on the vewlix io - it should work, https://irkenlabs.com/jvs-pac2/keyboard-operation
What do you want the 7th button to do?
Im currently using 2x ps360's and I use the 7th buttons as a right trigger, the main problems I have with this setup is that sometimes the players get swapped in steam. and there's a bit of a faf to go back to JVS to play on real stuff, so was hoping this would simplyfy things and make it so its just a usb cable swap
@Hi @invzim
I have noticed today while playing Wonderboy a new behaviour I didn't have before, it's jvs-pac2 related only. With jvs-pac this doesn't happen.
When I press a button for running + button for jumping the character stops running and starts walking, as if the number of buttons pressed simultaneously is limited.
Happened in Wonderboy, and Super Mario Bros.
I guess something has been implemented to the JVS-PAC2 prevents using multiple inputs at the same time, the first one is dropped when the other ones enter in action.
I have noticed today while playing Wonderboy a new behaviour I didn't have before, it's jvs-pac2 related only. With jvs-pac this doesn't happen.
When I press a button for running + button for jumping the character stops running and starts walking, as if the number of buttons pressed simultaneously is limited.
Happened in Wonderboy, and Super Mario Bros.
I guess something has been implemented to the JVS-PAC2 prevents using multiple inputs at the same time, the first one is dropped when the other ones enter in action.
Last edited:
That is one of the more important features of a a product like this and is tested quite thoroughly, simultaneous input up to over 20 keys is tested. Fire up a game like SF2 or MK3 in MAME which have good test modes, go to input tests and see if you can reproduce the error.
Is the input on the OLED showing what's expected, and which OS/emulator are you using?
Happened with Groovymame and Retroarch with Jvs-pac2. It doesn't happen with Jvs-pac1 with both emulators.
I will do the test you told me too but I am pretty sure I can reproduce it everytime in WB. Just by maintaining direction+fire then jump while maintaining direction+fire the character stops running until the fire button is released and maintained again. The characters never stops moving but it definitely stops running. The direction isn't cancelled but the running stops when the fire command is acknowledged.
EDIT : I have tested MK2 inputs and here are the results of my inputs.
The bug doesn't happen with all combinations but in a certain order.
To reproduce the bug buttons must be maintained and cumulated without releasing the first ones.
- If you press all buttons simultaneously no problem they all work
- 1+2+3+5+6 no problem
- If you add button 4 to any of these buttons the bug happens, it cancels the combination.
- Right direction + 1 + 2, same thing bug happens it cancels button 1
Some combinations provoke the bug others don't but it's really constant and precise, I mean it's not a random bug.
I will do the test you told me too but I am pretty sure I can reproduce it everytime in WB. Just by maintaining direction+fire then jump while maintaining direction+fire the character stops running until the fire button is released and maintained again. The characters never stops moving but it definitely stops running. The direction isn't cancelled but the running stops when the fire command is acknowledged.
EDIT : I have tested MK2 inputs and here are the results of my inputs.
The bug doesn't happen with all combinations but in a certain order.
To reproduce the bug buttons must be maintained and cumulated without releasing the first ones.
- If you press all buttons simultaneously no problem they all work
- 1+2+3+5+6 no problem
- If you add button 4 to any of these buttons the bug happens, it cancels the combination.
- Right direction + 1 + 2, same thing bug happens it cancels button 1
Some combinations provoke the bug others don't but it's really constant and precise, I mean it's not a random bug.
Last edited:
Not sure about 6 buttons + button 4. I tested only button 1+4 2+4 1+2+3+4... but I am sure only about the 3 tests I mentionned. You should make your own tests too maybe it's Windows related bug. Keep in mind it doesn't happen with jvs-pac 1.
Ah, something "that" easy would not pass the QA stuff I did - but I've been bitten before and will test again with a stock JVS-PAC 2 with the firmware it's shipped with.
Bitten again, bug confirmed
It's something to do with 'modifier-keys', I'll get right on it and update the firmware.
Thanks for report @archimage!
Bitten again, bug confirmed
It's something to do with 'modifier-keys', I'll get right on it and update the firmware.Thanks for report @archimage!
Last edited:
Bug confirmed and fixed, if you release one button 1,2 or 4 - it clears buttons 1,2 and 4, all of them. Hard to believe this was not reported before or caught during testing.
Updated firmware to fix this posted here, all users encouraged to update:
https://irkenlabs.com/jvs-pac2/firmware-update
Thanks again to @archimage for reporting this!
Updated firmware to fix this posted here, all users encouraged to update:
https://irkenlabs.com/jvs-pac2/firmware-update
Thanks again to @archimage for reporting this!
Sp33dFr34k
Champion
Dude, your turnaround time is nothing I've ever seen. A bug can happen, but fixing something within this kind of timeframe, wow... hats off to you sir 
I had nothing better to do today so I decided to do something totally pointless with my JVS-PAC setup and found something weird.
My Vewlix has a Lindbergh IO installed in it since it originally came with a Taito Fast-IO, and the JVS PAC detects it fine, with the polling rate ending up around 380hz. Seems normal.
The cabinet also has one of those Nesica JVS readers installed with two mini-usb B ports on it. My understanding of the "normal" setup with this is that it goes directly to the Fast-IO board on the ttx3.
Not being a fan of normal (and not having a ttx3), I decided to plug this into the Sega IO.
Of the two ports labeled J1 and J2, plugging J1 into the Sega IO causes the a relay on the Sega board to never click and start communicating until you unplug the Nesica reader.
Port J2 is more interesting. Plugging this port into the Sega IO works... Except the polling rate sometimes starts low, around 190hz, before rising to nearly 420hz for unknown reasons.
The JVS-PAC sees this chain of JVS-PAC->Sega IO->Nesica reader as "Unknown IO". I would have expected it to keep the Sega identification.
I wonder why running this chain versus just going straight to the Sega IO results in such a different polling rate. I wonder if it's actually faster this way or if it's just a weird display quirk.
I suppose I could test this with my spare JVS-PAC and Sega IO wired up to the same button and running one of those "punch each other" tests, only really feel like trying if other people are curious too.
Having the Nesica reader plugged into anything other than a TTX3 directly seems pointless anyway (although part of me was hoping the indicator would turn blue), but I thought some people here might find my findings amusing.
My Vewlix has a Lindbergh IO installed in it since it originally came with a Taito Fast-IO, and the JVS PAC detects it fine, with the polling rate ending up around 380hz. Seems normal.
The cabinet also has one of those Nesica JVS readers installed with two mini-usb B ports on it. My understanding of the "normal" setup with this is that it goes directly to the Fast-IO board on the ttx3.
Not being a fan of normal (and not having a ttx3), I decided to plug this into the Sega IO.
Of the two ports labeled J1 and J2, plugging J1 into the Sega IO causes the a relay on the Sega board to never click and start communicating until you unplug the Nesica reader.
Port J2 is more interesting. Plugging this port into the Sega IO works... Except the polling rate sometimes starts low, around 190hz, before rising to nearly 420hz for unknown reasons.
The JVS-PAC sees this chain of JVS-PAC->Sega IO->Nesica reader as "Unknown IO". I would have expected it to keep the Sega identification.
I wonder why running this chain versus just going straight to the Sega IO results in such a different polling rate. I wonder if it's actually faster this way or if it's just a weird display quirk.
I suppose I could test this with my spare JVS-PAC and Sega IO wired up to the same button and running one of those "punch each other" tests, only really feel like trying if other people are curious too.
Having the Nesica reader plugged into anything other than a TTX3 directly seems pointless anyway (although part of me was hoping the indicator would turn blue), but I thought some people here might find my findings amusing.
If you start the jvs-pac 2 with an sdcard that has (an empty if you wish) file called "jvsdebug.txt", we can see exactly what's going on. Would actually be interesting to see what that card-reader identifies itself as and what jvs capabilities it reports.
