Why would older video games include fragments of source code?

Question

One thing that was surprisingly common in older video games (around the same era assembly language was king) was the inclusion of uncompiled, plaintext source code in the ROM. You can see many examples of this here.

My question is...why? It doesn't make much sense for a variety of reasons:

1. The source code is not usable by the machine in any way, and is not pointed to by any part of executable code.

2. I figured it could be used for padding an EPROM when writing it during testing, but wouldn't it be trivial to just use a sequence of zeroes?

3. A bug/error in the assembly process. I've used assemblers before and it doesn't quite make sense to me how it could include the source it's reading by mistake unless the assembler tools were heroically bad.

4. Another thing that crossed my mind is deliberate inclusion, either by disgruntled employees or as an easter egg. But almost nobody of the era could actually see it without a ROM dumper, which wasn't exactly a common household item. Additionally, even if the intention were to surreptitiously release the source, very seldom was enough code included to actually rebuild the game.

Was there any technical or other reason that source code would end up in a game ROM?

Answer 1

I'd guess a lot of the systems used for development didn't clean the memory down in between usages. It's also likely that for games "gaps" got left between binary chunks. So if for a hypothetical system redefined characters had to start on a multiple of 256 (0x100) byte boundaries the memory layout might have looked like this:

0x0000 - 0x1789 - Compiled code
0x178a - 0x1800 - Whatever was in memory
0x1800 - 0x2000 - 256*8 byte redefined characters

So unless someone explicitly set the chunk between 0x178a & 0x1800 to be a value you might see some left over source code.

Answer 2

I don't know if this applies in every case, but, on the Commodore PET and by extension C64, an executable program file on disk/tape consisted of a load address (normally $0401 on the PET) and then literally a memory dump of the the region of RAM containing the program. The normal save routine would save all the memory until it got to the end of the BASIC program.

Most games were written in assembler but to load and run them the executable on disk/tape would be a memory dump of a one line BASIC program followed by the assembled machine code. The one line BASIC program would just call the machine code, using a SYS command.

Because you had all that machine code after the BASIC program you couldn't just use the default save routine because it would stop at the end of the BASIC, so you told it to save a block of memory. If you didn't get the size of it right (your block was too big) or there were gaps (e.g. between the end of the BASIC and start of the machine code) whatever garbage happened to be there would also get saved. These machines had no virtual memory, so the garbage that happened to be there had a good chance of being part of the source code you might have been working on in your assembler just before saving.

Answer 3

The page you linked on The Cutting Room Floor offers its own explanation:

Sometimes this is to pad out a disc or ROM to fill any empty space, other times it's just funky compiler behavior...

"Funky compiler behaviour" is the most likely explanation for the older games. More specifically, as explained in Muzer's comment, it's likely because memory was reused without erasing it first or completely overwriting it with new data. One can imagine this resulting in source code ending up in a game in one of two ways. Either a compiler/assembler that ends up reusing part of its own memory for both storing the source code input and the machine code output, or a linker that ends up using memory previously used by a compiler/assembler.

The first case case could happen in a scenario something like the following:

1. The program allocates an input buffer
2. The source code is read into the input buffer
3. The source code is converted into a parse tree or some other intermediate representation
4. The input buffer is freed
5. The program allocates an output buffer which happens to overlap the the location in memory where the input buffer was
6. The program converts the intermediate representation to machine code and stores it in the output buffer
7. The entire output buffer is written out

If the output buffer isn't cleared in step 5 or entirely overwritten in step 6 it could end up containing part of the source code read into memory in step 2.

Older single-user operating systems like MS-DOS didn't (and/or couldn't) provide any sort of real process isolation and there's was no security to speak of. While a modern multitasking OS will erase any memory it provides to a process so it can't see any data that might have been stored there by other processes, these older OS'es didn't do that. So the second case mentioned above could happen in a scenario like the following:

1. The compiler/assembler allocates space for an input buffer
2. The source code is read into the input buffer
3. The source code is compiled/assembled into an object file
4. The compiler/assembler exits
5. The linker allocates space for an output buffer which happens to overlap the location in memory where the compiler/assembler allocated the input buffer
6. The game's object files are linked together and stored in the output buffer
7. The entire output buffer is written out

Again, if the output buffer isn't cleared in step 5 or entirely overwritten in step 6 it could end up containing part of the source code read into memory in step 2.

This later scenario is probably more likely, at least for anything other than the earliest of games. The program is only likely to write an entire buffer regardless of how much of that buffer was used when the output needs to be a certain size like when creating a ROM image. A smaller game might use assembler that produces the ROM image directly, but bigger games are more likely to use separate compilation and produce the ROM image using a linker.

Padding out a disc or ROM is a much less likely explanation, though you see something similar in the newer games listed on that The Cutting Room Floor page. Instead of explicit padding, or even actual game source code, you often see build scripts and build configuration files included in games. These are files that happened to be in the build output directory for use by the game's build process but aren't actually needed at runtime by the game itself. They end up being included in the game because the entire build output directory ends being included in the game's disc (or flash cart) file system. Essentially they turn that entire directory into an ISO and use it as the image they send to manufacturing.

Answer 4

There are many reasons why a program might be written to include unspecified data, including:

• if the platform utilises any sort of paging, each individual page may need to be self-enclosed as the machine will have visibility of only a subset at a time, often implying unused space at the end of pages;
• if the platform was also the development machine, using all available RAM for object code implies no room for both object and source code; therefore source code may need to be assembled in chunks, each with a fixed start address (either because it's programmer specified like a ORG $4000, or because the working environment would make reassembling all files for every edit infeasible, so the assembler applies some other fixed scheme), so that when glued together gaps are left;
• some CPUs may prefer certain data alignments (e.g. with 6502 lookup tables, it's usually faster not to overflow a page) so an appropriately directed assembler may be asked to skip certain output addresses (e.g. with the 6502, to move directly to the beginning of the next page).

If the assembler is told "I don't care what's at address N" then it is legitimate not specifically to put anything there. It is also likely, since it is faster. Therefore whatever was in memory before may linger. Which is likely to be source code.