Had not tried with the zapper (I don't have a CRT, and when you said "trigger" i thought you just meant the in-game trigger).

Tried it now. No problems in 1 player mode, but in 2 player mode if I pull the zapper (in port 2) trigger when it's player 1's turn, I get severe graphical corruption. Looks like nametables are messed up kind of randomly, and also the CHR banking gets changed.

zapper_light.nes makes a buzz whenever the zapper is aimed at the white space (with precision) and sometimes goes off a little when I wag the lightgun at my bright, flourescent lights

zapper_trigger.nes is very interesting! The buzz goes off when the trigger is partially pulled (there is an audible click in the zapper itself), but the buzz stops when the trigger is completely pulled. (I didn't know the lightgun could do this.) Is this how the test is supposed to work?

I can't seem to find the source, but as I recall both ROMs just continually poll either the "light" or the "trigger" bit; if set it flips the value written to $4011 (buzz) and waits until the next NMI to start polling again.

Yes the trigger starts to signal on about halfway into a pull, and it turns off somewhere roughly on the "zap", and there's a lot of bounce/noise at either transition. (Slow pulls are particularly bad.)

There's also no way to distinguish half pull then release from pulling to "zap". Either way counts as a shot, generally.

Edit: I found the source, cleaned it up a little and posted it in that thread.

There was/is a glitch in most PowerPak mappers causing PPU writes during rendering (which signifies a bug in the program 99.9% of the time) to leak through to PowerPak's CHR-RAM chip. Details at viewtopic.php?f=9&t=11339.

I worked around the glitch in PowerMappers v23 (at https://kkfos.aspekt.fi/), but naturally this is something that's better fixed in the game itself.

ebfa is inside the NMI routine, specifically _flush_vram_update in neslib. The first update which loads the gun writes about 55 bytes to the nametable, which should be well below the 160 bytes recommendation even with the general overhead.

The normal frame code likewise doesn't get even close to overdoing a frame, it stays below 1/5 with occasional spikes to 1/4.