Home / Rainbow Islands / Game history

Rainbow Islands / GAME HISTORY

Why Can Rainbow Islands Crash at the Ending on Master System?

A misplaced stack instruction can send the European Master System game away from its ending code. The visible result depends on the setup.

By Patchlo Editorial Desk · Published October 20, 2026 · Sources checked October 20, 2026

Short answer

SMS Power researchers traced the European Master System ending problem to a stack mistake: a routine pushes a saved value twice instead of restoring it. The game can then return to the wrong address. That explains an ending failure, but not a claim that every cartridge and emulator must fail identically. [1]

Scope: European Master System Rainbow Islands and SMS Power's 2015 investigation. Arcade, NES and other ports are separate releases.

Rainbow Islands on Master System, showing the player, platforms and two curved rainbows.
European Master System gameplay, World 5 Level 1, via SMS Power. © Taito and respective rights holders. A context screenshot, not a capture of the ending crash. Image source ↗

A wrong return, not a missing ending

The 2015 investigation compared two nearby routines. One uses push ix followed by pop ix. The faulty one uses push ix twice. In plain terms, it leaves an extra saved value where the program expects the address of its next instruction. Execution can wander into RAM instead of continuing into the ending. [1]

So “the developers never made an ending” isn't the explanation. The useful question is where the program goes when it tries to get there.

Why recordings can disagree

Researchers examined how BIOS behaviour and RAM contents affected the result, and identified a difference in the Brazilian version. But a later post also found glitches in Kega Fusion despite its cleared RAM. “The BIOS clears memory, therefore the ending will work” is too neat a rule for the evidence. [1]

When comparing footage, look for the release and the machine or emulator being used. A working ending on one setup doesn't erase a failure on another. A failed ending doesn't establish that every other setup fails either.

What to check in a bug video

Keep the run and the diagnosis separate. Footage can show where play stops. A code comparison can explain why the program takes the wrong turn. You need both before attaching the same explanation to another port.

That is what makes this case worth revisiting: the fault is small enough to point to, while its on-screen result is messy enough that two players can describe different experiences without either inventing one.

Join the conversation

Have a question, correction or a different take? Share it below. Comments appear immediately after submission.

3–2,000 characters. Your name and comment will be public. Please avoid personal contact details, advertising and abuse. Comment policy & privacy

Reader comments

Loading comments…