nesdev.org

There's a lot of nonsense going around in here regarding what could and could not be done, and what is and is not a reasonable internal architecture. The PPU sprite evaluation page, AFAIK, is tested on the real thing. Whatever you come up with should be able to produce the output it describes. Paten...

Drawing conclusions on where some chunk of memory might live in reality from the patent diagrams is not a good idea. The address register for the temp memory is just a counter that gets cleared at the start of the active line (for evaluating) and again at the start of hblank (for fetching) The "...

HLLs work with system that have a variety of hardware details by way of abstraction. The limits and architecture get abstracted to a library, or as part of the runtime, and the rest of the high level code accesses it through that. The libraries and/or runtime are usually written in lower level langu...

Correct.

Most likely it violated a trademark, which must be actively protected to retain the rights. Ergo, law-ninja strike.

The "don't try it in production code" bit was referring to the fact that random hardware IRQs shouldn't stomp on registers, or whatever you just interrupted is going to shit itself. Nothing to do with the bit 4 stuff.

Lower left center, labelled B flag, directly north of decode lines 116 and 115. Inputs are lines 105 and 106 (PHP/BRK), and D1x1, which is a lovely mess of the B flag, RDY0, phi2, /IRQ, Bxx, and the general interrupt line. That slew of lines is the data bus, usually pulled high and wired AND'd down ...

I assume you mean 32 bytes, as it should be pretty trivial to cram 32 bits into a 6-7 character password.

Metroid and Castlevania 2 cram about 200 bits into theirs I think, maybe a bit more.

OAM memory is it's own separate address space, hence the separate pair of registers used to access it.

Are you remembering to have your joypad emulation code switch to producing all 1's after the shift register empties?

Your best bet is probably to look for expected output over the serial connection, by way of hacking the test roms to output some known value to it, and running them in sequence. Graphical glitches that are not detectable by the roms are probably best handled with actual eyeball tests, possibly ones ...

They're on the same bus, there's no switching needed. It's just a matter of enabling the chips at the right time, which is what the CIRAM pins do.

Because programmers like eating.

http://www.ross.net/crc/ has plenty of details about it. The quick version is that the CRC is effectively a 1-bit operation, so when you're shortcutting things a bit by running it 8+bits at a time, the bit order matters a bunch. The inversion thing has to do with disagreements as to the exact imple...

the circuit in the zapper is supposed to be looking for a 15 KHz white, which the LCD probably isn't generating