Romhacking.net

Romhacking => ROM Hacking Discussion => Topic started by: Metal64 on July 12, 2020, 03:27:39 am

Title: Source code fragment of "Death and Return of Superman" for sega genesis
Post by: Metal64 on July 12, 2020, 03:27:39 am
I was hacking Death and Return of Superman (USA) for sega genesis and I found this

(https://cdn.discordapp.com/attachments/570658924731039751/731735988262666250/1.jpg)
(https://cdn.discordapp.com/attachments/570658924731039751/731736018365055038/2.jpg)

It's appear to be C programming language, it's start at 0x14600 and end at 0x15600
Title: Re: Source code fragment of "Death and Return of Superman" for sega genesis
Post by: Malias on July 12, 2020, 02:48:49 pm
Have you heard of TCRF?  They have a whole bunch of stuff like this.  Looks like they even have the code you found:

https://tcrf.net/The_Death_and_Return_of_Superman_(Genesis) (https://tcrf.net/The_Death_and_Return_of_Superman_(Genesis))

Check out the site for other interesting finds.
Title: Re: Source code fragment of "Death and Return of Superman" for sega genesis
Post by: Jorpho on July 12, 2020, 07:18:43 pm
As for how the source code got there, I read some interesting speculation about that over here regarding a different game.
https://www.pagetable.com/?p=28

Quote
Imagine you’re writing a Game Boy game, and the resulting ROM with all the code and data is just a little over one megabyte in size. No big deal, just pad the game to two megabytes, and use a 2 MB ROM in the cartridge. Just tell the linker to allocate 2 MB or RAM, put the actual data at the beginning, and then write a 2 MB “.gb” image to disk, which will then be sent to the ROM chip factory.

Now imagine you’re doing this in MS-DOS. Your linker, probably written in C, calls malloc() of the runtime library of the C compiler. You already know where this is going?

While modern operating systems will always clear all malloc()ed memory, so that you cannot get to other processes’ data, this was uncommon in the single-user MS-DOS days. If you allocate 2 MB of RAM (the linker must have used a DOS extender or XMS), you’d get memory with random data in it: leftovers from whatever was in this memory before. (seppel tells me that this can also be caused by seek()ing over EOF in MS-DOS, in which case the previous data on the hard disk will be in the image.)