Seems more like voodoo.
Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they're used, etc.).
This is something someone only familiar with writing code for general purpose devices or higher level languages can't imagine. But when you're building for one very specific hardware platform you can tailor your code to that platform in ways that simply aren't possible when building for portability.
I guess I'm assuming that sloppy and buggy software didn't much become popular.
Because it was sloppy and buggy.
But also, as long as the game works on the specific hardware it was designed for then that's all that mattered, which was my point. If it reads uninitialized memory or depends on exact cycle counts or some undocumented hardware behavior then that's _fine_ if it still works on the real hardware, plenty of that was even intentionally done to achieve things otherwise impossible on that hardware.
At the same time it makes it almost impossible to verify even trivial changes to a function. Once you start accounting for all the potential state differences the answer to "does this function work the same?" will basically always be 'no' unless the code is identical. The only way to eliminate various kinds of state from being a concern is to analyze where the function is _used_, rather than just the function itself, and that's an entirely different and much harder kind of challenge.
Why would I assume that sloppy and buggy software would be less popular?
I'll have to get back to you on that one.