I some news that feels slightly embarrassing for me to share. Call it a plot twist, a technical foul, a mea culpa – whatever it is, it’s interesting and unexpected.
Now, I discovered this secret message using an emulator and was able to get to it just fine. Took less than a day to uncover it after I first peeked at the file.
Other people have been able to get it to work just fine on the original hardware, but with a catch: they either had to use either a flash cart or a fan-made multicart.
So far, nobody has been able to reproduce the easter egg on the actual original cartridge.
e5frog has 11 different copies of Spitfire, between carts and loose PCBs. He has dumped every single one of them, and verified that they all have the exact same ROM, bit for bit, as the one floating around the internet. He hasn’t been able to get it to work on those carts.
What gives?
Let’s look at some simplified pseudo-code for the code entry routine:
e5frog’s theory behind the issue has to do with the data counter.
From a programmer’s perspective, the data counter seems like it would be a normal CPU register. The F8 processor’s instruction set has several instructions that use this particular register: instructions to read and write the value of the counter itself, and instructions to use it as a pointer to read, modify, and write the stuff it’s pointing at. Seems simple enough.
The problem is (this is where things get weird) the data counter is technically not a CPU register. The data counter is actually located on the cart itself.
Here’s a simple diagram showing how the relationship between the CPU and a ROM would work in a sanely, elegantly designed system (not the Channel F):
The CPU shoves a number in the address wires, and the ROM pops out whatever number was at that address through some data wires.
The Channel F’s approach is a bit different:
Fairchild made chips called PSUs, short for “Program Storage Units”. These things contain normal ROMs inside of them that work just like in the previous picture. However, between the ROM and the CPU is a blob of digital logic and registers. The CPU communicates to this blob using a very strange bus protocol, and the blob uses that protocol to do things like figure out what ROM address to read. To help with this task, that blob has registers like the data counter and even the program counter.
(Why did they design it this way? To save on money. That ROMC bus only uses 5 pins, whereas a full address bus could have used 16 (fewer pins, lower cost). Likewise, having that logic blob be on a separate chip rather than on the CPU itself (like a sensible design) drove down the cost of the CPU (as well as giving their customers some sweet, sweet vendor lock-in).)
(Also, it bears mentioning that on some carts (particularly dev carts) that that logic blob was its own chip and the ROM chips were just normal ROM chips.)
Fortunately for the programmer, these hardware-level implementation details are practically irrelevant when actually, you know, programming.
Except, of course, when they are.
Spitfire is only 2 kilobytes in size. Accounting for the 2 kilobytes that the built-in games take up (those are on their own PSU, and no I don’t understand how that works), Spitfire’s PSU only really needs to be aware of 4 kilobytes of address space, and it only takes 12 bits to address 4 kilobytes.
e5frog’s theory is that the data counter in the actual Spitfire cart is only 12 bits wide, instead of being 16-bits like the F8’s documentation says. This makes some sense, because the game is small enough that those extra 4 bits would only be used to look at empty space, which is kind of pointless. Thus, removing those extra bits there would be a harmless cost-saving measure.
The problem with that, according to our theory, is that the data counter would never equal 0x1000. Even if you entered the passcode in correctly, the data counter would get to the last digit at 0x0FFF, would increase by one, and then would end up pointing to 0x0000 instead of 0x1000, and so the code never goes on to print the secret message – all because those upper bits don’t exist on the cart. And thus the easter egg exists, but it’s trapped.
(There may exist a revision of the cart where the egg is accessible, but I doubt it.)
The perverse thing about this all is that the easter egg was most likely accessible on the carts Michael Glass used during development. In fact, I’d wager that the message becoming inaccessible was completely unintentional – no executives clamping down on workers; no co-workers ratting each other out; no self-censorship – just an absent-minded technical oversight when moving from development to production (good thing that stuff like this never happens anymore).
Thanks to emulators and multicarts not implementing this obscure, cart-specific technical limitation, the easter egg finally became free.