nesdev.com

Does this count?

If you think your code might be slow, a cheap way to measure CPU usage is to use PPUMASK. At start of frame, do something that you can see (such as monochrome mode, color emphasis, masking left 8 pixels, etc), then at the end of frame, turn that off. You can count your CPU load in scanlines. But unl...

Sounds like you may be polling PPUSTATUS to check for the end of a frame? That can cause missed frames, don't do that (outside of the boot code that waits one frame).

Oh gosh, if this expects a 256 + 32K game to use the bankswitching rules of usual 256K MMC1, but with last page stuck in the second 512K, there's no way this would ever work, it would need to be redone. Real 512K cartridges use CHR ROM selection bit to determine which 256K page to select, so you can...

There is only one background color. The other background colors found among the background palettes don't actually do anything.

Meanwhile, the Game Boy Color does things the opposite way, and does not share a single background color.

The font in that screenshot isn't compressed, it just aren't aligned to a usual 16-byte boundary. Use the + or - buttons in YY-CHR to change the byte alignment.

Two bad CPUs sounds unlikely, it might be a problem on a chip or trace elsewhere.

Could the Super FX do graphics compatible with Mode 7? Maybe it would have been possible to rotate the graphics 90 degrees, so you generate horizontal lines and display them as vertical.

Something I see a lot in old console/computer repair videos is observing the address/data lines on an oscilloscope, just to see if the waveform looks "off" or not. You can sometimes tell by inspection if the square waveform doesn't look right, or has the wrong voltage range.

Watch out for writes that reset the MMC1, or writes that change the CHR banking.

Power-On state isn't actually all that consistent. On US NES, Reset state is far more consistent.

This is more of a thing for languages like C than actual assembly. Build the call tree, and allocate 'stack space'. And you will end up with multiple parallel trees once you consider Interrupt Handlers. From within your interrupt handler, anything called by that won't be using the same memory as som...

I would have called it "Stack Flattening".

If you're trying to build a call tree, your root isn't just the entry point. Every possible 'thread' (interrupt handler) becomes its own root, and then function pointers make everything more complicated.

Maybe DXROM and MMC6 should be added to MMC3 Family?