Recent Posts

BTW, just a little more info about what's going on.
I've had this Area 51 Site 4 cab for years now I bought it from a Laundramat owner after seeing it sitting in the back of the place for over six months.
I went to ask about it when I first saw it but he refused to sell it, like 6 months later in the middle of December when it had been sitting out in the weather and now covered in snow I went back and told him I'll get you $100 take it or leave it!
I went back with a buddy and took it about an hour later.
I got the game back up and running but the cab is obviously waterlogged and beyond help.
Although I got the game up and running the picture was far from good so I messed with the monitor. (HUGE mistake)
I later realized that the main issue with the picture was corrosion built up in the signal connector to the monitor, once disconnected and reconnected the picture improved 100% but by that time I F'd with so much on the monitor the picture was not like I should be!
Anyway, I believe I am correct that it is a Wells Gardner K7400 original to the dedicated cab.
And as I said I have been messing with this for some time but never really got anywhere so just forgot about it for years at a time!
Then recently I got an email from ebay telling me that there was a USB2GUN JAMMA board on auction, I bought it for $160 because why not it's only the second time I have ever seen one on ebay, I bought the first NON-JAMMA one too! (Don't hate me!)

I also own a Sharpshooter cab it's actually a Dynamo cab that is in great shape but has an older monitor, still a great looking (probably looks better than this one) but the plan is to use the WG K4700 after a cap kit and a bit of love. The Sharpshooter cab has some weird guns that I never heard of but I only paid $300 for it so whatever.
I have 4 Happ guns two on the Area51 and two I bought for parts.

So obviously this is about making a MAME cab that uses real Arcade guns.
I kept putting it on pause because I could never get to this point, but now I am here!

Currently, I am running a Lenovo M83 Tower maxed out the only thing was they supposedly had a white list for video cards so I wasn't sure if the one I got (AMD Radeon R7 350X) would even work but it did with no problem so I'm not sure if the whole Lenovo white list video card thing is BS or if I just got lucky? After that I have my VGA connected to the USB2GUN and then to an Ultimarc Video amplifier and up until tonight I wasn't sure if I was just chasing a dream but when I launched the game from command prompt the picture came up and it's only a few tweaks from PERFECT!!!! Like OMG!
It honestly looks better than if I disconnect it from the PC and put it back on the Area 51 board!!!

Anyway, I apologize for going on and on.
I'm on a Euphoric and a tad bit drunk HIGH, I have been wanting to get this far for literally years!
Now I honestly feel like I can actually take the next step to connect the guns to the USB2GUN board and give them a go.
BTW, Both USB2GUN board work fine they are recognized by windows and show up as a game controllers.
I have never played with them other than now also having them as a VGA pass through, I am surprised that the USB2GUN doesn't do the video amp Like The Ultimarc amp does but obviously it doesn't because I measured it before doing the required mod to the Ultimarc.
I actually have some test programs that were used for the Optigun so those should work since it's the same beast!
Anyway enough from me for tonight, if anyone knows what is causing the switchres issue in windows let me know!!!
Also, I am NOT Hoarding USB2GUN boards, I figured buy another since you don't know if the one you have works, I will NOT buy another and I may just sell one for around the same price I bought it.

Ok, Tonight's update.

I went through and did everything again, ran the CRT Emudriver setup to uninstall the driver, deleted the CRT Emudriver and GroovyMAME folders.
Then extracted the folders again, ran the CRT Emudriver setup and followed Calamity's 5450 guide.
Everything goes as it should then this is where the issue happens.
If I try to launch GroovyMAME in Windows I get a Switchres error about filling the screen for a second then after a few more seconds the MAME menu does appear but if I try to launch a game it crashes.
Then after looking at the guide I figured I would follow it exactly so I opened a command prompt and tried launching a game that way and BOOM It's freaking working!!!!!
So what is the issue trying to run it in windows?
The youtube link I was going off of seems to be able to do it from Windows.
Again thanks so much and if anyone has any thought about the launching from windows that would complete my Quest.

i bought new bearings with no shields to replace some extremely crusty and frozen bearings on a 3" arcade ball from ebay
they were all rusted and frozen up.
the roller was pretty rough also.
there were mud daubers in the screw holes on the bottom.
it was filthy.
but really cheap.

I got the new bearings, read here to soak in wd-40 then use a drill bit with duck tape on the tip to spin the bearings like crazy with a drill motor to loosen them up, then 3 in 1 them.
so i did that.

i also put the roller in the drill like a bit and wet sanded it smooth by spinning it while holding sand paper wrapped around it.
i started with a more aggressive grit and worked it smaller.
the shafts still had the bevel worn in from the ball but it seemed to spin smoothly and for a bit like it's supposed to once put back together.
never actually used it though to play anything.

Trying again.

Had a chance to get back to the machine and turn it on after rearranging things finally.
I pulled most of the parts out first to have a good uncluttered think on it.
The result is...



Wound up leaving the power supplies, DVG, and the Pi in the same places and swapped the HV unit and deflection board positions.

Makes for a better cooling layout, keeps those parts as far away from each other and the tube as possible and the parts still remain on the shelf I made for the stuff.

It also allowed me to turn the deflection board on its side and possibly gain a little in velocity as regards the heat being evacuated through the cooling fins.

The 120VAC fan I got is kind of noisy (and may get replaced if it is distracting once I have the bezel area built and in) but it certainly does what I wanted it to.
I drilled a hole in the shelf to allow the fan to draw from wherever it likes and gave it a good angle to shoot into but still across the heatsink.
The other bonus is I got to add a block of ply underneath the heatsink to carry the weight of it on its own.

Prior to component rearrangement and install of the fan I was seeing 185 F on the heat sink next to one of the transistors.

In that same spot the temp is now down to 95 F.
I expected a good drop in temp, but wasn't expecting one that dramatic.

Certainly worth the effort!
I'm stoked.

Audio amp should be here by the weekend I think and after that is done then it's time to start on the bezel extravaganza.

Still haven't decided if I care enough to bother sanding the cabinet again and getting a more proper coat of flatter finish paint on the outside.

Fresh

Well, for the record, i don't build them to sell as there wouldn't be any profit in it. I did make one or two spares though, so PM me and we can work something out

EDIT: Gambaman, did you PM me?

PM sent

i soak the bearings in WD40 then work them a bit, the soak them some more in some clean WD40. blow them out with compressed air, then let them dry. a drop of light machine oil on the hub part to get it behind the shield, and they spin good as new.

a few drops of the silicone spray on a paper towel rubbed over a cleaned trackball and put all back together again... works like brand new again.

My original cabinet had the same problem - control panel wasn't big enough for a normal trackball.   I ended up making the control panel bigger. 

I've got a 3" Happ trackball sitting in a box if you want me to open it up and check anything out for you.   I don't recall anything special about the bearing.   (My current cab uses a Ultimarc trackball that has a smaller footprint than the Happ trackball due to the large square top mount plate the Happ uses)

Well, again, you use CRU here which modifies and adds things to EDID. But still, even if you did, if you use RatRefresh -usecustomedid after using CRU, it will do the same as 0.11, namely only change byte 54 and 55 of the 0 value in the EDID_OVERRIDE key, and value 127 (the last one). 54 and 55 is the pixelclock in 10kHz units (reversed, because why take the easy road). Byte 127 is checksum, which must match else the value is ignored completely.

I don't have the luxury of a HDMI2 screen. I'm interested though in an export of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor instance> for that, to see if there's actually something different. For your info, if you completely reset things (remove from device manager, reboot) you can open the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor id>\Device Parameters key, there is an EDID value. If you open that, the next to last byte (ie. 126, start counting from 0) contains either 0 or 1 - 0 is no extension blocks, 1 is use extension blocks. When you use CRU to create custom resolutions, and there is an extension block active (even default counts), in the EDID_OVERRIDE key it'll create the 0 value (which is the regular EDID value) with bit 126 set to 1. And if that's 1, there will also be a registry value 1, which contains the extension blocks. When it's set to default, so far I've seen it then has value 02 03 00 00 00 00 ....... 00 and then the checksum.

So, if using extension block on a custom resolution, in EDID_OVERRIDE you'll have values 0 and 1. But I don't know where the extensionblocks would be stored when you DON'T use a custom resolution, i.e. your monitors own EDID in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\<monitor instance>\Device Parameters is still only 128bytes in total, and I've not seen another value in there. As far as others with the same question I've found, Windows only stores the first EDID block and not the extension blocks. If we need them for some monitors to work, I'll need to find a way to get them from the monitor. CRU can do it (or does it just make some extension block up?), and I have CRU's sources, so I might be able to figure that out, although it'll not be easy.

I tested just removing the detailed resolutions for the original extension block, and this seems to work. For some reason, later versions after .11 replace the original extension block with a 'Default extension block'. This seems to work to prevent issues with the monitor, but for some reason it won't let you see any other resolutions set.

Maybe I'm misunderstanding you, but isn't that exactly what we want? When I start a MAME game from my frontend, which has a certain rereshrate, it runs RatRefresh, and after disable / enable the display driver I am in that refresh rate. Without the need of manually switching to it. That's exactly the intention of the tool, to automate so your game runs at the exact speed it was intended for. It's NOT meant to add multiple resolutions with different refreshrates in order for them so show up in Windows. The deal (or at least my deal ) is to have only ONE resolution in there, so Windows HAS to use that. If you want to setup different ones, then CRU is your buddy, as that's much more versatile for that. Basically, sorry for repeating, RatRefresh changes the pixelclock (ie. byte 54 and 55) and the checksum, and stores that in the EDID_OVERRIDE value. All other options are for trying to get it to work in more configurations. But we should have the same expectation in mind else you might say 'doesn't work' but maybe it actually does

It seems the 'Default' can't be customized and there is also no way to go back to the original block, unless CRU is used to reset it. If it's possible to keep the original instead of the 'Default extension block' this might help with some of the issues from before.

The thing is the Extension block is not in registry. When you run CRU and save a resolution, it creates the EDID_OVERRIDE key and in your case has value 0 and 1, 0 beging the regular EDID block (with customized resolutions if any), and 1 with the extension block. If you remove the complete EDID_OVERRIDE key (ie, RatRefresh -remove would do that) it reverts to the original EDID, which is NEVER changed from RatRefresh. However, I have seen CRU change that, as per some procmon screenshots some posts above here. So that means, if CRU leaves the original EDID alone, removing the EDID_OVERRIDE key should reset everything back to normal.


So what I'm interested in, is a 'clean' registry export of your new monitor, after remove / reboot of everything. If possible the whole registry tree. There should be an EDID value in there. Then, use CRU and edit the default resolution, preferably only the refreshrate. Save that, and there should be a EDID_OVERRIDE key now, with values 0 and 1 (and who knows even more). I'm curious if that 1 value actually holds some data, or if it's just the default 'empty' one I've seen before. Please do an export of the whole monitor registry again, so I can also see if CRU modified your original EDID value.

You can't trust the date shown on the NMK games, we've seen multiple cases of completely different builds with the same date, and even different games with the same date.  Either they forgot to update it, or it has some other meaning like the engine date, or project start date, rather than the build date.

Likewise NMK don't seem to do anything to differentiate versions with labels.

The only real way to know is the dump them.

If Yotsuya is willing to dump some ROMs from his PCB, which ROMs are most likely to show if there is a different variant?
- a03 looks promising. (main CPU)
- a08, a09, and a10 might have something relevant. (proms)
- a01, a02, a04, a05, a06 and a07 don't look very promising for the difference noted.  (audio CPU, oki sound chips, tiles, and sprites)

921a03              0524288    maincpu
921a02              0065536    audiocpu
921a01              0131072    fgtile
921a04              2097152    bgtile
921a07              2097152    sprites
921a05              0524288    oki1
921a06              0524288    oki2
921a08              0000256    proms
921a09              0000256    proms
921a10              0000032    proms

Scott