[MobiusHorizons]

Undefined behavior in C or C++ is possible because the language specification is built to deal with different hardware architectures, so it's not possible to build portable code. In the case of something like NES game development, there is only one hardware target, so the actual observed hardware behavior can be relied upon when doing things that aren't explicitly documented. In this case it is possible to know before hand exactly what will happen because there is only one hardware target. Undefined behavior in a language like C is unknowable at compile time because its behavior has not been specified by the language, and it can't be specified by the hardware. Technically I guess you are correct that it is undefined behavior, but in practice it's pretty different IMO.

[codebje]

I'm not sure it's really true that the NES represents a single hardware target. There's two families of CPUs (2A03, 2A07) with different clock speeds depending on whether the device is NTSC or PAL, within each family there's a half dozen or more revisions, DRAM controller chips changed frequently causing many interesting variations in how and when the object attribute memory could be read (or not read, as the case may be).

And that's just the NES devices! The Famicoms were different again, there were at least two licensed clones, and dozens of unlicensed clones (if you, eg, wanted your game to sell in Russia, you'd care about being compatible with the Dendy as well as the genuine NES).