4 ms·

Everyone does because most games back then were written in assembly so the raw code is there on the ROM. Games written in C slow in comparison, as seen with So

Everyone does because most games back then were written in assembly so the raw code is there on the ROM. Games written in C slow in comparison, as seen with Sonic Spinball, so I’d wager Sonic 3D would have had to be assembly too given the technical achievements involved in that game. There’s some YouTube videos from various developers of that era and you can see them stepping through the assembly of those games too.

mrob 5y ago
A disassembly of the ROM is not the same as the source code because it's missing the human-readable labels for memory addresses. It's more like the source code after using an obfuscator to remove variable and function names.
- deleted 5y ago
  [deleted]
- laumars 5y ago
  Technically yes. But it’s still usable on a platform like the Mega Drive / Genesis and it’s how ROM hackers would generally work. They might still have the original code though given they wrote the game. But I wouldn’t be at all surprised if they just worked off the ROM instead.
Jetrel 5y ago
I was really surprised to discover that quite a few games in the SNES/Genesis era actually weren't written in assembly. They were usually "touched up" in assembly; there would be inlined assembly stuff for a lot of core loops and hardware interaction, but apparently quite a few games actually used "high level languages" for large tracts of the code. I'm merely relating hearsay here, but at least one primary source (Secret of Evermore) suggested this was the case. The thing is that once it's compiled down to a final rom, all the scaffolding used to build it is gone, so there's so little evidence left that it's pretty plausible for people to think it was just done completely in assembly (particularly since there's significant evidence of hand-crafted assembly routines in such a product, since they did that for parts of it). I think there's a lot of "transposing of knowledge" there, where people know how 8-bit games got built, and assume it was the same for the 16-bit era, but I suspect the 16-bit era was where the transition away from that started, so there was a bit of both.
- laumars 5y ago
  As I said, C code did exist but it was slower so it wasn’t the norm. I don’t know of any other languages being used on those systems (I think C++ was supported on the following generation of consoles, albeit SDKs took longer to be released on some consoles than others). If anyone knows of non-C languages being used I’d love to hear about it. Back then compilers weren’t as good at writing optimised machine code as they are now and the consoles of that era were built with assembly in mind anyway so it was an easier job writing assembly for them than it would be on modern architectures. That all said, it seems to be a lot more common these days (ie with the homebrew community) to use higher level languages even on easier platforms like the GameBoy.
  - ndiddy 5y ago
    The Koei strategy games on NES ran in a bytecode virtual machine. The actual game program would be written in C and compiled to the virtual machine. This allowed them to use the same codebase as the computer versions of their strategy games. As for why they use a VM rather than compiling to 6502, my guess is it saved ROM space (for example a 16 bit memory + memory add would be one instruction instead of 7) More information: https://forums.nesdev.org/viewtopic.php?f=2&t=15931 https://forums.nesdev.org/viewtopic.php?f=2&t=15931
    - laumars 5y ago
      There were a few game engine that adopted this approach (though I can mentally visualise the games, my mind has gone totally blank trying to name said engines). I wouldn’t go so far as to say it was common practice but it certainly was a technique used by a few game developers. A lot of the time is was as much down to portability as anything else. However I’m not that familiar with Koei (aside having a few titles as a gamer) to comment on their design decisions.
  - kingcharles 5y ago
    I had both the official Sega dev kit and the SN Systems one. IIRC they both came with a C compiler. I don't remember any C++ compilers for the 16-bit consoles. C++ was just coming into PC game development at that time. I was in the industry then and I definitely used some C++ code for PC game development. I once called up SN Systems as their office was down the road and asked if I could visit (this was about 1996) and they were such a nice bunch of people. They had very early prototypes of every console stacked on a back wall. Stuff that would not see the light of day for at least another 20 years. Early PlayStations, 32X, Saturns, Megadrives, Mega CDs. I was looking at a Mega CD dev station and they just handed it to me and said I could have it O_O. I think they gave us a couple of SNES and Megadrive dev kits too. They said they would have given us boxes of the things but they'd just thrown them out yesterday and the rubbish had already been collected.
kingcharles 5y ago
Having the machine code from the ROM isn't the same as having the original assembler files, even if it's close. I would over-comment my assembler just because it is an order of magnitude harder to scan over than C code. You also lose all the labels on your subroutines and jmps, all your variable names, all your data block labels.
- laumars 5y ago
  Another commenter made the same post and my reply to that is here: https://news.ycombinator.com/item?id=29815491 https://news.ycombinator.com/item?id=29815491

mrob 5y ago

A disassembly of the ROM is not the same as the source code because it's missing the human-readable labels for memory addresses. It's more like the source code after using an obfuscator to remove variable and function names.

deleted 5y ago
[deleted]
laumars 5y ago
Technically yes. But it’s still usable on a platform like the Mega Drive / Genesis and it’s how ROM hackers would generally work. They might still have the original code though given they wrote the game. But I wouldn’t be at all surprised if they just worked off the ROM instead.

Jetrel 5y ago

I was really surprised to discover that quite a few games in the SNES/Genesis era actually weren't written in assembly. They were usually "touched up" in assembly; there would be inlined assembly stuff for a lot of core loops and hardware interaction, but apparently quite a few games actually used "high level languages" for large tracts of the code. I'm merely relating hearsay here, but at least one primary source (Secret of Evermore) suggested this was the case. The thing is that once it's compiled down to a final rom, all the scaffolding used to build it is gone, so there's so little evidence left that it's pretty plausible for people to think it was just done completely in assembly (particularly since there's significant evidence of hand-crafted assembly routines in such a product, since they did that for parts of it). I think there's a lot of "transposing of knowledge" there, where people know how 8-bit games got built, and assume it was the same for the 16-bit era, but I suspect the 16-bit era was where the transition away from that started, so there was a bit of both.

laumars 5y ago
As I said, C code did exist but it was slower so it wasn’t the norm. I don’t know of any other languages being used on those systems (I think C++ was supported on the following generation of consoles, albeit SDKs took longer to be released on some consoles than others). If anyone knows of non-C languages being used I’d love to hear about it. Back then compilers weren’t as good at writing optimised machine code as they are now and the consoles of that era were built with assembly in mind anyway so it was an easier job writing assembly for them than it would be on modern architectures. That all said, it seems to be a lot more common these days (ie with the homebrew community) to use higher level languages even on easier platforms like the GameBoy.
- ndiddy 5y ago
  The Koei strategy games on NES ran in a bytecode virtual machine. The actual game program would be written in C and compiled to the virtual machine. This allowed them to use the same codebase as the computer versions of their strategy games. As for why they use a VM rather than compiling to 6502, my guess is it saved ROM space (for example a 16 bit memory + memory add would be one instruction instead of 7) More information: https://forums.nesdev.org/viewtopic.php?f=2&t=15931 https://forums.nesdev.org/viewtopic.php?f=2&t=15931
  - laumars 5y ago
    There were a few game engine that adopted this approach (though I can mentally visualise the games, my mind has gone totally blank trying to name said engines). I wouldn’t go so far as to say it was common practice but it certainly was a technique used by a few game developers. A lot of the time is was as much down to portability as anything else. However I’m not that familiar with Koei (aside having a few titles as a gamer) to comment on their design decisions.
- kingcharles 5y ago
  I had both the official Sega dev kit and the SN Systems one. IIRC they both came with a C compiler. I don't remember any C++ compilers for the 16-bit consoles. C++ was just coming into PC game development at that time. I was in the industry then and I definitely used some C++ code for PC game development. I once called up SN Systems as their office was down the road and asked if I could visit (this was about 1996) and they were such a nice bunch of people. They had very early prototypes of every console stacked on a back wall. Stuff that would not see the light of day for at least another 20 years. Early PlayStations, 32X, Saturns, Megadrives, Mega CDs. I was looking at a Mega CD dev station and they just handed it to me and said I could have it O_O. I think they gave us a couple of SNES and Megadrive dev kits too. They said they would have given us boxes of the things but they'd just thrown them out yesterday and the rubbish had already been collected.

kingcharles 5y ago

Having the machine code from the ROM isn't the same as having the original assembler files, even if it's close. I would over-comment my assembler just because it is an order of magnitude harder to scan over than C code. You also lose all the labels on your subroutines and jmps, all your variable names, all your data block labels.

laumars 5y ago
Another commenter made the same post and my reply to that is here: https://news.ycombinator.com/item?id=29815491 https://news.ycombinator.com/item?id=29815491