Kudos to @RT-55J for doing this kind of painstaking games history work, and big thanks to mkglass for telling us about the person behind the easter egg! This is awesome.
Someone on the linked Twitter thread mentioned that any documents you find from your dad’s career may be of interest to the Strong Museum of Play in Rochester, NY. I’d like to back that up, it’s a great museum and they do put a big emphasis on game history.
Stanford also does great archival work related to games. Henry Lowood would be the guy to contact there. Archivists do great work in preserving and organizing old records, exhibiting them, and making them accessible to researchers. Papers or other artifacts related to the creation of early video games could have a lot of historical value.
Did some quick and dirty investigations various games preceding Spitfire.
The Channel F built-in games have graphics for the charcters 0 though 9, G?TMX-:, and various slanted lines. I’ve done enough looking at the code in the past that I’m confident this game doesn’t have a secret message.
Also, various carts use graphics and functions from the built-in games. If those games don’t have additional letters of their own, I’m going to assume they don’t have secret messages either.
Videocart 1 is a multicart with 4 (four!) games pieces of software in it. Tic Tac Toe has a bitmap font that includes the following characters in this order:
Using that as a text table in a hex editor reveals that the game has 5 (five!) strings in a length-string format. All of the messages are used, although the -, C, and H in the font appear to be unused (in these strings, at least).
(Yes, the game really does have a 15 character blank string. It appears to use it to undraw the text.)
(Also, yes, that is the game’s real loss message.)
The other three games on the cart don’t appear to have any notable graphics of their own.
Videocart 2 reuses the Shooting Gallery game from the previous cart, and that doesn’t have anything interesting. Desert Fox only has tank and playfield graphics, so I doubt it’s hiding anything.
Videocart 3, Blackjack, has some letters:
(Yes, a bitmap of the letter T is really included in the game 4 different times.)
The graphics for cut, hit, and bet are stored separately from the rest of the graphics, and each of those words is preceded by a byte that appears to determine the word’s color. Thus, it is unlikely those letters would be referenced by a string elsewhere.
As far as the other letters, I doubt they’re used for a secret message.
The Atari 2600 was released in September of 1977, months after Spitfire, so none of its games would qualify.
The RCA Studio II, however, debuted in January 1977, which means it (probably) predates Spitfire.
Taking a quick look at some of its games, I’ve noticed two things: (1) viewing the graphics in YY-CHR still works, and (2) aside from the built-in set of games, most of the games are half or a quarter of the size of a typical Channel F game (1 kB, or even 512 bytes). Nothing immediately stands out from what I saw. Maybe somebody familiar with its assembly language would know better.
As for dedicated Pong and Pong-like systems (1st gen stuff), I doubt they’d have any secret messages able to be seen by the end user. However, I think it’s very likely for that at least one of them has something whimsical or personal etched into the silicon itself. That research, however, is outside of my purview (who wants to decap antique electronic chips?).
Beyond that, there’s still several dozen video arcade games predating the Channel F Spitfire, and quite a few mainframe/terminal-based computer games. These kinds of games are not as well-documented as home console games are, and quite a few games from this era are lost forever (as far as anybody knows). Any of those games could be hiding secrets.
In conclusion, I had Quadra-Doodle from Videocart 1 running in the background as I was writing most of this post. This is what it looked like after an hour or two:
I just want to further encourage @mkglass to reach out to some preservation experts. If digging into your dad’s past feels like a big stressor a museum might even be able to take care of some of the labor for you or boil it down to just interviewing you or something.
To give you some idea of the significance of this (if you don’t already know), almost every every video game history book or article tends to mention “the first Easter Egg” in Adventure for the Atari 2006.
This kind of thing is considered a little bit more than an oddity, because it harkens to a historical period when game designers/coders were actively told they were not allowed to “sign” their work. Easter Eggs like these are seen as the first push by game creators to acknowledge that they were doing something creative–that their work has meaning beyond a temporary novelty. As it turns out, they were right: and many smaller games are well remembered as stepping stones to the the mature medium we have today.
I don’t want to pump you up too much: Adventure is also remembered because it was a very influential game, so to most gamers (even those weird enough to really care about video game history), your dad will probably be a curious footnote or trivia question. However, we don’t know what historians might find. If someone wants to write a book about the Channel F, knowing about your dad could unlock everything. Maybe his name will help find a coworker who’s still living. Maybe we can find out exactly what was going on in those offices way back when. It would be interesting!
So yeah: I’m sure whatever firsthand access you can offer would be really interesting to the right preservationist. And if you need help making those connections some peeps on here or Reddit can likely help!
This is kind of off topic for the thread, but I have a lot of fondness for the Channel-F because as a kid I knew somebody who had one and I had no idea what it was but the concept of video games was inherently cool even if the games were really simple.
A good way to qualify the Easter Eggs, is that Adventure had the first one to be found by players while the game designer was still living; Spitfire’s similar egg was buried so deep as to be a time capsule.
Hence this comment thread.
(And yes, I’m another someone who signed up, just to post this comment. I’m not a gamer; the last game I learned was Backgammon, 7 or so years ago.)
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.
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.
Hello RT-55J sir.
I’m writing an article about Easter eggs for a Finnish retro gaming magazine Retro Rewind. This story will be featured in the article and I was wondering if I could use some of your screenshots in it?