nesdev.com

I ran thefox's oam-decay-test.nes on my Everdrive and found the results pretty interesting. If I provide no input at all (so rendering is enabled, but OAM is not being rewritten each vblank), I lose 2 sprite tiles (tiles 48 and 56), usually at the same time, after about half a second, and then 4 mor...

Interesting. So, the wiki references this thread where thefox couldn't get OAM decay to occur on PAL, citing this as the source for having 20 safe scanlines (which was considered approximate). I don't know if that's also the source for the statements about refresh occurring everywhere but early vbla...

@Nicole/lignariq: Yeah, earlier hardware not supporting $2004 reads is an unfortunate limitation, for sure. lidnariq's sprite 0 trick is a neat workaround I hadn't thought of before. @Sour: The lag frame case I was talking about was specifically with sprite corruption I observed during lag frames wi...

That's certainly a lot more visible! I'm actually planning to do some OAM decay testing in the near future; I'd like to get an idea of how long it takes before decay occurs and how it tends to decay. Beyond just understanding it better, I'm curious if it could have utility (could it reasonably be us...

Tried out your test on Everdrive. DmcPowerOnBuzz starts up with buzzing, pressing a button silences the buzzing, and it remains silent after a reset, so seems to confirm that address is preserved across resets. I did further testing with my sample-based test and it plays the full sample normally aft...

Someone I know used to have an issue with Everdrive where sprites would mess up during lag frames in Zelda (IIRC, sprite RAM bits would get set). I believe this turned out to be a power supply issue, since the cart draws more power than is typical. During lag frames in Zelda, OAM DMA isn't performed...

Based on Eugene's results, the sample address should be initialized to $C000 and length to 1 byte, which should cause a buzzing on the C000 test. Since he tested on Everdrive, like me, I'm not sure we can trust those results. I'll do additional testing on this tonight. The test for this should be s...

I did some testing with my own test ROMs on Everdrive and suspect that its firmware writes to these registers (unless I was doing something wrong, setting the address in one ROM and switching to another did not seem to preserve it), so I can't say much about the power-on values, but it does appear t...

By testing this on real hardware via Everdrive, I believe I've been able to confirm this write behavior, and also discovered that the only emulator that seems to be getting this totally correct right now is Nintendulator 0.980. Testing this is a bit tricky because it seems that you can have timing a...

I tried to write a test that involved watching for corruption while doing repeated synced joypad reads, with the goal of identifying whether the emulator supported this method of reading. Surprisingly, despite being synced, I was encountering corruption when testing on Mesen. What I learned was that...

I think this looks really cool, and even as-is, I'd probably rather play a racing game like this than Rad Racer. It may not be the prettiest, but the gameplay could be worth it.

Nice work, and I'd love to see improvements on this.

This post by blargg indicates there is a way to detect the alignment and that he may have made a test ROM for it, though I haven't yet found evidence of such a ROM being posted. The data also shows that alignments may have different likelihoods, though I'd like to see more testing done on that to b...

I've tested how often I get each result across batches of 30 resets. I only tracked number for the first several tests, and then started tracking order, as well. I also did tests on how often I get jitter when starting up split_scroll_test_v2. Here are my results in the order I got them: (y = yes gl...

I finally got all the equipment I need to run some tests on my NTSC frontloader via Everdrive. Here are some results. ppu_2005_glitch.nes & ppu_2406_glitch.nes After many resets, I can confirm that the $2005 and $2406 tests do indeed show the glitching that lidnariq predicted for some (but not all) ...

If you want to know when an address is read by some code, use a read breakpoint. If you want to know when it's written to by some code, set a write breakpoint. If you want to know when it's executed as code by the CPU, set an execute breakpoint. If you really don't know, then use all 3; they're not ...