9 ms·
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. I
by derefr 5y ago
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.
IMHO that's not quite right — there's a lot of simple things Nintendo could have done to make the SNES a lot more 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 do line up (e.g. controller read-out + MMIO address) were certainly done right at the beginning.
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 single 6502 macro-assembler codebase that compiled to either a NES or SNES target. 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.
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.
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.
—————
On a separate note, I feel like it would be even simpler — and a lot more performant! — to ahead-of-time recompile 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.)
- neuronexmachina 5y agoI'm also curious about how what architectural similarities there might've been between NES/SNES and Gameboy, since there were quite a few common releases.
- einr 5y agoThe GameBoy is distinctly different from the (S)NES. It uses an 8080/Z80-ish CPU core instead of the 6502/65816, the audio and graphics hardware have different capabilities than the NES, etc. There were a lot of games that were both on the NES and the GB but they were rarely 1:1 ports for these and other reasons.
- coldacid 5y agoProbably not as many as you might assume. There's also the issue of the Game Boy running on an 8080 derivative, unlike the NES and Super NES, which ran on 6502 (and 65816) derivatives. You might be interested in these articles covering each console's architecture: * NES https://www.copetti.org/writings/consoles/nes/ https://www.copetti.org/writings/consoles/nes/ * SNES https://www.copetti.org/writings/consoles/super-nintendo/ https://www.copetti.org/writings/consoles/super-nintendo/ * Game Boy https://www.copetti.org/writings/consoles/game-boy/ https://www.copetti.org/writings/consoles/game-boy/
- truthwhisperer 5y agovery cool link
- codebolt 5y agoThe Super GameBoy comes to mind. Was it a full-fledged emulator or did it use any neat tricks to run GB code directly on the SNES?
- einr 5y agoThe Super GameBoy is essentially full GameBoy hardware in a cart, that hijacks the SNES PPU for video output and uses SNES controllers for input. There is no hardware emulation going on.
- monocasa 5y agoIt wasn't even an emulator, it was a complete gameboy SoC with the pixel stream routed to the SNES's VRAM rather than an LCD screen.
- Wowfunhappy 5y agoWhile not quite the same thing, I've read that the games in Super Mario All-Stars use basically the same assembly code as the original NES versions, just with updated graphics.
- pfranz 5y agoI'd be curious to know more about the development of Super Mario All-Stars. I've been playing both the original and All-Stars (on the Switch--if that matters) and the acceleration of Mario in SMB1 feels different. The original SMB and All-Stars were only released 8 years apart. If they didn't use the original code base they likely had access to the original dev team.
- Wowfunhappy 5y agoIt feels different because of a one-bit screwup! https://www.romhacking.net/hacks/167/ https://www.romhacking.net/hacks/167/
- Tarsul 5y agoyour link is about the behavior when Mario hits a brick whereas OP was talking about acceleration of Mario (I think he means running?!). Quite interesting link, nonetheless!
- Wowfunhappy 5y agoYes, but we often don't feel what we think we're feeling! The patch changes Mario's speed when he hits a brick, which will have implications for when he hits the ground. I'm far from an expert player, but I really think the physics are identical once the patch is in place. I sometimes wonder if it was really a mistake at the factory—something they didn't catch until 20,000 PCB's in, and didn't want to change in revisions for consistency.
- nyanpasu64 5y agoI heard that this "one-bit screwup" theory is incorrect: https://tcrf.net/Talk:Super_Mario_All-Stars#SMB1.2FLost_Levels_Brick_Physics https://tcrf.net/Talk:Super_Mario_All-Stars#SMB1.2FLost_Leve... > The actual mechanics behind the issue were discovered a while ago (the Y-reverse thing isn't right). Something to do with the block getting replaced immediately instead of a one-frame queue/delay. Unfortunately I can't find a fuller explanation for this claim.
- wk_end 5y agoI think you’d find the opposite - that NES games use lots of weird unstructured or dynamic code tricks that make automated AOT static recompilation very difficult or impossible, in most cases. These things tend to be more common on older CPUs and in hand-written assembly code, not less.
- derefr 5y agoYou're talking about this stuff: https://andrewkelley.me/post/jamulator.html#dirty-assembly-tricks https://andrewkelley.me/post/jamulator.html#dirty-assembly-t... Personally, I disagree with the author of that article's conclusion here, that the [only] "solution is to embed an interpreter runtime in the generated binary." You can statically recompile this code! You "just" need to run a concolic interpreter over the code, generating out new static instruction streams for each possible phi-node (branch) state, and then coalescing them back together where you find you've generated the same instruction stream. You can early-terminate these spec-exec paths when you find yourself back at an instruction postdominated by entirely static code [within the body of the unrolled runtime coroutine sequence]. Might sound like an unbounded exponential check, but in practice 1. merging back together will usually happen within, at most, five instructions, because these are almost always last-minute bit-packing-hacks to get code to fit within a given constrained ROM image size; and 2. there are always only two concolically-discoverable valid interpretations of a given instruction stream (if doing mid-instruction jumps), and only one concolically-discoverable valid interpretation of data-as-code / RAM-as-code. (NES games don't assemble and JIT arbitrary code streams. They don't have the work RAM for it. They're at most unpacking existing, non-arbitrary code streams; or taking something that is primarily a code stream, and then reusing it as data elsewhere, maybe a PRNG seed, or a 1-bit noise texture.) A large part of my job lately is decompiling and "reconstructing meaning" for object code compiled for lousy underspecified abstract-machine architectures. There are a lot of modern compiler-theoretic tools and tricks that can make short work of "statically" recompiling any but the hardest of hard cases. They're sadly virtually unknown outside of academia, though (probably because they're based on various graphical transformations of the code proposed after the Dragon Book was published, which is the point in history where most people in industry's knowledge of compilers seems to stop.)
- 0xcde4c3db 5y ago> 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. Runtime code generation is rare, but dynamic dispatch (i.e. "JMP indirect" through RAM), jump tables, and certain instruction-level hacks are fairly common. This can make it tricky to reliably identify all subroutines or traces [1]. [1] https://andrewkelley.me/post/jamulator.html https://andrewkelley.me/post/jamulator.html
- monocasa 5y agoWhat I think really happened is that they originally planned on it being backwards compatible, but then realized how many games depended on undocumented opcodes and bugs that had been 'fixed' in the 6502 mode of the 65816. At that point, go back to your bread boards and go nuts removing anything that was there for NES compat but was holding back the SNES in some way. A few iterations of that and you have a pretty much what an SNES was on launch. Edit: Thinking about it more, that all would also make sense given their strategy past the SNES for back compat. On the GBA they literally just have a complete GameBoy SoC on the die. It's not accessible to GBA software, is probably clock gated in GBA mode, but is there with as few changes as possible from GB hardware to run GB software. Then for the Wii, the companion ARM processor (Starlet as it's known by the Wii hackers) will go so far as to patch problematic GameCube games on load even though it's very nearly identical hardware with a few extensions. It seems like they either drop down gate for gate compat, leave a back door for themselves to get really dirty with patching, or these days just keep an emulator around that they've re-QAed each game on that they'll allow. They're very intentional with back compat in a way that feels like an ancient learned lesson internalized by the company.
- Wowfunhappy 5y agoCurious, is there a reason to think the 65816 wasn’t just a good CPU? From a supplier Nintendo had a good working relationship with? I mean, we'll never know for sure, but what was the cpu landscape like? Were the other options clearly better?
- christkv 5y agoThe Motorola 68000 is the only other one I can think off.
- phire 5y agoThis has always been my view; It's the only CPU I know about that met the requirements. Other 16bit consoles used an off-the-shelf 68000, combined with custom support chips. Nintendo made their own custom cpu silicon, an off-the-shelf soft-cpu and custom support logic for bus control and DMAs. And there simply weren't that many 16bit soft-cpus available for Nintendo to license. You couldn't license the 68000 HDL, nor the 8086 HDL.
- hypertele-Xii 5y agoThis one I presume: https://www.youtube.com/watch?v=TthFh27Mx5k https://www.youtube.com/watch?v=TthFh27Mx5k
- hnlmorg 5y agoI wouldn't have thought so. Back then version control was making copies on a floppy disk. A lot of developers didn't even have dedicated build machines let alone the fancy CI/CD pipelines we do these days. Plus most studios had pretty tight deadlines. So if they did any code sharing it would have been more like copying/pasting rather than assembly macros. In fact I wouldn't be surprised if the "copying/pasting" was literally someone printing out (to a dot matrix printer) and an office junior manually punching those instructions back in on another machine. It was a very different era back then. Tooling sucked and everything was a lot more manual. But we didn't mind as were still pushing boundaries of our imaginations and didn't know any better.
- stormbrew 5y agoI don't think this was really a practical thing and I think there'd be other signs of an attempt at if if so. The final version of the SNES PPU probably would have resembled the NES PPU more, for example, in small ways like tile sizes at the very least. There's at least one mode on the snes ppu that's kiiiinda like the nes ppu's standard behaviour but it's just off enough to make reusing code for it fairly hard I think. And then I think you'd have seen a mapper for the NES that more closely resembled the 65816's native addressing, since that would definitely have eased such porting efforts. But even the MMC5, which was first used the same year the SNES came out didn't move much in that direction. Tbh I think you're also overestimating the assemblers they used at the time as well, both in terms of the expressiveness of the macros they had available and and kind of dead code removal you might be imagining happening. I think a much simpler explanation is just that they had it in mind as a possibility from the start and they made some design choices that were both easy and would have allowed it. They may have been leaving open the possibility of an adapter cart like the genesis power base converter (which had much less work to do) too. But they also decided fairly early on that it wasn't really worth it economically and nixed it early enough that it didn't make a huge impact on the architecture.
- djur 5y agoNintendo also tends to be pretty conservative when selecting technology for new products (Gunpei Yokoi's "lateral thinking with withered technology"[1]). It's entirely possible that the similarities between the NES and SNES are that they wanted to avoid any needless innovation -- keeps costs down, makes sourcing parts easier, you already have a lot of expertise in at least some of the hardware you're using, and your developers don't need to relearn as much. Nintendo stuck with pretty similar PowerPC chips for three generations while Sony went MIPS->PowerPC->x86. And when they finally switched off of PowerPC, they went to ARM, which they'd been using for handheld systems for two decades. [1]: https://en.wikipedia.org/wiki/Gunpei_Yokoi#Lateral_Thinking_with_Withered_Technology https://en.wikipedia.org/wiki/Gunpei_Yokoi#Lateral_Thinking_...
- daneel_w 5y agoThere are no similarities between the two except for the 65816 having a 6502 compatibility mode. Everything else in the SNES is radically different because of innovation.