Trying to run Tethered with Fizmo gives the error message: “This interpreter is broken. Please use another one.”
Does anyone have any idea what Fizmo is doing that Tethered doesn’t like? It seems to be able to run other games in zblorb format, such as Savoire-Faire.
Thanks for reporting! I’ve been able to reproduce the error, and it does indeed seem to be a bug in Fizmo.
The Dialog runtime performs a couple of sanity checks at startup, to detect potential problems with the interpreter. Here, it seems that Fizmo performs unsigned comparison when the Z-machine specification calls for signed comparison.
To elaborate, signed comparison is used a lot in the Dialog runtime, because type information is stored in the upper bits of values. Inform deals with types in a different way, so most Inform games won’t run into this problem. But it should be possible to write a small test program in Inform, using an if-statement to check whether -1 is less than 1. That comparison would then come out wrong in Fizmo.
Then I’ll have to look into how hard this is to fix. I’m interested in Fizmo because I’m trying to add autosave support to Spatterlight, and Fizmo is one of the few Z-machine implementations which has this functionality already.
EDIT: On a cursory glance, Fizmo seems to do signed comparisons. At least in its jg and jl opcodes (lines 142 and 189 in mathemat.c. Or should I be looking somewhere else?
Fizmo is actively maintained, have you reported it?
Whoops, I forgot that there are two execution paths leading to that error message. As it turns out, signed comparisons work fine in fizmo. The problem is with throw/catch. These instructions aren’t used by Inform at all, as far as I know, so it must have been difficult for interpreter developers to find test cases.
This change seems to fix the problem:
diff --git a/src/interpreter/routine.c b/src/interpreter/routine.c
index 8e07ab6..2737ccc 100644
@@ -370,7 +370,7 @@ void opcode_throw(void)
- while (number_of_stack_frames > dest_stack_frame)
+ while (number_of_stack_frames >= dest_stack_frame)
set_variable(last_result_var, op, false);
I have added a clarification to your issue at the fizmo bugtracker. Sorry for the confusion.