The GameBoy CPU Manual talks about restart operations on page 116. Each of these operations push the current address onto the stack, and then jumps to a specific address (0x00, 0x08, 0x10, etc, depending on the opcode). E.g., for the 0xFF opcode, I'd jump to the address 0x38 (after pushing the current PC onto the stack).

But this makes me run in an infinite loop with a Tetris ROM... Which has a 0xFF opcode in the address 0x38. So the loop here and the overflow is pretty obvious. This is how that part of the dump looks like:

00000000  c3 0c 02 00 00 00 00 00  c3 0c 02 ff ff ff ff ff  |................|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  87 e1 5f 16 00 19 5e 23  |.........._...^#|
00000030  56 d5 e1 e9 ff ff ff ff  ff ff ff ff ff ff ff ff  |V...............|
00000040  c3 7e 01 ff ff ff ff ff  c3 be 26 ff ff ff ff ff  |.~........&.....|
00000050  c3 be 26 ff ff ff ff ff  c3 5b 00 f5 e5 d5 c5 cd  |..&......[......|
00000060  6b 00 3e 01 e0 cc c1 d1  e1 f1 d9 f0 cd ef 78 00  |k.>...........x.|

Am I misunderstanding something? Is the documentation wrong or inaccurate?

2 Answers 2


The documentation is correct.

Tetris does not use the RST 38 instruction (restart vector $38 is a custom vector, not tied to any Game Boy hardware interrupt), so the emulator I assume you're developing is calling it by mistake. It's a common error, since uninitialized/unmapped memory on the Game Boy contains $FF, which is the RST 38 opcode. Since Tetris doesn't use that reset vector, it is itself uninitialized and filled with $FF.

So the infinite loop is expected, but your initial RST 38 call is not. You should debug your program flow to see how you end up executing an $FF opcode in the first place, because you shouldn't be.

I'm not sure what you mean by "overflow", though. There's no overflow involved here. Unless you mean the eventual stack overflow (underflow) that you will encounter, of course, where the stack will eventually spill into ROM.

By the way! Trivia: Sharp LR35902 is the name of the Game Boy's SoC (system-on a chip). The CPU itself has (somewhat) recently been identified as a Sharp SM83. It was commonly used in Japanese home appliances like air conditioners and washing machines.

  • I see, many thanks for your answer. So basically if I encounter a 0xFF instruction, means that there's something wrong fetching the opcode. Many thanks. Just curious, how do you know that Tetris doesn't specifically use that instruction? I wouldn't have had figured it out by myself.
    – Julen
    Jun 7, 2020 at 21:13
  • 1
    @Julen Well, for one thing, it's obvious from the ROM dump you yourself provided, seeing as the vector in question is full of $FF :) But Tetris has been thoroughly disassembled and analyzed, and I know it pretty well. RST 38 is a non-interrupt reset vector, so any game that uses it, uses it for some custom behavior. Anyway, I'm active in several emulator development communities, and like I wrote in my answer, this is a common error. I've seen it a lot. Like here: reddit.com/r/EmuDev/comments/654co0/…
    – tobiasvl
    Jun 7, 2020 at 21:18

Am I misunderstanding something?


Is the documentation wrong or inaccurate?

Also no.

RST 38h (Opcode FFh) is simply not used within this application and thus not filled with code. Unused cells in (EP)ROM images are set to FFh by default.

The same seems to be true for restarts 2, 3 and 4 (10h/18h/20h) as well. Unused, and therefore filled with FFh.

If any of these four is called, they will get stuck in an infinite loop. All available RAM will be filled with return addresses over and over again (eventually all being 39h 00h), as well as any other addresses. But the CPU won't care, as they will never be read.

Only ROM address 38h will be fetched, followed by storing 39h and 00h at the actual SP address, SP decremented by two and setting the PC to 0038h again. There will also be no overflow detected, although SP will underflow every 32768 iterations, but again, noone cares :)

  • Can't remember. Usually those are not relevant for the main question anyway, so let's just drop it.
    – Raffzahn
    Feb 23 at 11:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .