Shin Megami Tensei for the SNES has a really cool intro sequence. I'm not talking about the spinning ATLUS letters or the the mode 7 hexagram. I'm not even talking about the creepy and foreboding scenes that interrupt the typing. I'm talking about the code.
The game's intro sequence shows a terminal-like display with seemingly random letters being typed. To the average person, these would appear as just random letters, but they're actually 65c816 mnemonics. This is SNES code being typed out. And it's not just any SNES code, it's Shin Megami Tensei's own reset routine.
The reset routine is, well, the routine run when the game is reset. For every SNES game in existence, there's a 16-bit address at
$00:FFFC that tells the CPU where to go whenever the system is reset, including power on.
There's nothing particularly special about this reset routine. It's actually pretty simple compared to another Shin game I've looked at. I just personally think it's really cool that these guys decided to expose some of the actual code used in the game for the intro.
It's not quite the exact same code. But it's pretty close, and I still want to make sure everyone appreciates it.
Below is the reset code shown in the intro sequence (left) compared to the actual code the game runs (right).
The very first line is the word "RESET" followed by a colon (:). This is used to define a label in assemblers, but, when the code is assembled, labels and their names don't actually get in. I personally have this label named "Vector_Reset", but that's okay! There's no wrong answer here! I'll give them the point.
Following that are 4 opcodes that are exactly correct:
SEt Interrupt flag. This tells the CPU to not respond to any interrupt request from the anything, except the non-maskable interrupt.
CLear Carry flag. This clears the carry flag, exactly as the name implies.
eXchange Carry and Emulation flags. Emulation? Yes. Technically, the SNES is an emulator. An emulator for what you ask? Why, the 6502 of course! When the Western Design Center created the 65c816 (the chip the SNES Ricoh 5A22 is based on), they wanted it to be backwards compatible enough that you were meant to literally just rip out the 6502 from whatever machine you were using and put the next-gen 65816 in its socket.
The newer chip has more advanced capabilities and modes of operation, but requiring configuration before it can behave as the lesser chip would make it an unsuitable replacement. So, by design, whenever a reset is triggered, the 65c816 and its variants always start in 6502 emulation mode. The processor status register only has 8 bits visible to the programmer; the 9th bit, the emulation flag, is hidden. The only way to affect the flag is to swap it with the carry flag.
CLear Decimal flag. The 6500 series is able to perform arithmetic with a more human-friendly system called "Binary Coded Decimal". Since this mode is immediately disabled, I'm not going to explain it. If you'd like to learn more, just look it up.
X16 isn't a valid opcode. Or is it? This is almost certainly an assembler specific mnemonic for exactly what I have on the right:
REP #$10, which means
ResEt Processor flags. In this case, the only flag being reset is bit 4, the index register flag also known as
X. When this flag is reset, the index registers will be in 16-bit mode.
M8 is in the same situation as above. It's not an official mnemonic, but there's no doubt that it corresponds to
SEP #$20, which means
SEt Processor flags. This time, the 5th bit (the
M flag) is being set, which puts the accumulator in 8-bit mode.
And this is where I must intervene to shame the developers. The accumulator is already in 8-bit mode. That's part of the architecture's emulation mode.
But that's not all. Even though that
REP #$10 did actually do something, it could have been combined with the
CLD just before it.
REP #$18 would have cleared both the
D flags in a single instruction.
Whatever… let's move on.
LDX #1FFFH means
LoaD X register, and the
# means immediate addressing; i.e. it will load from the address that immediately follows the opcode. In this case, that value is
#1FFFH. In our demonic computer, the suffix
H is used to indicate that a value is to be interpreted as hexadecimal. This wasn't unheard of for assemblers of the time, but it is inferior to the
$ prefix. At least if you ask me. By reading this blog, you are hereby asking me.
Transfer X to Stack pointer. The value we just loaded is what's being transfered here. This means that the top of the stack is now pointing to that value (
STore Zero to, and it's writing to some address that has been named
NMITIME. This is one letter off of
NMITIMEN, the official name given by the SNES Developers' Manual to
$4200. This address is the interrupt enable hardware register. Setting it to 0 disables NMI, tells IRQ to never trigger, and disables the auto joypad read.
But what's this? The actual opcode the game uses is an
STore Accumulator to, after using
LDA #$00, to
LoaD Accumulator with
What gives? They made their real code take more time and space than the code in their intro sequence. While it's completely inconsequential, it's still confounding. Someone was clearly aware of this slightly better code, but apparently someone else (or maybe the same guy) wanted to be a contrarian?
LDA was just described. Pay attention.
BLANKING isn't something we have the definition for, but, like the mysteries we encountered earlier, we pretty much have the answer. The value is definitely
$80, and I am willing to bet my life on it. Why? See below.
Again, you need to pay attention.
STA was just explained.
INIDSP is another register just 1 letter off of its official name in the SNES Developer Manual. So we know this is meant to be
$2100. Thus, we know that
BLANKING is the value
$80, because this would set bit 7 of
INIDISP which puts the PPU into force blank so that its registers can be used by the CPU uninhibited.
Now, out of nowhere, we have a huge chunk of code that's completely missing from the intro. Maybe it was omitted because it was boring, or maybe it wasn't written yet, but all I can do is guess. This code sets some flags and reads a signature that the game uses to check for a soft-reset. RAM decays, but if it only lacks power for a short period of time, it will stay in tact. So here, the game is looking for the phrase
programming by cozy! in Work RAM, and, if it finds it, it will skip the animated logo.
BJSR is something I have absolutely no clue about. This is not a standard mnemonic, nor can I find anything about any assembler that uses this mnemonic. Above all, it's a 4 letter mnemonic, when every other mnemonic in the 6500 family is only 3. My only guess is that this means something like
Big Jump to SubRoutine, which would be a jump to code specified by a 24-bit address. The actual mnemonic normal people use is
Jump to Subroutine Long.
The routine specified is something named
ATLUS. Appropriately enough, the routine at
$06:E04D is a subroutine that animates the spinning ATLUS letters when you first boot up the game.
I think it's safe to assume they're the same thing.
The chant at the bottom seems like complete gibberish, as if someone were speaking in tongues, but it has an actual traceable source! The Grimoire of Armadel is a book by some French guy in the 1600s, and it contains this text on page 19. The linked printing of the text contains a translation of the text, and while it isn't gibberish, it doesn't really mean anything.
Most of the words are actually Hebrew names for God. The latter lines contain Greek describing God as powerful. The agla in the final line is a Hebrew acronym meaning "God is strong forever!"
Unfortunately, no matter how hard I try, I cannot get this chant to assemble into a ROM.