ROMs
People tend to use the term ROM and its plural ROMs pretty casually. Therefore, it has come to have several meanings:
- ROM stands for Read Only Memory.
- A ROM can mean an individual computer chip.
- A ROM can mean a software file containing the programming from an individual computer chip. For our purposes, this is the meaning we will go with.
- People sometimes call a collection of all of the software files necessary for a game a ROM. For example, they will refer to their “Tron ROM.” However, this is better referred to as a set as in a “Tron set'”.
Confusing enough? To explain we need to delve a little deeper.
Contents
The History of ROMs
To actually understand what a ROM is, you need to understand a little history. Unlike PC games today, the arcade games we are talking about mostly are not software as we think of it today. These games generally did not involve floppy drives, hard drives, CDs, or DVDs. They involved computer chips that were encoded with the programming that makes up the game. These chips were Read Only Memory chips – hence, the name ROMs.
These chips were mounted onto a Printed Circuitry Board (PCB) which, in turn, was plugged into the hardware built into a cabinet. Thus, the cabinet was largely generic in terms of software, and the PCB with the ROMs loaded on it made it into a particular game. So, if you took the Donkey Kong PCB (and hence, the Donkey Kong chips) out of a Donkey Kong cabinet, and replaced it with a Galaga PCB (and hence, the Galaga chips) the cabinet would now play Galaga instead of Donkey Kong. Arcade owners really did do this, it was known as “converting” a cabinet. So as you can see, it was this collection of computer chips that made the game the game, rather than the rest of the machinery.
Sometimes it is easier to think about in terms of the early home consoles. Do you remember pulling that River Raid cartridge out of your Atari 2600 console and popping in that Adventure cartridge? Guess what was inside the cartridge? Computer chips. The 2600 was the same as the generic cabinet and the cartridge was the PCB. It was not significantly different from how a arcade cabinet worked.
Emulators and ROMs Generally
Emulators are modern software programs created to mimic the generic hardware that made up the console or was loaded into these cabinets. However, that is all that it is – generic hardware. No programming for Pac Man, Tron, River Raid, or Adventure. So in order to run a game, the emulator needs access to the programming that was encoded onto those computer chips.
This is where ROMs come in. Some members of the emulation community have developed a way to extract the programming from the original computer chips and turn them into modern software files. These modern software files usually are bundled together in one zip file per game, known as a set. This process is known as “dumping” a PCB. So when someone says that they have “dumped Tron” they are saying that they took a Tron PCB and extracted the programming from the computer chips installed on that PCB. Of course, it is actually much more difficult to get a working ROM from a PCB but we do not need to get into that here.
By the way, this process of dumping is what is so great about playing on an emulator. You are not playing a game that is similar to the original. You are actually playing the original game – line of code by line of code, it is identical.
The Files Inside (And Not Inside) A Set
When you open a set, you will notice that there are several files in there. That is because the programming necessary for a game spanned across several chips and, therefore, the original PCB for that particular game had several computer chips installed on it. When the PCB was dumped, each of those computer chips was extracted into its own file. You may wonder why we don’t combine all of those separate files into one big file for each game. Remember, emulation is about keeping the game original, and since the original game had its program broken up across all of those chips, our emulator is going to expect the program to be broken up across all of those chips.
It should also be noted that for some games, a set may not contain everything you need to run that game:
- Parent/Clone ROMs - Just keep reading. This is covered below.
- BIOS ROMs - Some games had BOIS programming that was common to all of the games that ran on a particular machine. This programming was not included on the individual game PCBs and was instead installed elsewhere in the cabinet. However, the emulator still will require both the game ROM and the BIOS ROM in order to play the game. Essentially, this is similar to the parent/child relationship discussed below and the BOIS ROMs should be saved along with the games they will support.
- Compressed Hunks of Data (CHDs) - Some more modern games did not rely solely on PCBs and ROM chips. They used hard drives, CD drives, and laserdiscs. CHDs are basically files that contain the programming that was on those hard drives, CD drives, and laserdiscs. You can find out if a particular game requires a CHD by doing a deluxe search at MAWS.
- Other Stuff - Some games had non-digital elements that were part of the game play. For example, Discs of Tron had a physical background that has been digitally emulated. Likewise, someone has emulated an audio tape (remember those?) that played music at a the end of a mission in Journey. The game may still play without this additional stuff, but it will not be exactly the same. See Also Screens, Titles & Extras.
Multiple Sets of the Same Game (Clones)
Now that you know that each set contains the files that represent a game, you are ready to learn why we have multiple sets for the same game. The main reason - they are not exactly the same game. They are slightly different. One may have the instructions in English and one in Japanese. One may be a better dump than another. One may allow adjustment of the number of lives and one may not. One may have Mario’s overalls in red, one in blue.
Remember how the PCB contained several chips, each containing some portion of the game’s programming? Well, by breaking the program down this way it was possible for the manufacturer to make slight changes to the game without replacing all of the chips on the PCB. They only had to replace one or a few.
For example, suppose that after Donkey Kong’s release the programmers decided to change Mario’s overalls from red to blue. Hypothetically, the color of Mario’s overalls may have been stored on a chip called C, while the levels were stored on another chip called A, and the music was on yet another chip called B. So the programmers change the program so that Mario now wears blue overalls, create a new chip called C-Blue, and from that point forward put chips A, B, and C-Blue on all Donkey Kong PCBs.
Then twenty five years pass and someone in Italy dumps a Donkey Kong PCB with the C chip. A year later someone in Australia dumps a Donkey Kong PCB with the C-Blue chip on it. We now have two sets both of which are for Donkey Kong, but are slightly different when you play them.
These slightly different versions of an original game are called clones. If it is a split set or a non-merged set, as discussed below, the set for each clone will have its own specific filename and the name listed in your front end may be different. For example, there are two ROMs for the game 10-Yard Fight. One, called 10yard.zip, is named "10-Yard Fight (World)" while the other, called 10yardj.zip, is named "10-Yard Fight (Japan)." Presumably, 10yardj.zip contains some code specifically developed for the game’s release in Japan.
Parent & Child ROMs and Merged, Non-Merged, and Split Sets
Having two sets which share the majority, but not all, of their programming brings us to one of the more confusing aspects of dealing with ROMs: Merged, Non-Merged, and Split sets. You see, back in the 1990s when you could only download at 56k, it was fairly tedious to download the most recent sets. Therefore, the emulation developers came up with a way to save bandwidth.
The space saving solution involved not storing the duplicative part of the programming into each and every clone set. Instead, the clone set of a game would only contain the files for those chips that differed from the original set. When an emulator loads a cloned game, the set instructs it to utilize the programming in the clone set, but otherwise utilize the programming in the original set. When sets are organized this way the original set is called the “Parent” while the clone set is called the “Child.” It is important to note that because it only contains a portion of the total program required for a game, an emulator cannot successfully load a Child set unless it can also load the Parent set.
This structure of having Parent and Child sets is called having Split sets. They are split because the programming is split between the two sets and this is the most common way to store sets. However, there is no rule that you have to do things this way.
Another option is to have Non-Merged sets. This means that both the original set and the clone set will each contain all of the programming necessary to run independently. As a result, you never have to ensure that a Parent set is present before you can play a clone set. However, you should be aware that this approach uses up the most space on your hard disk since the same files will appear in several different set.
Finally, you can choose to have Merged sets. Merged sets are exactly what they sound like. The files from the original set and the clone set are merged into a new set. [REQUEST – CAN SOMEONE PLEASE IDENTIFY THE UPSIDE AND DOWNSIDE OF MERGED SETS]
