Game Boy Zelda Comes With Source, Sort Of

Jamie found a fun story about a 90s Zelda Game Boy ROM that shipped with the source code- not so much on purpose, but more because the linker padded out the last meg of ROM with random memory contents, which happened to include game source code.

Avoiding the malloc()

[kcbanner]

I guess the only way to really avoid the malloc() calls grabbing your source code would have been to compile, then reboot to link...so the extra data thats padded on the end of the ROM image would just be your emtpy RAM contents.

Air Fortress (NES) had exact same issue!

[Dwedit]

Air Fortress [rustedmagick.com] (Famicom version) also included a portion of the source code due to not clearing memory before linking.

Not true

[Megane]

Now the site is Wordpressed (like Slashdotting, only the other way around) and you can't get to it, but one of the last posts before it died pointed out that this was from a trainered version. That's where someone adds cheat code to a ROM. As it turns out, the original doesn't have any of the code in question. Dissassembling for the purpose of adding cheats is a completely sensible explanation of the code that was found.

The moral of the story? Start with a known clean dump (look for the "[!]" tag) before assuming that the introns were in the original game.

Re:Avoiding the malloc()

[simcop2387]

thats what calloc is for, it'll clear it for you, malloc just gets it.

This is a non-story

[Dwedit]

This is a non-story. This only applies to a specific Pirate ROM Dump of Zelda DX. The clean dump does not contain any embedded source code.

Re:Not true

[eulernet]

Agreed.
The 'disassembled' routines are simply a filling routine with register D and a copy routine.
As a Z80 developer, you really don't need to disassemble this kind of routines.

I guess the source code parts come from the intro, and its coder was not very good either. For example: CALL/RET instead of JP or disassembling a copy routine, and keeping it called L_B000_2914.

Re:Avoiding the malloc()

[billcopc]

When you're a ROM developer, you don't think in such terms. It's all about mapping this and interleaving that.

Rather than writing the extra few lines to calculate the padding required, set up a 0-filled buffer and truncate the first (or last) buffer, rounding up the fwrite call to 2mb requires 0 extra lines.

Besides, they don't expect many people to actually look at the ROM code. This emulation craze is fairly recent.

Re:Malloc clears?

[0123456]

"What do they mean by clear the memory? Because when I malloc() (and not calloc()) I seem to get whatever was there before.."

But you don't get anything from another process. When malloc() runs out of memory and asks for a new chunk from the operating system, a modern system will usually zero the block that it returns, whereas some older operating systems (e.g. MS-DOS, I think?) would just give a pointer to a chunk of free memory which could still contain any data that the previous user had left in it; that could be any program which had previously run on the machine.

When you free something and call malloc() again afterwards, you may well get a block with old data from your program. But in most cases you won't get a block with old data from a different program.

The same applies to disk files; with some operating systems in the past you could open a file, write a byte a megabyte into the file and then read a megabyte of old data preceding it in free blocks which had been allocated to you and not cleared. That was obviously a big potential security hole, so most modern operating systems will zero all the data in the file instead (more precisely, they'll probably allocate a sparse file which will return zeros from areas which haven't been written to).

Re:Air Fortress (NES) had exact same issue!

[Indefinite, Ephemera]

There was also a chunk of code discovered in Secret of Evermore. [datacrystal.org]

Re:Avoiding the malloc()

[antime]

Malloc isn't the only culprit - some old DOS-era linkers would directly allocate disk blocks but not clear them, so whatever old content that wasn't overwritten remained in the final binary.

Re:Avoiding the malloc()

[kevmatic]

First release of Zsnes was in 1997. It was designed to run on 486es, and was written in heavily optimized ASM.
NESticle was also released in 1997. These pretty much sparked a craze, and lead to the creation of the Emulation Community and its Golden Age was pretty much in full swing by the middle of 1998.

It has pretty much died, but Zsnes is still under very active development and the new pSX Emulator has revitalized Playstation emulation since ePSXe hasn't been updated in years and leaves MUCH to be desired.

http://www.romhacking.net/ [romhacking.net] for info on ROM hacking.
http://psxemulator.gazaxian.com/ [gazaxian.com] for pSX Emulator. Try it!

Re:Mingw32 for the Advance SDK?

[tepples]

So the GameBoy Advance SDK uses MinGW32 and Newlib? Neat!

Because so does the unofficial devkitARM [devkitpro.org] used by homebrew developers on GBA and DS.

Re:Not too uncommon

[Anonymous Coward]

The BBC model B didn't have CMOS ram. The operating system ROM did have a chunk of text in the memory-mapped IO area. It read:

(C) 1981 Acorn Computers Ltd.Thanks are due to the following contributors to the development of the BBC Computer (among others too numerous to mention):- David Allen,Bob Austin,Ram Banerjee,Paul Bond,Allen Boothroyd,Cambridge,Cleartone,John Coll,John Cox,Andy Cripps,Chris Curry,6502 designers,Jeremy Dion,Tim Dobson,Joe Dunn,Paul Farrell,Ferranti,Steve Furber,Jon Gibbons,Andrew Gordon,Lawrence Hardwick,Dylan Harris,Hermann Hauser,Hitachi,Andy Hopper,ICL,Martin Jackson,Brian Jones,Chris Jordan,David King,David Kitson,Paul Kriwaczek,Computer Laboratory,Peter Miller,Arthur Norman,Glyn Phillips,Mike Prees,John Radcliffe,Wilberforce Road,Peter Robinson,Richard Russell,Kim Spence-Jones,Graham Tebby,Jon Thackray,Chris Turner,Adrian Warner,Roger Wilson,Alan Wright.

The BASIC ROM didn't have room for any extra text; the only cruft in the whole 16K is the name "Roger" in the last five bytes. The optional disk filing system ROM doesn't have any extra text either (I just checked).

I don't know what you saw, but it wasn't a standard part of the BBC micro.