Yeah, I can see where they print that section, and you might be able to see that in Milliways if you input the right thing (but it doesn’t take a long time because of the modern system).
Finally got around to this: a PR to add ZIL opcode names to the Complete Table of Opcodes.
6 Likes
From the Infocom zip spec:
FSTACK 0OP:185
Flushes the top value off the stack.
Infocom seems to have reused the name for the v6 opcode.
Oh, good. I just missed that when reading through.
The Standard currently states:
7.4
In Versions 3 and later, all four output streams can be selected
or deselected using the output_stream opcode.
If we go by this, then the table parameter must be available for v3.
Yeah, that line in 7.4 has always been at odds with the opcode table. My personal preference would be to accept 7.4 as correct and the change the table.
It seems to me that output_stream is a v4 feature that got used in some v3 games as well. Given that the Standard says stream 3 is available in v3, I agree that simply altering the table in section 14 to read
VAR:243 13
3 output_stream number
3/4 output_stream number table
6 output_stream number table width
is by far the simplest and nicest solution.
1 Like
I am definitely going to go through and add more internal links to the spec. Sometimes a section refers to another section, with no link. Also, I think the Remarks could do with links from and maybe to the relevant section. Some of the Remarks sections are kinda long and cluttered.
2 Likes
The Remarks for Section 14 states:
The opcodes EXT:5 to EXT:8 were very likely in Infocom's own
Version 5 specification (documentary records of which are lost):
they seem to have been partially implemented in existing Infocom
interpreters, but do not occur in any existing Version 5 story
file. They are here left unspecified.
This was entirely true when written, but now documentary records of which have been found, and we know what those opcodes were supposed to be. Although the opcodes remain unspecified in the Standard, this remark needs updating.
The Standard should probably somewhere contain links to the current official location of the Standard (Inform - ZMachine - Standards), the location of the github repository (GitHub - iftechfoundation/Z-Machine-Standard), and the Infocom Specifications (https://ifarchive.org/if-archive/infocom/interpreters/specification/infocom-zip-specs.zip), while making it clear that the current official Specification is the one on inform-fiction.org.
The first two help to avoid taking old versions or in-progress edits as current. The last one is just likely to be of interest to many people reading the Standard.
1 Like
I have updated Section 14 on github to add the FSTACK ZIL name.
1 Like
What do we know about their intended purpose? I’m curious now.
The opcodes in question are draw_picture, picture_data, erase_picture and set_margins. Under the Standard, these are all v6 opcodes, but they are detailed in Infocom’s xzip (v5) spec, more or less the same as they were actually used in v6 games.
The current size of the left and right margins were stored in the header, at the locations used by v6 for routine and string offsets.
2 Likes
What’s the plan for branches in the spec repository?
Three options I can think of:
-
Only maintain the 1.1 document/branch. Because the 1.1 additions are all clearly identified as such, the 1.1 document can still be used to learn how to implement a 1.0 standard interpreter. This would be my preference because it will be simplest. If we chose this option, then the official 1.0 document on inform-fiction.org should have a note added saying it is frozen, and pointing people to the 1.1 document.
-
Commit changes to the 1.0 branch and then merge the 1.0 branch into the 1.1 branch. This treats the two branches like two branches of a software project. As long as the 1.1 additions are in separate paragraphs (as they should generally be), merges from 1.0 to 1.1 should be clean and automatically resolved. This makes it easier for people submitting changes as they only need to make a pull request to the 1.0 branch. Someone else will then have to (frequently or periodically) merge the 1.0 branch into the 1.1 branch.
-
When an update applies to both 1.0 and 1.1 require separate PRs for both branches. This is the worst option as it is just unnecessary work.
I’d like an answer to this soonish, as I’d like to add the various Z-Machine tests to the repo. Ideally we want most future changes to also be accompanied by tests, either in Praxix or in stand alone files.
I plan to largely choose option 2, but if people want to help with changes they can just do whatever’s easiest and I will make sure the changes apply correctly to both versions. I have no problem doing the extra work required to keep both documents current.
1 Like
Back when I was implementing the Z-machine, I would have personally preferred option 1: less to juggle and no additional ambiguity.
I’m not clear on how keeping both versions of the spec accurate makes things more ambiguous. We can definitely add a note in the 1.0 version pointing towards the 1.1 version, even while keeping both up to date.
(I didn’t ask this in the topic I had intended to, so I’ve moved the last 4 posts.)
I’ve put up a pull request with the tests I had in my if repository.
Option 1 makes no sense to me as freezing the 1.0 document renders the document useless. Anyone wanting to implement 1.0 would need to read the 1.1 document for corrections.
Clarifications and corrections need to be in both documents.
Another philosophical question… one of the major changes going from 1.0 to 1.1 was just updating links. (Changing ftp.gmd.de to ifarchive.org, removing links to obsolete interpreters, mentioning Inform 7, etc.)
Is it worth backporting those changes to the 1.0 doc? I am ambivalent. I guess it’s consistent with backporting the ZIL opcode names to 1.0 (which David has already done) but it doesn’t feel very important.