• A quick analysis of the Pole Position cartridge and source code
  

Project Status

• Digital Archeology - An investigation of the Pole Position cartridge

• Recently, I was independently asked by two different persons if I had already taken a look at the Pole Position code, and if it possibly contained any information about the as-of-yet unknown programmer(s) of this game. I had not. But I got into an interesting conversation with one of these guys and at some point could not resist the urge to give the code a quick glance. It turned out that the code (as I had expected) does not contain any obvious hints to by whom it has been programmed. But I found another thing:
  

• There is an Easter Egg hidden inside Pole Position. And the way by which it is hidden is insanely clever!
  

• However, to say this right here at the beginning, the Easter Egg does not reveal the name of the programmer. Or does it?
  

• I have to repeat myself. This is insanely clever. I am not talking about the method how to trigger the Easter Egg. That method is only mildly crazy. But the way this is implemented and hidden inside the code is absolutely great. I will try to explain this below as best as I can.
  

• In order to trigger the Easter Egg, you must have a final score of 3330 points. Then, when the game over message is displayed, wait until the game over melody has finished, and then press buttons 2+3+4 all at the same time while also pressing the joystick to the left (pressing all buttons at exactly the same moment is a bit tricky).
  

• Then, from here on, the following screen on the right will be displayed in an endless loop:

• A lot of Vectrex games contain hidden information about the names of the respective programmers. In most cases, those names are printed to the screen by means of the Vectrex Print_Str() BIOS functions, and the names are stored as ASCII strings somewhere in the ROM. Such texts can easily be found by viewing the game ROM in a hex editor. And such texts also appear somewhere in the assembly source code in a readable format.

• My theory is that at some point GCE likely became aware of the programmers including their names in the code and possibly tried to prevent them from doing so. Therefore, the programmers had to find a way to obfuscate their credentials so that they did not appear in the code in a readable way.

• We already knew of one game where this was done. In Bedlam, the name of the programmer is stored as encrypted data in the ROM, and there is a routine which decrypts this data to RAM and then prints it to the screen (see here for more details).

• Pole Position does a similar thing. But the name (i.e. the text "THE KID") is not stored as encrypted data, but is encrypted in executable code!!!

• The Pole Position code contains a subroutine (for the sake of simplicity let us call it subroutine A) which looks completely innocent and which is repeatedly executed while the game over melody is playing. This subroutine does a lookup in the BIOS tune table and seemingly computes a note to be played, and branches to another soubroutine (let us call that one subroutine B) when the game over melody has finished. However, the notes that are computed in subroutine A are effectively not used, so subroutine A basically does nothing.

• The branching to subroutine B is done by doing two indirects jumps. Meaning: when looking at the code it is far from easy to see what code will effectively be executed next after subroutine A.

• And here it comes: subroutine B now reads the ROM part in which the code of subroutine A resides. I.e. it reads the numerical codes of the assembly instructions of subroutine A, interprets them as encrypted data, and decrypts them to ASCII letters by adding a numerical offset to the value of each instruction: The instructions of subroutine A decode to the string "THE KID".

• This is insanely clever! The programmer must have carefully tuned subroutine A to contain instructions that seem to do something reasonable, yet something that effectively does nothing, and that have numerical values which decode to "THE KID".

• Since subroutine A is obviously executed and appears to do something plausible, who would ever suspect that in fact this routine does not contain productive code but encrypted data?

• I bow to such ingenuity!!!
  

• Again, this analysis would not have been possible without Vide.
• Many thanks to Malban for his continuous support.