tiff_lee
Grand Master
Yeah true dunno wtf I was going on about there I even helped a guy do exactly what you said. Piggy back off the PCB to the wires for the existing sensor.
- Thread starter bobbydilley
- Start date
bobbydilley
Grand Master
I don't believe it is necessary. The Guncon 2 just needs the sync signal. It doesn't matter if it comes from composite video, the green cable from component or the s line from RGBS.
From what I read, people have had no sync related issues with the current Guncon 2 drivers for Windows 7. I plan to test it for myself soon.
A lot of the real light gun arcade games I like are either not emulated yet or not emulated very well in mame. Time Crisis 1 is passable although I would rather play the PS1 version. For TC 2, 3 , and zone, you can only play them on a PlayStation 2.
I have seen that done before but the problem is that you have to pay a lot for a used arcade TIme Crisis gun that actually works. 95% of the ones I have seen on eBay either have a broken solenoid or that infuriating "untested" description which I just assume means broken. Even the broken ones sell for $150....
So.... yes, that is an option if someone finishes the drivers for Windows 7 but I would prefer that someone offered a far cheaper shell and recoil package. I'd pay $50 for that (tops) and only if it allowed me to easily transfer over the Guncon 2 electronics without any further mods.
If I have to do a bunch of diy work like soldering or fitting the sensors, I wouldn't pay $0.01 for it as there are any number of cheap options for gun shells you have to work on.
I don't know about you guys but my list of unfinished diy retro gaming projects has grown beyond my patience (or available time).
bobbydilley
Grand Master
@Zebra Composite and VGA (RGBHV) are very different. Most people would likely want to use VGA output to some sort of monitor I think (thats what i'd do) and so getting the Horizontal and Vertical syncs (from vga) into the composite format (for the guncon2) requires some circuitry no? The yellow cable going into the guncon2 is much more than just a sync line, its doing the entire video and so I don't beleive the sync from even a component cable would do? I could be completely wrong though...
My project here is actually to make a gun setup for real hardware (Lindbergh, Naomi etc.) as the gun setups normally cost a hell of a lot of money, so thats sort of the reason behind it. I don't play any emulated light gun games myself.
Yeah they do cost alot, however broken ones are usually (if you have some technical circuitry skills) very easy to fix. All they contain is a microswitch, a solenoid (which has a little fuse inside that blows, which you can just bridge over) and a photoresistor. All of these parts can be bought really cheeply, and are a 2 minute job to replace. I've got a working pink time crisis 1 recoil gun, that I bought untested for £30 and it works a treat! (the one in the video infact).
You make a good point though, it would be much better to just find a guncon2 thats already in a recoil package (which I'm sure exist?), or just use a non recoil guncon2.
My project here is actually to make a gun setup for real hardware (Lindbergh, Naomi etc.) as the gun setups normally cost a hell of a lot of money, so thats sort of the reason behind it. I don't play any emulated light gun games myself.
Yeah they do cost alot, however broken ones are usually (if you have some technical circuitry skills) very easy to fix. All they contain is a microswitch, a solenoid (which has a little fuse inside that blows, which you can just bridge over) and a photoresistor. All of these parts can be bought really cheeply, and are a 2 minute job to replace. I've got a working pink time crisis 1 recoil gun, that I bought untested for £30 and it works a treat! (the one in the video infact).
You make a good point though, it would be much better to just find a guncon2 thats already in a recoil package (which I'm sure exist?), or just use a non recoil guncon2.
The PS2 / Guncon 2 does not require composite video. It just needs composite sync. It can take this from composite video but it also works with just the sync line from an RGBS cable.
My PS2 with Guncon2 is connected to my arcade monitor through an Ultimarc rgb cable which outputs RGBS and / or RGsB on a standard db15 (vga style) cable.
My pc is connected through an Extron rgb interface which outputs either RGBS or RGBHV on BNC connectors. The Guncon 2 would just connect to the s line. From there, you can use a BNC to vga adapter to connect to a tri-sync arcade monitor. It's no big deal.
I should point out that others have already got this working with light gun games in mame with the available drivers.
bobbydilley
Grand Master
Ah makes sense, thank you for clearing that up - so your using a Extron RGB interface to get the composite sync output!
Does your interface buffer the video at all? I’ve seen lots of people complaining it doesn’t work, and I thought that could be because of buffering?
Does your interface buffer the video at all? I’ve seen lots of people complaining it doesn’t work, and I thought that could be because of buffering?
Last edited:
For my ps2, it outputs composite sync through my Ultimarc PlayStation rgb cable which has a built in sync seperator.
For my PC, I could output composite sync natively as there is an option in the CRT EMU setup process but I left it outputting RGBHV because my arcade monitors and my Ikegami broadcast monitors can all accept both RGBS and rgbhv.
I sometimes have my Extron interface convert the seperate sync to composite but it makes little difference to the end result.
The rgb interfaces have no buffer. They just boost the signal (if needed when using long cables) and convert one type of sync to another. They are handy for this as they output on BNC connectors, giving you a convenient way to splice the sync line into your Guncon.
Using any type of upscaler or downscaler will stop a Guncon from working though. The image displayed on screen has to be the same as what the machine is outputting.
Segasonicfan
Enthusiast
@bobbydilley
I'm very interested in your project, and I've been trying to do something myself in a similar vein recently.
I could help design a board to convert the video / sync info, however:
1) I can't find a working download link for the guncon2pc, guncon2driver, or wingun software (dead links: http://forum.arcadecontrols.com/index.php?topic=37196.0)
2) I'd love to help with what you're developing, which is an Arduino version from what I can tell. This would spare people from having to sacrifice vintage working Guncon2 controllers.
Anyone else interested in this? The electronics are pretty simple, and a kit could be made that would be $50-$75, especially if the 24 V power supply was sourced separately. This would be a"poor man's" version to the (insanely awesome looking, deluxe) USB2GUN: http://www.nanotechgaming.com/optigun.php
I'm very interested in your project, and I've been trying to do something myself in a similar vein recently.
I could help design a board to convert the video / sync info, however:
1) I can't find a working download link for the guncon2pc, guncon2driver, or wingun software (dead links: http://forum.arcadecontrols.com/index.php?topic=37196.0)
2) I'd love to help with what you're developing, which is an Arduino version from what I can tell. This would spare people from having to sacrifice vintage working Guncon2 controllers.
Anyone else interested in this? The electronics are pretty simple, and a kit could be made that would be $50-$75, especially if the 24 V power supply was sourced separately. This would be a"poor man's" version to the (insanely awesome looking, deluxe) USB2GUN: http://www.nanotechgaming.com/optigun.php
Last edited:
bobbydilley
Grand Master
Hey there, glad you're interested in the project - I've not worked on it for a while due to the issue where I couldn't force the games to flash the screen white.
In essence it works like this:
- Arduino runs in a loop, and has inputs for the gun light sensor, the H SYNC and the V SYNC
- It constantly looks at the H SYNC and V SYNC lines and uses timing to see where the screen is drawing at the moment
- Every time the light sensor in the gun gets triggered, an interupt saves the H SYNC and V SYNC timings
- From this, you can calculate where the gun is pointed and convert this into a mouse pointer position using the arduino USB library
The only problem I had was how to flash the screen white - you could make the game do this, or do it in software, but I thought it would be better if the board could do it.
Would be interesting if you had any ideas,
Bobby
Segasonicfan
Enthusiast
Awesome, sounds like you made a lot of progress on this!
All CRT light guns use a photodiode, which has to absorb light to trigger a response. So there must be something going on with the screen.
Doing a little basic research, I came across this:
"The computer normally uses one of two different techniques to figure out whether or not the gun is pointed at the target when the user pulls the trigger:
- The computer blanks the screen and then paints just the target object white. If the photodiode senses darkness after one vertical retrace signal and then light after the next, the computer assumes that the gun is pointed at the target and scores a hit.
- The computer blanks the screen and then paints the entire screen white."
Rereading your post though, it looks like it might work better to "force" the screen white with the Arduino for universal compatibility. This would be doable with some low-level hardware I could design.
I think the easiest way would be to have a video input on your board, and then use a high-speed/high-bandwidth multiplexer to switch to a "dummy" all-white signal. Then of course, bus it to video out (maybe with a buffer).
I have some basic Arduino programming skills as well, and I know you can get video output from them...
bobbydilley
Grand Master
Haha, I probably only played with it for 2 hours in one evening and then gave up!
The way all modern systems work is the second option. The first one was used for really really old games like duck hunt where the CPU wasn't fast enough to process each pixel of light.
Our actual problem is not these games, but ones like Naomi light gun shooters that use an IR LED setup to detect the gun and so don't do the flashing.
I think the flashing the screen white on the board is the best way to go about it! It would have to wait until the next screen is about to be drawn, then set all the RGB outputs to full/white and then allow normal video to pass through at the next V SYNC. I suspect a normal arduino could probably do 640x480 at best, which is likely okay as most arcade games run at this. It wouldn't be doable with any sort of HD games however.
I just looked through my example, and this is unforunately the only code that is left over - very not documented and the variables don't make any sense - sorry!
https://github.com/bobbydilley/OpenGun/blob/master/LightGun/LightGun.ino
The way all modern systems work is the second option. The first one was used for really really old games like duck hunt where the CPU wasn't fast enough to process each pixel of light.
Our actual problem is not these games, but ones like Naomi light gun shooters that use an IR LED setup to detect the gun and so don't do the flashing.
I think the flashing the screen white on the board is the best way to go about it! It would have to wait until the next screen is about to be drawn, then set all the RGB outputs to full/white and then allow normal video to pass through at the next V SYNC. I suspect a normal arduino could probably do 640x480 at best, which is likely okay as most arcade games run at this. It wouldn't be doable with any sort of HD games however.
I just looked through my example, and this is unforunately the only code that is left over - very not documented and the variables don't make any sense - sorry!
https://github.com/bobbydilley/OpenGun/blob/master/LightGun/LightGun.ino
Segasonicfan
Enthusiast
Thanks for sending the code over! Yeah, a little tricky to make heads or tails of it without annotations 
also a little over my head, apparently you know your stuff!
Did you ever get this working with non-Naomi era stuff? This would be such a cool thing to have even for older CRT-based lightguns.
As long as your code can work, I don't think this sounds very complex, and would be very doable in hardware. Let me know if you'd like to spend some time on this project and I can develop a prototype PCB!
also a little over my head, apparently you know your stuff!Did you ever get this working with non-Naomi era stuff? This would be such a cool thing to have even for older CRT-based lightguns.
Awesome. Also, we might be able to get away with doing it without the Arduino outputting video. It's been a while since I messed around with R,G,B but I believe you can get a pure white screen by safely maxing out the voltage (0.7 - 1V probably) using a resistor divider and then an AC coupling capacitor. That way, the Arduino could save its cycles for the sync stuff. I can do the research on this, and also developed the 240p test PCB a while back, which could be useful for this.
As long as your code can work, I don't think this sounds very complex, and would be very doable in hardware. Let me know if you'd like to spend some time on this project and I can develop a prototype PCB!
bobbydilley
Grand Master
I didn't ever get this working full stop, as I said I only played with it for about 4 hours one evening on the Naomi and then lost interest. There isn't any reason that this shouldn't work for any game you can emulate on a computer however!
Yeah I agree, you should just be able to use a transistor or something to swap to full white. The Arduino wouldn't actually have to do anything anyway R.E outputting a white screen, it doesn't need to count pixels if it's drawing all the pixels white, and it's not producing it's own SYNC signals, just reading the ones from the machine supplying the video!
I'm unforunately not going to be able to dedicate any time to this at the moment due to work and life, but I'm happy to answer any questions you have RE the arduino side. The code should be very simple, and as long as you understand the hardware and how CRT lights gun works (which it sounds like you do) then I think you'd easily be able to learn how to code up something small like this!
Sorry that I can't commit to working on it with you as I would like to, but please keep me updated if you do decide to pursue the project - I'm sure lots of people would be interested!
Yeah I agree, you should just be able to use a transistor or something to swap to full white. The Arduino wouldn't actually have to do anything anyway R.E outputting a white screen, it doesn't need to count pixels if it's drawing all the pixels white, and it's not producing it's own SYNC signals, just reading the ones from the machine supplying the video!
I'm unforunately not going to be able to dedicate any time to this at the moment due to work and life, but I'm happy to answer any questions you have RE the arduino side. The code should be very simple, and as long as you understand the hardware and how CRT lights gun works (which it sounds like you do) then I think you'd easily be able to learn how to code up something small like this!
Sorry that I can't commit to working on it with you as I would like to, but please keep me updated if you do decide to pursue the project - I'm sure lots of people would be interested!
Segasonicfan
Enthusiast
Hey, thanks for the fast reply! And I really appreciate the offer, I'm sure I'll have some questions for you, but I'll do my best to not bother you and do necessary research on my own. I also know some programmers that would be interested in helping I think.
Happy to pick this project up where it is, and see where I can take it. I'd be really happy to get this working on a basic MAME setup. I've used an Arduino Uno before as a USB controller so Im familiar, if this is the same thing. Haven't used it as a mouse before, but I doubt it's much different. It was a bit annoying though, that the library I used in the past required an official Uno since CH340 was not supported.
Also, I think using an ESP32 will solve the processing issue. It can work with the same code and I've had a lot of success with it in designs. Also, according to the positional code notes, it would give much higher precision (0-4096 instead of 0-255)
Current questions and goals:
1. What is the benefit / use of the library atomic.h right now?
2. Is gunPowerPin just the 5V power for the gun / optic sensor? Assuming gunPin is the optical sensor line (seems that way).
( digitalWrite(gunPin, HIGH); // enable pullup resistor - this is strange, should be just a hardware pull up I think, no?)
I will also have to do some research on the difference between the the 2 and 3 pin optic sensors (EDIT: the extra pin is 5v power: http://forum.arcadecontrols.com/index.php?topic=114156.0)
3. For MAME games that already flash the screen white, will this already work "out of the box" so to speak? Sounds like it might, assuming there's a faster processor.
4. It would be wonderful to have just a C Sync support, so that I won't have to use a LM1883 if the video card does not output split sync. Shouldn't be too hard to edit the code for that or do it in hardware if absolutely necessary.
5. Once I get the library and drivers installed and everything working on a MAME setup for CRT-based gun games, I will work on the 24V solenoid support. After that, I'll focus on the MUX switching white circuit.
That's the game plan so far, let me know if there's anything I'm missing! And thanks again
Care to share how you managed this? All the links and info I can find are abandoned and dead.
and here's the code for easy access:
Last edited:
bobbydilley
Grand Master
That all sounds good to me!
1. I can't 100% remember, but I beleive that the atomic library is used so that I can update variables without them being interrupted. I'm not sure if you know about interrupts / what atomic operations are, but it would be a good thing to learn for this as it's all about speed!
2. I'd assume that pin was just power for the gun sensor, it had 5v in, GND and signal out.
3. I'd think games that already flash white should just work yeah! If you've got any strange interlacing effects going on with your mame setup though, that may cause issues so watch out for that!
4. You could add the circutry for both on your board, and then have different connectors that connect into the right parts of the circuit so you can support both!
I thought I'd write some psuedo code below, so that you know what you're trying to achieve code wise, considering my code is a bit rubbish.
time_v_in = 0
time_v_end = 0
time_h_in = 0
time_h_end = 0
when you get a H_SYNC:
time_v_in = time_v_end
time_v_end = currentTime()
when you get a V_SYNC:
time_h_in = time_h_end
time_h_end = currentTime()
when the guns light sensor goes off:
// Stop previous H_SYNC and V_SYNC intterupts going off
gun_time = currentTime()
Y = (gun_time - time_h_in) / (time_h_end - time_h_in)
X = (gun_time - time_v_in) / (time_v_end - time_v_in)
// Start interrupts again
I think this is right from thinking off the top of my head, you basically just need to work out the time between each H sync, and each V sync and then work out how far through them you are when the gun gets a flash of light.
Hope this helps!
This explains intterupts and atomic operations: https://forum.arduino.cc/index.php?topic=73838.0
General rule, if you mess with a variable that gets changed in an interrupt, you must wrap it in an atomic code block or bad things will happen.
1. I can't 100% remember, but I beleive that the atomic library is used so that I can update variables without them being interrupted. I'm not sure if you know about interrupts / what atomic operations are, but it would be a good thing to learn for this as it's all about speed!
2. I'd assume that pin was just power for the gun sensor, it had 5v in, GND and signal out.
3. I'd think games that already flash white should just work yeah! If you've got any strange interlacing effects going on with your mame setup though, that may cause issues so watch out for that!
4. You could add the circutry for both on your board, and then have different connectors that connect into the right parts of the circuit so you can support both!
I thought I'd write some psuedo code below, so that you know what you're trying to achieve code wise, considering my code is a bit rubbish.
time_v_in = 0
time_v_end = 0
time_h_in = 0
time_h_end = 0
when you get a H_SYNC:
time_v_in = time_v_end
time_v_end = currentTime()
when you get a V_SYNC:
time_h_in = time_h_end
time_h_end = currentTime()
when the guns light sensor goes off:
// Stop previous H_SYNC and V_SYNC intterupts going off
gun_time = currentTime()
Y = (gun_time - time_h_in) / (time_h_end - time_h_in)
X = (gun_time - time_v_in) / (time_v_end - time_v_in)
// Start interrupts again
I think this is right from thinking off the top of my head, you basically just need to work out the time between each H sync, and each V sync and then work out how far through them you are when the gun gets a flash of light.
Hope this helps!
This explains intterupts and atomic operations: https://forum.arduino.cc/index.php?topic=73838.0
General rule, if you mess with a variable that gets changed in an interrupt, you must wrap it in an atomic code block or bad things will happen.
Last edited:
Segasonicfan
Enthusiast
I do
since I'm using a force15khz software... I don't imagine you would know any way around this? I don't it's possible to get 15khz MAME won a CRT without some interlacing issues. Although, I think there may be settings in MAME I can tweakThat makes sense, I'll probably do that!
Thank you!! This is really helpful
Very cool! I know about interrupts, and that you're not supposed to change variables within them. I didn't realize there was a way around that, I will definitely look into it
Although this is a bit of a tangent, another way you might be able to get lichens working on your Naomi cab is this:
https://www.instructables.com/How-to-Use-a-Wiimote-as-Your-Computers-Mouse/
A little bit cumbersome to set up, but pretty cool!
another thought I have, is
1. Doing a teardown/reverse engineering pre-existing USB lightguns out there (I think there are a couple cheap ones), and
2. Getting a corded rollerball mouse or something to see if I can input X,Y coordinates to the IC somehow. Seems like we might get better performance if we use the second Arduino or second microcontroller to handle the USB protocol. What you think?
I definitely have some research to do, Ill post more updates as it comes along.
Last edited:
I do
That makes sense, I'll probably do that!
Thank you!! This is really helpful
Very cool! I know about interrupts, and that you're not supposed to change variables within them. I didn't realize there was a way around that, I will definitely look into it
Although this is a bit of a tangent, another way you might be able to get lichens working on your Naomi cab is this:
https://www.instructables.com/How-to-Use-a-Wiimote-as-Your-Computers-Mouse/
A little bit cumbersome to set up, but pretty cool!
another thought I have, is
1. Doing a teardown/reverse engineering pre-existing USB lightguns out there (I think there are a couple cheap ones), and
2. Getting a corded rollerball mouse or something to see if I can input X,Y coordinates to the IC somehow. Seems like we might get better performance if we use the second Arduino or second microcontroller to handle the USB protocol. What you think?
I definitely have some research to do, Ill post more updates as it comes along.
The best way to avoid resolution and refresh related issues with Mame (on a CRT) is to use CRTEmu drivers with Groovymame. It's free and is better than all other PC /Mame to 15khz CRT options.
When used with CRTemu drivers, groovymame automatically outputs every game in the correct native res and refresh rate by generating custom modelines on the fly (including interlaced modes when they are needed).
I used to spend more time messing around with settings and modes than I did playing when I used Soft 15khz. Groovymame does it all for you so every game looks correct by default. It's fantastic.
Old arcade games came in a wide range of obscure resolutions and refresh rates. Changing the refresh rate even a little causes all kinds of issues including screen tearing and lost effects (like shadows).
CRTemu + GM is the only emulation option that solves these issues without a whole lot of extra work..
