Zapper test ROMs
Moderator: Moderators
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Zapper test ROMs
A few days ago I made these to test my zapper. Thought I'd post them in case they're useful to anyone else.
zapper_light.nes
Displays a white square in the middle of the screen. Generates 60hz buzz on any frame the zapper detects light. (Polls continually through frame until it finds light.) Trigger is irrelevant. Zapper on controller port 2.
zapper_trigger.nes
Generates 60hz buzz on any frame the trigger signals. Light is irrelevant. Zapper on controller port 2.
zapper_stream.nes
Reads the trigger once per frame and displays a stream of data on the screen. Zapper on controller port 2.
zapper_flip.nes
Same as zapper_light.nes except pulling the trigger will black the screen, in order to test black to white transitions.
I don't have a CRT. I thought I'd see if there's any hope of the zapper picking up an LCD TV but I figure it's just way too dim compared to the momentary brightness of a CRT? Maybe there are other factors. I can get a light signal by sticking it right up against a lightbulb, at least. I also managed to get a 1-frame blip by shining an LED flashlight into it, and during the moment it switches on or off I get a signal on that frame, but not while it's just shining in.
The trigger is kind of interesting. I can get a constant signal if I squeeze to a point just before the click. If I click it down, it tends to signal for a few frames then stops. I notice Duck Hunt has a software de-bounce filter about 5 frames long, which seems like a good idea.
Edit: added source code.
Edit: added zapper_stream test.
Edit: added zapper_flip test.
zapper_light.nes
Displays a white square in the middle of the screen. Generates 60hz buzz on any frame the zapper detects light. (Polls continually through frame until it finds light.) Trigger is irrelevant. Zapper on controller port 2.
zapper_trigger.nes
Generates 60hz buzz on any frame the trigger signals. Light is irrelevant. Zapper on controller port 2.
zapper_stream.nes
Reads the trigger once per frame and displays a stream of data on the screen. Zapper on controller port 2.
zapper_flip.nes
Same as zapper_light.nes except pulling the trigger will black the screen, in order to test black to white transitions.
I don't have a CRT. I thought I'd see if there's any hope of the zapper picking up an LCD TV but I figure it's just way too dim compared to the momentary brightness of a CRT? Maybe there are other factors. I can get a light signal by sticking it right up against a lightbulb, at least. I also managed to get a 1-frame blip by shining an LED flashlight into it, and during the moment it switches on or off I get a signal on that frame, but not while it's just shining in.
The trigger is kind of interesting. I can get a constant signal if I squeeze to a point just before the click. If I click it down, it tends to signal for a few frames then stops. I notice Duck Hunt has a software de-bounce filter about 5 frames long, which seems like a good idea.
Edit: added source code.
Edit: added zapper_stream test.
Edit: added zapper_flip test.
- Attachments
-
- zapper.zip
- 4 zapper test ROMs and CC65 source code.
- (13.5 KiB) Downloaded 781 times
Last edited by rainwarrior on Tue Sep 18, 2018 7:36 pm, edited 4 times in total.
-
- Posts: 260
- Joined: Mon Jan 23, 2012 11:27 pm
Re: Zapper test ROMs
That's something I noted in the zapruder(?) thread a while back. The obvious "click" when you fire the zapper is actually the end of the fire sequence. Most zapper games register the "shot" at half pull or so, when you are getting that signal. It's pretty seamless on the zapper, so most people won't notice.rainwarrior wrote:A few days ago I made these to test my zapper. Thought I'd post them in case they're useful to anyone else.
zapper_light.nes
Displays a white square in the middle of the screen. Generates 60hz buzz on any frame the zapper detects light. (Polls continually through frame until it finds light.) Trigger is irrelevant.
zapper_trigger.nes
Generates 60hz buzz on any frame the trigger signals. Light is irrelevant.
I don't have a CRT. I thought I'd see if there's any hope of the zapper picking up an LCD TV but I figure it's just way too dim compared to the momentary brightness of a CRT? Maybe there are other factors. I can get a light signal by sticking it right up against a lightbulb, at least. I also managed to get a 1-frame blip by shining an LED flashlight into it, and during the moment it switches on or off I get a signal on that frame, but not while it's just shining in.
The trigger is kind of interesting. I can get a constant signal if I squeeze to a point just before the click. If I click it down, it tends to signal for a few frames then stops. I notice Duck Hunt has a software de-bounce filter about 5 frames long, which seems like a good idea.
I figured this out after playing around with camerica's revolver style gun. The issue with that is that the trigger is again the end of the sequence, but the signal-on mechanism is the hammer. In order to actually pull the trigger you the hammer has to be cocked (it'll actually lock in that position when you pull it back) and the trigger releases the hammer. The issue is that cocking the hammer goes signal-on immediately, registering as the shot in most games. This makes it mostly impossible to play those games.
What I've learned since I posted all that is the camerica gun design is almost certainly bootlegged right of nintendo's original famicom revolver. Everything is effectively the same, but with sloppier tolerances/build quality. On the famicom revolver, pulling the trigger will actually move the hammer in stride- it doesn't have to be cocked first. That should mean it will more or less shoot at the expected time (haven't gotten around to plugging it in yet). The camerica gun's inability to pull the trigger with the hammer uncocked is apparently due to quality control rather than an intentional choice.
So anyway, I've thought about patching the zapper games to register the shot when the on signal goes to off so I could play with the camerica gun, but haven't gotten around to it.
What's a debounce filter and how does it work?
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zapper test ROMs
It just means you watch over several frames, so if you get a 0 in the middle of a stream of 1s, you ignore it. The name comes from how a lot of mechanical switches will "bounce" on and off rapidly during the moment of switching, too slow for a human to notice but a high frequency machine can often pick it up.FrankWDoom wrote:What's a debounce filter and how does it work?
More detail than you'll ever want: http://www.labbookpages.co.uk/electronics/debounce.html
Re: Zapper test ROMs
Too dim is certainly part of it. High contrast ratio and a dark room should help with that. Delay from frame to frame is another ...rainwarrior wrote:I don't have a CRT. I thought I'd see if there's any hope of the zapper picking up an LCD TV but I figure it's just way too dim compared to the momentary brightness of a CRT? Maybe there are other factors.
The demodulator inside is very strongly responsive to initial turn-on events. At one point I figured out how to use it to transmit data to the NES at about ≈1kB/sec (because a sufficiently sharp bright light source would reliably turn on the output consistently the same amount of time later), but I decided that a non-invasive means of transmitting data to the NES, when it's that slow, just wasn't useful.I can get a light signal by sticking it right up against a lightbulb, at least. I also managed to get a 1-frame blip by shining an LED flashlight into it, and during the moment it switches on or off I get a signal on that frame, but not while it's just shining in.
It's a momentary switch with a over-pull mechanism that releases the switch (the spring sound). Then after you release it, there's a simple R-C time constant (C inside the Zapper, R inside the control deck) before it reads false again.The trigger is kind of interesting. I can get a constant signal if I squeeze to a point just before the click. If I click it down, it tends to signal for a few frames then stops. I notice Duck Hunt has a software de-bounce filter about 5 frames long, which seems like a good idea.
Extra data:
viewtopic.php?t=8108
viewtopic.php?t=10138
viewtopic.php?t=11169
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zapper test ROMs
I'm confused as to how the darkness of the room would matter. I can't get any light detected from my LCD screen at any distance in a dark or light room, with its brightness/contrast as high as they go.lidnariq wrote:Too dim is certainly part of it. High contrast ratio and a dark room should help with that. Delay from frame to frame is another
Does the zapper somehow try to re-normalize to the darkest and brightest things it senses, or does it just trigger over some absolute threshold? (I presumed it was absolute.) If I put it against the light bulb it will sustain a signal for me, it seems?
Hmm. Is it edge triggered? I'm realizing the lightbulb is a type with a flourescent tube inside. Just tried with a halogen bulb and an incandescent one (neither were detected). Is the zapper specifically looking for a very sharp ride in intensity? (And if so, how long does it trigger after it gets that? Duck Hunt polls constantly until it gets a hit or the next NMI occurs, so my test does the same.)
Frame delay is not relevant to this test. The screen just displays a constant image. I started testing because I was kind of curious whether I could modify Duck Hunt with a delay to compensate for the display lag, but ultimately it proved irrelevant because it just doesn't seem to pick up the LCD screen at all.
Actually, I'd like to know if anybody else has a different experience with this. Does your zapper respond to your non-CRT TV at all?
Re: Zapper test ROMs
It is edge triggered, and it does some normalization (removing DC bias) but there are still hard limits (e.g. photodiode saturation).
The delay depends on the total amount of received energy that falls on the photodiode. As I said, a sufficiently sharply bright light source would reliably turn the sensor exactly 3 scanlines later. Normal zapper usage on the TV didn't do that, though, see also the problems that Tepples had with noise when decoding an X coordinate. BUT when I held my zapper against the CRT using his ZapRuder test, the X noise went away.
(TLDR, Too dim of a light source would produce a true signal randomly 3-4 scanlines later instead of exactly 3). also "exactly 3" is "exactly 3 time constants from the RC inside the zapper, not NES scanlines"
The delay depends on the total amount of received energy that falls on the photodiode. As I said, a sufficiently sharply bright light source would reliably turn the sensor exactly 3 scanlines later. Normal zapper usage on the TV didn't do that, though, see also the problems that Tepples had with noise when decoding an X coordinate. BUT when I held my zapper against the CRT using his ZapRuder test, the X noise went away.
(TLDR, Too dim of a light source would produce a true signal randomly 3-4 scanlines later instead of exactly 3). also "exactly 3" is "exactly 3 time constants from the RC inside the zapper, not NES scanlines"
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zapper test ROMs
So, it's more or less impossible to get useful light sensor function with an LCD TV, I suppose. I think I've learned enough to give up, at this point. Ha ha. I was hoping there was a software-only solution.
I guess if I really wanted to I could try to rebuild the zapper with a much lower frequency filter? Though, I have no idea what kind of new detection problems that would add to the situtation. It'd be interesting if there was an easy modification that wouldn't break Duck Hunt / Gumshoe / Hogan's Alley on a CRT, but would permit LCD light detection (with software modified for the frame delay).
I mean, whatever it was would break Zap Ruder, I guess, but the needs of the commercial-era games were simpler.
I guess if I really wanted to I could try to rebuild the zapper with a much lower frequency filter? Though, I have no idea what kind of new detection problems that would add to the situtation. It'd be interesting if there was an easy modification that wouldn't break Duck Hunt / Gumshoe / Hogan's Alley on a CRT, but would permit LCD light detection (with software modified for the frame delay).
I mean, whatever it was would break Zap Ruder, I guess, but the needs of the commercial-era games were simpler.
Re: Zapper test ROMs
I actually picked up the technique used in Zap Ruder's zapkernel from Operation Wolf, though not the X stuff. Operation Wolf uses a linear scan from left to right for the X coordinate.
Re: Zapper test ROMs
I'd think you'd be able to rebuild a receiver without the demodulator, and that ought to work? I'd think? It should basically be equivalent to an older lightpen or the SNES/SMD lightguns...
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zapper test ROMs
Added source code, in case anyone wanted it.
- NESHomebrew
- Formerly WhatULive4
- Posts: 418
- Joined: Fri Oct 30, 2009 4:43 am
- Contact:
Re: Zapper test ROMs
Thanks!rainwarrior wrote:Added source code, in case anyone wanted it.
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zapper test ROMs
Added a third test that just displays a stream of 0/1s read from the trigger. Useful for examining the dirty trigger behaviour, especially with slow pulls. See: viewtopic.php?f=3&t=14346&p=172494#p172494
- Jedi QuestMaster
- Posts: 688
- Joined: Thu Sep 07, 2006 1:08 pm
- Location: United States
- Contact:
-
- Posts: 775
- Joined: Mon Jul 02, 2012 7:46 am
Re: Zapper test ROMs
2 things. First of all, the demodulator. This is the #1 reason that you're not registering a hit on an LCD screen. It works very similarly to the IR transmitter in your TV remote. When you're using light, visible or otherwise, to send data, it tends to be very susceptible to noise. So, instead of, say, turning the light on for a 1, and off for a 0, you toggle the light on and off at a specific frequency to represent a 1, and off to represent a 0. Noise sources that aren't at that exact frequency get filtered out, and register as a 0. So does a solid light. Here's a good overview, if you're interested. The demodulator in the Zapper is tuned to 15kHz to match the NTSC scan rate, with the on/off signal being the result of the screen refresh. There's a bit more to it than that, getting into protocols and other aspects, but that's the really barebones, low-level issue here. If you were able to generate a 15kHz strobe light, it should register on the Zapper's light sensor. That's also probably why you were able to register off of a lightbulb, because the 60Hz flicker is an even divisor of 15kHz. It still gets filtered out, but some of the higher frequency components make it through the filter and end up registering (though that's likely why you needed to hold it up directly to the bulb, in order to get a strong enough signal through the filter). As far as whether or not this can be achieved on an LCD screen, I have no idea. Brightness/contrast/ambient light/etc are not the issue, or at least they are all secondary to the frequency component (i.e. they may cause issues in a working setup, but those are the wrong things to be looking at when trying to get this all working).
Second, the debounce. Having implemented debounce in both hardware and software, as well as HDL, by far the simplest debounce I've found is a simple shift register.
From there, there are 3 different ways to use that buffer. Fast on/delayed off, delayed on/fast off, or hysteresis.
Fast on/delayed off:
Delayed on/fast off:
Hysteresis:
Also, you can adjust the length of the debounce using a simple bitmask
Depending on the clock speed and the switch, I usually find 4 bits to be a good mask value, or at least a good starting point, and then adjust up or down from there.
That's an interesting idea, but I would suspect that at the very least you would have accuracy issues because that relies on the electron beam position to determine exactly where it's pointing. Though, I suppose with more modern technology you could compensate with more powerful sensor/image processing.lidnariq wrote:I'd think you'd be able to rebuild a receiver without the demodulator, and that ought to work? I'd think? It should basically be equivalent to an older lightpen or the SNES/SMD lightguns...
Second, the debounce. Having implemented debounce in both hardware and software, as well as HDL, by far the simplest debounce I've found is a simple shift register.
Code: Select all
debounce_buffer = (debounce_buffer << 1) | input;
Fast on/delayed off:
Code: Select all
output = (debounce_buffer == 0) ? 0 : 1;
Code: Select all
output = (debounce_buffer == 0xFF) ? 1 : 0;
Code: Select all
output = output ? ( (debounce_buffer == 0) ? 0 : 1 ) : ( (debounce_buffer == 0xFF) ? 1 : 0 );
Code: Select all
output = (debounce_buffer & mask == 0) ? 0 : 1;
Code: Select all
output = (debounce_buffer & mask == mask) ? 1 : 0;
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Zapper test ROMs
My own goal was not to support old NES software with a modern TV, but rather to write new NES software with detection routines that could be robust on modern TVs (compensation for lag, etc.), but the frequency of the filter basically made it impossible unless I want to modify the zapper.qwertymodo wrote:That's an interesting idea, but I would suspect that at the very least you would have accuracy issues because that relies on the electron beam position to determine exactly where it's pointing. Though, I suppose with more modern technology you could compensate with more powerful sensor/image processing.