How does the RST operation of GameBoy (SHARP LR35902) work?

Question

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?

Answer 1

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.

Answer 2

Am I misunderstanding something?

No

Is the documentation wrong or inaccurate?

As well not.

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

The same seams to be true for restarts 2/3/4 (10h/18h/20h) as well. Unused thus FFh.

If any of these 4 is called, they will get stuck in an infinite loop. All available RAM will be over and over filled with return addresses (eventually all being 39h 00h), as well as any other address. But the CPU won't care, as they are never 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 teh PC again to 0038h. There will also be no overflow detected, although SP will underflow every 32768 iterations, but again, noone cares :)