Full button remapping and auto fire for player 1 and 2 buttons 1-6. Select and Home emulation support will be there too, still trying to sort out the best way to handle this. This is an optional upgrade to the design that is being supplied to me by @RGB. It's going to have the same button remapping and auto fire features of the HAS supergun. This will be really useful for games that have arcade unfriendly button maps, and console shmups that benefit from auto fire.
I've implemented this so the same board can be used with or without the microcontroller, so this won't negatively impact the open source design.
EDIT: I also settled on the JST NH connectors for the Auxiliary Harness. I have a personal (probably irrational) beef with XH type connectors so I just can't support adding to their use even though everybody else seems to like them.
Thanks for the support everybody. I'm trying not to get ahead of myself but it sounds like I'm getting some good news from one of the testers for the first prototypes so we may be getting close to nailing down some production details. I'm going to comb through the thread and start making a list of those who have shown interest.
Nothing is concrete yet but I'm still hoping to hit the target of under $150. I've got a new batch of prototype boards on the way right now so I can test the newest changes. Once I get a green light from my testers on monitor compatibility, I think we might be able to move into production. Functionally the design does everything that I want it to so I doubt much else will change.
Quick question for all interested parties. In the current design the volume pot controls both JAMMA and stereo RCA out. Is this preferable to most users or would it be better to have the volume pot only control JAMMA audio and leave the RCAs as line out?
I have one NNC like you and Jammafier. What's use external power supply or via JAMMA? It's seems cant use external power supply withit. And Can I use hack pad via JVS
I get what you are saying now. The console will still be powered by it's own power supply. This has not been a problem in my testing. The only thing shared between the Jammafier and the console is the ground plane.
@Arthrimus sent me a prototype for testing. My impressions thus far is that this is a spectacular product! I've posted an album of photos here (which don't do it justice) to show my results thus far:
Test Rigs/Setup
Firstly, what cabs and consoles I've tested with so far:
Cabs/Monitors
NNC (Sanwa PFX)
Blast City (Nanao MS2930)
Sega Astro City (Nanao MS
Egret II (Nanao MS9)
Consoles
NTSC PS1 SCART cable has coupling connectors (retro-access cable)
NTSC PS1 SCART cable does not have coupling connectors (retro-access cable)
NTSC PS2 SCART cable has coupling connectors (retro-access cable)
NTSC PS2 SCART cable does not have coupling connectors (retro-access cable)
NTSC Dreamcast cable does not have coupling connectors (cheap Chinese cable)
All video connections are through the high impedance connection on the monitor chassis if tri-sync; I have no JVS->to->JAMMA adapter. Power is connected from the cab's PSU; no external power. Audio is connected through the JAMMA harness when applicable, RCA connections where applicable.
From my tests, I see no difference between SCART cables that have and do not have the coupling capacitors under the SCART connector hood. As far as brightness fluctuation issues that @RGB mentioned being a potential problem, I've only seen seen one issue potentially related to that. That is with the Dreamcast boot screen (the one with the bouncing ball). And this only happens with a Dreamcast on the Egret II (MS9). This screen is mostly white. When displayed, there is black bar along the top of the screen that gradient-fades to white. When using 240p Test Suite's white solid color screen to replicate the mostly white Dreamcast boot screen, this problem cannot be replicated. From what I've read somewhere, this screen is problematic in other applications. I forget where I read that discussion.
Other than that, I have only seen issues with keystoning and pincushioning on the Blast City MS2930 which the user should be able to calibrate out. I didn't do this with the Blast City because it is such a pain in the ass to work with and it is not my cab. Belongs to a friend and I didn't want to mess with his settings. Audio works perfectly through JAMMA or RCA connection. There is no buzzing or ground looping that I can hear. I've yet to test controls and have been navigating using gamepads. I'll get to testing the MC PCB's as soon as I have a moment to dig out the RJ45 cables I've stored somewhere.
I think it is important to test this with some of the more common monitors. So I will be testing this with the Wells Gardner K7000 & K7400 over the next few days.
Also, I will test this for MAME application. I may even do the Pepsi Challenge with a J-Pac to demonstrate how much better the THS-series amp compares to the one used in the J-Pac. I'll be doing this by soldering to the solder side of the SCART connector as the prototype does not have the VGA hat. I'll report back what I find.
Alright, that is it for now. Questions or comments on what you'd like to see tested are encouraged/welcomed.
Just thinking out loud here... I've built this cool project already, that uses the UVC to downscale xbox360 to 15khz, and then uses a jamma fingerboard to get it into my cab.
But If I build a scart head output for the UVC instead, is there any reason I couldn’t pass that video signal into this? Wondering if I could consolidate, or if the video signals would not be agreeable.
I could use the optional hat to bring in 31khz directly for a trisync, just thinking about downscaling for my 15khz cabs.
edit: ...talking about this on the other thread so we don’t clutter it up here
As far as brightness fluctuation issues that @RGB mentioned being a potential problem, I've only seen seen one issue potentially related to that. That is with the Dreamcast boot screen (the one with the bouncing ball). And this only happens with a Dreamcast on the Egret II (MS9). This screen is mostly white. When displayed, there is black bar along the top of the screen that gradient-fades to white. When using 240p Test Suite's white solid color screen to replicate the mostly white Dreamcast boot screen, this problem cannot be replicated. From what I've read somewhere, this screen is problematic in other applications. I forget where I read that discussion.
I want to address this issue. It's almost certainly not related to the DC reference issue RGB mentioned earlier. Since he brought up the possibility of that issue I added AC bias resistors to the R G and B inputs as described in the THS7375 datasheet to provide a 1.6V DC offset to the RGB output of the amp. I've looked at the output of this circuit on a scope both with and without the AC bias resistors. Without AC bias resistors VPP and VMAX fluctuate together based on the video content on screen which I believe is what RGB was concerned about. With AC bias resistors VMAX is completely stable, while only VPP fluctuates based on the video content on screen. The issue with the Dreamcast is probably related to the Dreamcast's 480i mode since this test was done using a SCART cable.
Very nice write @acblunden2
Interesting device for sure, perhaps I will have to get one as well
So the Dreamcast issue, couldn’t it also be possible this has something to do with the output resolution of it? IIRC it isn’t true 640x480i but more like 720x480?
But it sounds like @Arthrimus is on top of it, so sure it will get solved
It's minor. I didn't have the Dreamcast on hand to test on the MS8 and MS2930 while at my buddy's house. I may take the setup's back to his house tomorrow and test things out again. He also has two Egret II's himself. I'll see if it is isolated to mine. But I don't see that same artifact on the NNC. I wouldn't sweat it too much since in-game screens look fine. Thought I'd point it out now in testing since there are a lot of MS9's out there. Might even be my cheap Chinese SCART cable.
Can't believe I misplaced my Saturn. In my own musings in this subject, Saturn's RGB is gorgeous. Also, my PS2 doesn't want to recognize the games on my HDD. I really wanted to show screens of Gradius V and R-Type Final. Working on that. In the meantime, I'll have some pics up with Wells Gardner monitors tomorrow or so.
New prototype PCBs made it in today. I'm waiting for a Digikey order before I can fully assembled one but here's a sneak peek of the VGA hat installed.
.........and I'll do my part and let you (and everyone else) know tomorrow how well the onboard video circuit handles CRTEmu's 15khz RGBHV. I will pay particular attention to screen tearing when doing MAME testing. I expect no issues.
With the VGA hat, JAMMAizer should be able to outdo the J-Pac as a complete solution for MAME-to-arcade interfacing. And for those that might say the J-Pac has the advantage of already having buttons mapped to key strokes, that is easily solved. Someone just has to map buttons for a particular controller PCB, then share the config file with everyone else. I can certainly do that for the MC Cthulhu. Even so, mapping MAME inputs is a 5 minute activity.
Here is an idea for you to ponder @Arthrimus .......... How about a bare controller PCB that has the 2x10 pin multi-console header routed to JST NH headers and/or screw terminals for controller inputs? It would also allow for cheaper controller PCB's to be used like for MAME applications. For instance, the Zero Delay Encoder is ~$16 bucks shipped for a pair. It wouldn't be a niche accessory either. There are a heck of a lot more MAME folks out there than console-to-arcade folks. It will be useful for those pad hackers and for those guys that will use this for consoles and PC's that aren't supported by commercial multi console PCB's as well. Maybe something to consider for down the line after all the present work is done.
I am having a premonition that those Raspberry Pi guys out there would get in the mix with JAMMAizer at some point too. Maybe they'll make an accessory that leverages the VGA hat's inputs for A/V and the 2x10 header for controller inputs. If they do, the MiSTer FPGA folks wouldn't be far behind.
