I'm working on a Zapper test ROM that tests the photosensor, not just the trigger as in Russian Roulette. I plan to have three "kernels", or loops that measure the timing of photosensor activation:
yonoff: Determine on which scanline player 2's photosensor turns on and off. (This kernel is working, and I could start making single-player Zapper games right now if I wanted.)
yon2p: Determine on which scanlines both players' photosensors turn on. (I could get this working, but only while visiting NovaYoshi because I gave him my second Zapper to play Panesian Power.)
xyon: Determine on which scanline player 2's photosensor turns on, as well as the horizontal position of the beam to a precision of plus or minus 10 pixels or so. (I don't know if this one will ever work, but if it does, it'll allow for some heavy narrowing of targets before the hit testing phase.)
Because of the kernels' 113.667 cycle timings and the lack of a PAL NES to test with, this ROM will probably be NTSC only.
A few things I've already discovered on my Zapper + Magnavox CRT TV:
An empty controller port and an unplugged Zapper appear as a photosensor that is constantly lit up. This is because D3 is false, just as it is when the photosensor is on. So games allowing for controller hot-swapping can reliably detect when this has occurred.
If I aim the Zapper at a static white area, the photosensor stays on for about 26 scanlines. This is true regardless of distance from the TV, but it appears to narrow slightly if I aim at a not-entirely-white portion of the screen. The response time is slightly shorter than Nintendulator's 40 or so scanlines, but much longer than 2 on Nestopia or about 10 on FCEUX (which has a few bugs that I haven't pinned down).
More to come as I get more kernels and display test patterns working.
I tried the (x, y) code, which measures the timing of photosensor activation down to a resolution of about six cycles, on an NES. Emulators gave clean timings, but timings from my NES were very noisy, with a range of about six or seven measurement points. Really all I think I can discern is left, center, or right, definitely not enough for firing a missile at a given point on the screen, and probably not even enough to do any meaningful target rejection given that the sprite unit already limits how many targets can be on one scanline.
Vertical aiming, on the other hand, is as smooth as a Wii Remote, even with two guns at once.
I'm working on drawing some test patterns to see exactly what the Zapper will and won't recognize in order to better characterize its method of operation.
tepples wrote:I tried the (x, y) code, which measures the timing of photosensor activation down to a resolution of about six cycles, on an NES. Emulators gave clean timings, but timings from my NES were very noisy, with a range of about six or seven measurement points.
I wonder if that follow from the resonant 16kHz demodulator on the photodiode input? Intuitively, it feels like it would produce nonlinear results on output timing...
Cool idea. You should see if you can make a calibration tool that homebrewers could include in their projects so we don't need to pull out a CRT every time we want to play a homebrew zapper game. I can see there being a lot of interest in homebrew zapper games in the future.
You'll need either a CRT SDTV or an emulator to play a Zapper game. LCDs and upscaling CRTs don't appear to have the raster scan pattern to make it work.
I've made a menu subroutine where the player can point the Zapper at an item to move a displayed cursor there and then fire to select what's under the cursor. (The Control Pad and A Button also work.) FCEUX and Nestopia are very glitchy with this menu, but it runs fine on an NES+CRT.
The time the photosensor stays on appears to depend on the average brightness within the circular "window" around the photosensor's lens. One of my line pattern tests suggests that there might not even be a 15.7 kHz resonator on the photosensor.
tepples wrote:One of my line pattern tests suggests that there might not even be a 15.7 kHz resonator on the photosensor.
Really?? The zapper includes a sharp IR3T07, which while I can find no direct information about it, it is implied that it like the Sony CX20106A or LG GL3274 is a standard infrared demodulator IC, where the passives have been adjusted from the standard 37kHz IR frequencies down to SDTV's 16kHz carrier frequency instead. (also the photodiode from near-IR to visible light)
Also, without some kind of demodulator at either 16kHz or 60Hz, I can't figure out why it wouldn't work on a LCD TV. The LIRC guys point out that IR receivers will respond to frequencies dramatically lower or higher than the demodulator's nominal frequency given a sufficiently loud (bright) input.
Just as Abraham Zapruder's movie camera captured and recorded light from the crime scene, the Zapper light gun captures and measures light from the TV. You can download the tech demo, plug in your gun, and capture light too.
I don't really understand, but It looks like we have first Zapper test program?
Will you add X axis?(I can move "Player arrows" only with Y axis.)
But this means people will learn how to use zapper and we can see more games
So, like always, great job, tepples
Denine wrote:Will you add X axis?(I can move "Player arrows" only with Y axis.)
The third item on the menu, "X AND Y COORDS", was my attempt to add X axis. But it turns out that on NES hardware, the time of onset of the photodiode signal is too noisy to be especially useful. See "X tracking" in README.txt and "xyon" in docs/tech notes.txt. (If it's all on one line in Windows Notepad, try opening the file in your web browser, WordPad, or Notepad++.)
Today while working on the tennis game, I added support for treating the Zapper's trigger as the A button in my controller reading code. That should help simplify some game logic in games that can use either a Zapper or a standard controller.
I have 12 more steps to do before I release tennis, and when I finish one step, I split another step into two smaller steps. I'll release once I can't split any more.