What is the relationship between solid-state ROM and inaccessible content in arcade games?

Question

I was browsing through tcrf.net, which specializes in displaying unused programming and content left in games by developers, and came across this page:

https://tcrf.net/Tank

Specifically, the following paragraph:

Tank is the first known arcade game to use solid-state ROM (in this case, a
tiny 2KB Mostek MK28000 chip) to store data. As such, it's the earliest
possible arcade game on this site and the oldest game on the site in general.

This gives me the impression that this is the first possible arcade game (possibly earliest game period) that can have unused programming because of its solid-state ROM, and by consequence a game cannot have unused content without solid-state ROM.

My question is, what is the justification for this assertion? What's special about solid-state ROM that allows it to store unused content on a machine where a machine without it could still function but be guaranteed to only store content that the player can access?

Answer 1

Excess capacity. ROM chips come in standard sizes based on powers of 2 and it is quite unlikely a particular size will be exactly what a game needs. For example, suppose a game displays numbers that are 8 x 8 pixels in size. It will need the digits from 0 to 9, each digit needs 64 bits so a ROM of 640 bits is required. That could be accommodated with a 512 bit and 128 bit ROM, but in terms of support circuitry, assembly costs and so on it likely is cheaper to use a 1024 bit ROM and not use the extra 384 bits.

Nonetheless, it is possible to have excess capacity without using ROMs. But such hand-rolled solutions will naturally avoid wasting components. Consider the arcade game Space Race. Here's a screenshot of it in action:

The game does not have a ROM. Instead, it uses a grid of wires to represent the rocketship picture and connects them wherever there is to be a white dot. You can see it this subset of the schematic:

Isn't that just wonderful? Notice how not a dot is wasted. They were even clever enough to lay down only half of the rocketship and use extra circuitry to display the mirror image of it to draw the right side of the ship.

You might ask if the score digits are stored in a wire grid. They are not. In fact, they're done by using a special-purpose chip used in handheld calculators that converts a binary number from 0 to 9 into 7 output bits that control the 7 line segments that make up the number. That binary number is sent to the chip using 4 wires which is actually 16 combinations. The game will only send combinations 0 through 9, what would happen if 10 through 15 were sent?

What, indeed? It depends on the chips used, but let's say for the sake of argument that the chip will do something useful with those numbers. Maybe light up segments that look like the letters A through F.

Aha! In that case the game has unused content! It's pretty boring unused content, but unused content nonetheless and not a ROM in sight.

Nonetheless, I think it is fair and reasonable to discount these cases. And practical, too.. ROM chips have another advantage. We can look at their contents and figure out within the context of the hardware and software what images, audio, etc. they represent. We can do that with the chips on board, but they're all special cases requiring familiarity which each individual chip and how it is connected. A much more difficult proposition and as I've mentioned before, very unlikely to yield much of interest.

Answer 2

I'm not sure of what is exactly what you are asking, but I will try:

Solid-state ROMs (and solid/state memories in general) are not built the size you desire, but they came always (afaik) with sizes that are powers of 2. This is because these memories are addressed using a binary number with N bits; with N bits you can represent 2^N memory cells, so the capacity is always a power of 2. Often, the physical layout of these memories is a square, so not every power of 2 is available. Often, the exponent of the power is required to be even. That is because it's very common to have 16k DRAMs, 64k DRAMs, and 256k DRAMs but it's much less common to find 32k or 128k DRAMs (which usually are built by recycling defective 64k and 256k DRAMs)

So although you (and the CPU) sees memory as a more or less large linear array of bytes, the actual layout is more a square, so every size is available. Only those that allow such physical layout to be designed.

But your program size does not need to be a power of 2. In fact, it's very common that the size will be any number, so when you store the program into the ROM, there will be always some unused cells.

These cells, for masked and EPROM ROMs, are simply not "programmed" (or burned) and will likely have the value $FF (all 1's because to burn a bit is to blow some kind of fuse that turns a logic-1 connection into a 0-logic connection, so non burned bits will have all the value 1)

For ROM containing boot code, OS entry points and so on, is very common to have "gaps" inside it. That is, regions with nothing more than $FF surrounded by regions with actual code and data. These gaps are the result of the OS needing to have specific code in specific addresses (like a NMI handler, jump tables, LUT tables at 256-byte boundaries to allow for fast translation, etc)

Answer 3

Another thought:

When most people refer to "unused content" in games, they're traditionally referring to UI changes. But what about unused memory addresses or the values at that memory? What about debugging information. Ideally, most debugging symbols and information would be stripped for release, but this is not always the case. Let's look at the Super Metroid memory map as an example:

7E:008D - 7E:008E    Controller 2 Input. ALL Controller 2 Unused (Debug mode)
# ...
7E:05D5 - 7E:05D6    Saved X-Scroll position ($0911). Unused (Debug mode)
7E:05D7 - 7E:05D8    Saved Y-Scroll position ($0915). Unused (Debug mode)
# ...
7E:0617 - 7E:0618    0 = allow Soft Reset via Start+Select+L+R. Unused (Debug mode)
# ...

etc.

I would say it is unlikely for a game like Space Race to include this type of information. Games that use an array of diodes have their circuitry are constructed by hand, and for production the circuits are changed to remove any unused debug logic, if they ever had any.

---

Let's look at a memory map and crash in the production version of MechWarrior for the SNES:

Ideally, this screen will never be shown in production under normal circumstances (without directly modifying the hardware and/or software), and could potentially be considered inaccessible content.

The idea of using/logging memory locations, or presenting this type of memory map to the user is a benefit of using ROM-based memory over diodes.