I was excited to see this article. I’ve also written an emulator for the NES, although I don’t consider it “finished”, whatever that means. It’s an extremely nostalgic system to me, and its architecture is interestingly different from modern machines. There are a great many subtleties to it; personally, I focused on getting clock-cycle-accurate behavior of every opcode, which is not a self-contained thing because the bus states are visible to third-party hardware that’s part of the game cartridges. There are actually games (only unlicensed ones, I think) which rely on the retention of values on the bus due to capacitance when both sides leave it floating… I stopped short of modeling that. :)
The article is a fun and reasonable summary of the architecture at a moderate level of detail. I guess it’s meant for a younger audience who has never worked with these chips physically, and that’s perfectly fair considering what year it is. :)
I would adore seeing a followup which talks about all sorts of games which made key features rely on unintended hardware behavior.
I know that the split-screen mode in “Bigfoot” was achieved by turning the PPU off and on again mid-frame, to allow essentially two independent displays.
“Pinbot” kept the PPU powered on, but used careful cycle counting to adjust the vertical scroll position between scanlines, making the pinball table it displays appear to telescope in a pseudo-3D fashion and allowing the movement to feel much more fluid and much less constrained by the screen’s dimensions.
Routinely, most games would count scanlines to reuse the same eight entries in the sprite table for different monsters and items as the frame was drawn top-to-bottom; this is the cause of the well-known flickering behavior where having more than eight moving objects at the same vertical position makes them not all simultaneously visible.
That’s to say nothing of the hardware hacks that were bolted onto the system over time, with ever more clever memory-mapper chips being used to overcome what used to be hard limitations. This capability was intentional on Nintendo’s part, and was part of why the system was sold actively for something like eight years, although of course the state of the market had a lot to do with it as well.
There’s a lot more to be said, and this author has a good communication style. Again, I hope he writes more. :)
if you’re interested in NES development / 6502 assembly http://nesdev.com is a great resource.
I’m writing a C64 demo right now (C64 uses a 6510 processor) so much of this is familiar territory. While there is a good C compiler (for both!), you really have to drop down to ASM to get enough speed to do anything beyond basic functionality.
Yeah. :) But it’s a lot more fun than x86 asm. The smaller instruction set is a lot easier to get started in. As I guess you know!