Project-Nested: An NES Emulator Running on the SNES
I saw this mentioned by a YouTuber, who went on to say that many people believe that the SNES was originally intended to be backward-compatible with the NES.<p>IMHO that's not quite right — there's a lot of simple things Nintendo could have done to make the SNES a lot <i>more</i> backward-compatible with the NES, that would have had to have been done right at the beginning (and so stuck around as additional evidence of this), just as the few places that <i>do</i> line up (e.g. controller read-out + MMIO address) were certainly done right at the beginning.<p>Instead, I think what Nintendo was imagining, was that — as long as the NES and SNES were still both "alive" in the market concurrently — then companies would want to concurrently release both NES and SNES versions of their games. And, with some careful planning, development studios would be able to have a <i>single 6502 macro-assembler codebase</i> that <i>compiled</i> to either a NES or SNES <i>target</i>. Developers could either add MMIO address pokes / JSRs inside #ifdef-like macro structures; or just write two subroutines, one for NES and one for SNES, and then compile-time branch to determine which would get compiled in.<p>This makes sense of where the NES and SNES line up in compatibility, and where they diverge: they line up where there's an obvious way to support both consoles with one block of instructions; they diverge where developers would have to write separate subroutines to support the different hardware anyway, so instruction-level / memory-map-level compatibility isn't so crucial.<p>This seems so obviously "possible" (though definitely challenging!) that I've always wondered whether there are any games that are actual examples of this — where the game came out at the same time in both NES/FC and SNES/SFC releases, and binary analysis reveals that the majority of the game's engine code is shared between the two, with differences mostly in the subroutines/coroutines composing the "graphics engine", and in the static data.<p>—————<p>On a separate note, I feel like it would be even simpler — and a lot more performant! — to <i>ahead-of-time recompile</i> a NES game to run on the SNES. The NES doesn't tend to do tricks with dynamic runtime code generation, so NES games are good candidates for being statically analyzed and transpiled. (And the SNES has such a similar architecture, that even those dynamic runtime tricks might map cleanly onto the SNES, too.)