intfiction.org

Effectively the only Z-Machine extension to ever gain traction was the introduction of the unicode opcodes. The 1.1 proposal wasn't ever fully ratified, possibly in part because there was no way to detect the new opcodes other than by checking whether the VM set the version to 1.1, which it couldn't do unless it fully implemented the new spec. There was no way to partially implement the proposal.

I suggest that we introduce a feature testing function, ie, a gestalt opcode. It would have the same syntax as Glulx's @gestalt, and an opcode number of EXT:127: @"EXT:127S". Opcodes EXT:128-255 would then be available for further extensions.

But, how can we detect whether this gestalt opcode will exist or not?

Following David Kinder's suggestion we will set the VM interpreter number to 20, but only for games with a serial number of 100000-820000 (ie, from 2010 until 2082, when serial numbers will start overlapping with the original infocom ones.) This means that old games which actually cared about interpreter numbers will not run the risk of getting confused.

Now, I just need to decide where a good place for a registry of gestalt selectors and new opcodes should be. I'll be taking submissions and will be happy to assign codes to those with reasonable extension proposals.

I intend to implement this in Gnusto. I hope other VM maintainers will get on board too.

Edit: The draft proposal has been posted at http://curiousdannii.github.com/if/zspec12.html

The 1.1 specification did tail off rather, but (after some pushing from Graham) I did get round to just removing all the controversial features from 1.1 and calling that (which is the version on the IF-Archive) final. I don't think a minimal implementation of the 1.1 specification (excluding anything V6 related) is at all a bad idea: most of the non-V6 parts of it are really just clarifications of the 1.0 specification.

After some more thought, the really elegant way to implement this would be to have your opcode be part of a "1.2" specification, so that games could test the header fields to see if the opcode was there. Adding 1.1 to Parchment would be a good idea and should not be significant work.

However, the real question is whether there's any real demand for this, now there's a web-based Glulx interpreter.

I like what you're suggesting, and have started working to add 1.1 support to Gnusto. Well, firstly by writing test cases for it (http://github.com/curiousdannii/gnusto/ ... 411c93d417)

Do we need to check that we're running on a 1.1 terp for the updates/clarification section? I ask because I haven't found any terps that return 0 for @get_prop_len 0.

I think there might still be use for extensions to the Z-Machine, even though Quixe is useable. For the moment the Z-Machine is still quite popular, and the lack of mobile support for it is a problem. And the extensions that we'll make will probably be quite small, such as the gestalt selector in the transcripts proposal.

Was there a Z-Machine developers mailing list? I thought there was one (hosted at feelies.org?) but I can't find it anymore.

Test cases are a good thing I did create a test Z-code file for Windows Frotz for this work: it's in the Windows Frotz zip file on the Archive.

I don't think games really need to test for 1.1 for the updates/clarifications bit: it's just making absolutely clear a few bits that were left vague in the 1.0 spec. I suspect if you dig around the really old interpreters in the Archive you can find some with odd behaviour on these points, but at this stage they're so archaic that it's not really an issue any more: everyone is using something Frotz-based or Gnusto-based

There was a Z-machine mailing list, but I can't remember where: I'd have to check my old emails at home. In any case it's pretty much dead - I don't recall getting a message from it for a few years.

That was my thinking, that the clarifications part of the 1.1 spec should be followed by all 1.0 terps while it was only the 1.1 terps that would implement the new stuff. But I guess the ones who ship, win, and the de facto standard is still Frotz, whatever it actually implements. (Though Gargoyle stating it's a 1.1 terp while not supporting the new opcodes is a worry...)

Is that something specific that you know of, or just a vague concern? Without actually looking at the Frotz code in Gargoyle, I know that Ben imported the work done from Windows Frotz to get Unicode support, which should (or at least could) have provided 1.1 support too. If it claims 1.1 but fails on the opcode, we should definitely hassle Ben to fix it one way or the other.

I did just import all your work from Windows Frotz, and it seems rather likely that I missed the fact that it now claims to be a 1.1 terp as a consequence.

Is this governed by these values in main.c?



If so I will patch the source right away. I haven't done an official release based on the changes yet, so there should be relatively few instances of this in the wild.

Well someone commented out the two opcodes in process.c, so if it wasn't you...

I think those lines are the ones that matter, but David could tell you for sure.

Well, I'm sure it was me. I figured I had not implemented @set_true_colour or @buffer_screen, so it was safe to comment them out.

I did consider trying for full 1.1 support, but the requisite changes to @set_text_style put me off. Combining text styles would require even more mangling on the Glk side, though the functionality would admittedly be useful for other interpreters (such as Hugo) which expect an equivalent level of control.

Demona allows combining text styles - between my color patch and the full set of Glk styles, I think there should already be enough functionality.