Spitfire notes

I have slightly embarrassing news to share. Call it a plot twist, a technical foul, a mea culpa -- whatever it is, it's very, very interesting.

Now, I discovered this secret message using an emulator and was able to get it just fine. Took less than a day to uncover it after peeking 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 of 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.

Still, that doesn't explain what the problem. What's going on?

Let's look at the code-entry's code, in pseudo-code with the irrelevant parts removed:

[code]
set the data counter to 0x0FD0 in hexadecimal

loop
	do some stuff
	increment the data counter
repeat until the data_counter equals 0x1000 in hexadecimal

print the secret message
[/code]

Our current 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 instruction set has several instructions that use this particular register. It has instructions to set and write the value of the counter itself, as well as instructions that use the counter to read, modify, or write the places the counter is pointing to.

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.

A ROM chip is a simple device where you spit a number called an address into some wires, and then a number located at that address is spat out some other wires. Channel F carts do not contain traditional ROMs chips, as we might understand them. Instead, they use what Fairchild called "program storage units", or PSUs for short.

Fairchild's PSUs did not have address wires. Instead, they interacted with the CPU using [url=http://channelf.se/veswiki/index.php?title=ROMC]a very confusing bus protocol[/url] (that is mercifully invisible to the programmer) to arbitrate reads from the ROM tucked inside the PSU to the CPU itself. To keep track of what the address should be, the PSUs had the data counter inside them (as well as the program counter!).

("Why in the world would they make something like that?" you ask. Probably as a cost-cutting measure. As absurd as that interface is, it allowed them to make carts with fewer pins. (Also, with Fairchild being a semiconductor company, there is probably an element of vendor lock-in at work here too.))

Now, the current theory we have is that the data counter in the 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. Removing those bits from the data counter on the cart would (marginally) decrease the production costs with no harm done. Right?

The problem at hand, according to our theory, is that the data counter would never equal 0x1000. Even if you entered the code 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 -- all because those upper bits don't exist on the cart. And thus, the easter egg exists, but also doesn't.

(In theory, there could be a revision of the cart where the egg is accessible, but that is doubtful.)

The perverse thing about this all is that the easter egg was probably 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 </s>).

Thanks to emulators and multicarts not implementing this obscure, cart-specific technical limitation, the easter egg became free.