I love that the default Emacs scratch buffer text got into Mario Golf (GBC) somehow. I wonder if this was a mis-copy-and-paste from a developer, or if it was another case of a compiler taking random memory contents and using them for padding in the ROM...
@Raspberryfloof hee, oh gosh
grabbing random bits of ram in compilation seems hellua-insecure
then again, the only other way i could think of this going down is maybe a developer used the scratch buffer as a scratchpad, and saved it as a file?
@thingywott Possibly!
And it wouldn't be the first time I've seen random data used for ROM padding; there's always the infamous case of DynaMike for GBC...
(cw: nsfw)
@Raspberryfloof ahahahahah, what the heck??
i'm definitely leaning more towards your RAM theory now though
i mean, if i knew my compiler did that, i would sandbox it so hard! i wonder how much sensitive information has been inadvertently distributed like this?
@Raspberryfloof I'm mot familiar with the inner workings of video games, why would you want to pad a ROM instead of having it be as small as possible? This is quite interesting to me.
@Yarideki There are at least two reasons I can think of:
Physical mask ROMs only came in fixed sizes, so unless you could manage to exactly fill up whichever size ROM you were using, there would always be some room left over; and
depending on how your code was written/compiled, you might want certain parts of your ROM to have fixed addresses for where they begin, either so you know code or graphics are always at certain places, or for working around any potential hardware quirks.
@Raspberryfloof no wonder that game was so good
@Raspberryfloof my favorite GBC tidbit was that the Klax developers had the original Amiga BASIC source but couldn't get their Z80 ASM rewrite of the game logic working quite right
so they built an Amiga BASIC interpreter for GBC and ran the game logic in that
At some point I should add this to the TCRF page, along with better documentation of this game's debug mode. ^^