The machine doesn't have error messages for machine code. And it would be a waste of space to code a graceful endgame state. In the larger version it changes border colour and reinitialises the board. In the smaller version, it just blows the call stack (edit: with an unexpected return value), and that is interpreted by the machine (which has no clue whether it's running BASIC or not) as the error given.
Ok interesting thanks, so Basic's error handling was basically the machines error handling. The spectrum had more of a (what would you call it? Bios?) than I thought. I didn't think there would be anything to catch and display an error, I assumed it would be more a case of just resetting. I suppose it shows just how built around Basic the spectrum was.
I should add I have only basic experience in both ZX machines. I was a kid at the time and just learning, so my memory may be dubious. But yes that's basically my understanding.
People at the time just called it "ROM or "ROM routines". There's the BASIC interpreter, but there's also a lot of useful functions you can call from assembly (like the ROM tape loader for example).
> it just blows the call stack
It seems to me this is an unintended side effect. The game code is entered using USR, which is the BASIC expression to call into assembly code [1]. A normal "ret" opcode should just return to the prompt, but apparently the game messes up some internal BASIC interpreter state, which results in this error upon return.
This isn't a Basic program, does it just use that string to save embedding text, or does it actually use Basic for some things?