nesdev.com

Maybe try using a voltmeter or oscilloscope to see if the pins have the correct signal levels. Around 11:55 in this video, https://www.youtube.com/watch?v=N8YVX75Qr-0 (Apple IIc Repair), he uses an oscilloscope to diagnose the address and data lines. At about 14:22, there's a bad data connection see...

Getting properly formed numbers tells you a lot of about the status of the PPU. In order to get a properly formed number, the data bus must be connected correctly. Any improperly connected bit will show up as a vertical line on the screen. It also tells you that the low 3 bits of the address bus are...

Generally not a problem with your own assembly code, since you had to make everything. You can read through the listing file if you need to see if anything is out of place.

Kid Dracula should be 384kb, not 256kb? Probably an underdump of some kind.

I think the ROM Singles are mapper 0, so you can just run those for now.
Note that they test unofficial instructions too, so if you're not trying for those at the moment, you can ignore errors regarding them.

http://wiki.nesdev.com/w/index.php/Emulator_tests

Try instr_test_v5. http://blargg.8bitalley.com/nes-tests/instr_test-v5.zip

Start with the basics.

First confirm that you pass CPU tests.

Then confirm that the memory map is correct, and that when you read a byte, the correct byte is read, including page crossing and zeropage wrapping.

As fas as I know, it's not level data in CHR ROM, it's the title screen.

You can keep a symbol dependency tree if you need to. Declare that A depends on B and C, and B depends on D, etc. Much easier to do this in a language with easy hashtables.

You'd probably want to create some kind of Packet system for playing back your upcoming PPU changes. Example of how to make a VRAM writing system: * Reserve a big block of memory, maybe 128 bytes large. (Maybe use the stack page 0x100) * Write formatted data like this: High Byte of PPU Address, Low ...

I was wondering if there was any way to increase the posts per page up to something really big, so I don't have to look at separate pages of a long thread?

It's still unclear exactly what the timing is for the glitch, and what the actual behavior is. It seems to happen when "T" is changed for any reason, such as $2000 writes, or scrolling/VRAM address register writes. It seems to affect the value that is written to "V" without affecting the value of "T...

Just don't do naive fades that subtract $10 from the color value, and you won't end up writing $0D (blacker than black) to the palette.

Not only that, it's an extremely bad captcha, which won't stop any bots at all.

Probably the theme is nonfunctional after a PHPBB upgrade, until it is migrated to the new version's code.