I don’t mean that all interrupts should be allowed to do whatever. Simply that (for instance), say we allow printing during timed interrupts but not during sound interrupts. If a timed interrupts interrupts a sound interrupt, the timed interrupt can print stuff, even though it’s in the middle of a sound interrupt which can’t.
Overall, I think your suggestion for prohibiting interrupts from certain behaviours is fine. I’m all for avoiding making interrupts more complex for interpreter writers, and anything that doesn’t require modification of current interpreters is good.
The only thing I’d say is, it’s worth looking at games that already exist which use these features to see if any of them already do things that we want to prohibit, such as printing during sound interrupts.
Also, printing during sound interrupts is probably not really all that bad. The only thing terp authors likely need be aware of is the redrawing of input lines when needed. Game authors would need to avoid multiple interrupts printing in the middle of each other, but that’s not a terp issue really.
To argue with my previous position: A cool feature of sound interrupts being able to print would be to launch a song and print its title in the upper window as the current song ends.
I haven’t implemented timed input in ZVM yet, so I never took the time to fully understand the Z-Machine’s interrupts. But I’d recommend looking at what existing games need, and banning any combination of features that isn’t already needed. It would be better to keep those cans of worms firmly unopened if possible.
I think if a sound interrupt really wants to print something, it can update an array with the text, and then the game can print that array when it gets a chance (possibly in a timed interrupt).
I would appreciate if someone could correct the standards document regarding Atari 8-bit story files. In the current version, Stefan Jokisch is cited on the structure and logic behind Atari 8-bit story files but he is wrong unfortunately. See this post I made in 2021 as a reference Z-machine standards / Atari 8-bit targets
Ah yes. I see it now. Back when I read it I thought the question mark documented that the purpose of the flag is unclear.
I don’t know if bit two being set and all others being cleared is equivalent to integer 4 as I am not familiar to with ASM or Z-machine bytecode. What I do know however is that this flag was only relevant for the Atari 8-bit and literally every Infocom story file I investigated, and I investigated them all, has integer 4 set. Excuse me if that sounds a bit cheeky now but: the Infocom standards document should document the Infocom standards, right? So if Infocom always set this flag to integer 4 when they split story files, why not documenting it like that? I have to admit that I don’t get that.
One also needs to consider that we do have a special situation here. I made story files run again in Infocom’s 2-disk Atari 8-bit interpreter but I always set the integer for this flag to 4, so to confirm if it is the same one likely would need to alter one story file by setting bit two and clearing all the others to see what happens.
The really important part though that needs correction is this one:
Blockquote and were divided into the resident part on one disc and the rest on another. (This discovery was announced by Stefan Jokisch on 26 August 1997 and sees the end of one of the very few Z-machine mysteries left when Standard 1.0 was first published.)
Because that part is definitely wrong as already stated in my linked post.
You’ll have to document it per bits, because the flags have different meanings. I don’t know if Deadline was available for Atari 8-bit but if it was, the integer value of byte 1 would be 6 (bit 1 and bit 2 set).
It is 4.
A hypothetical game which was split across disks and did not support a status line would have 20 (4 for split disks, plus 16 for no status line).
A game that was split across disks and supported split screen (only some Seastalker releases used a split screen) would have 36 (4 for split disks plus 32 for split screen).
It is entirely possible that all the split disk story files just coincidentally had all other flags zero, making the number always 4.
The standard actually is an amalgam of Infocom and modern behavior. It is designed such that Infocom era games will play under an interpreter that follows the standard, but it does not mean that it describes exactly the behavior of Infocom’s own interpreters. Infocom’s own interpreters weren’t always consistent with each other.
It was definitely available for the Atari 8-bit, as this is the version I bought and played way back in the dim distant past. I think this may have been the first of the two-disk games, as Starcross and the Zork trilogy were one-disk games.
I think version 4 is underspecified with regard to sound_effect.
The standard makes clear what is expected for V3 and V5, but leaves V4 unmentioned.
The sound_effect opcode works in V4, e.g. in AMFV, but only bleeps are used and no samples.
I see 4 possibilities for sound_effect behavior in V4:
It is completely undefined for anything beyond bleeps. (This is logical, but it bugs me)
It follows V3 behavior - externally defined looping, and no interrupts. (Yuck)
Hybrid behavior - No externally defined looping which allows repeats via operand like V5, but still no interrupts. (Meh)
I agree with this, technically the standard implies that version 4 has no capacity for sound. I think, logically, V4 should be the same as V3, even though the V3 method is ugly and weird.
Given a choice I’d prefer V4 be limited to bleeps vs. use the V3 model, provided no post-Infocom V4 games use samples.
It may not make sense as a chronological evolution (that’s the part that bugs me), but we know sampled sound was essentially backported to The Lurking Horror from V5 and Infocom’s V4 terps did not support anything except bleeps.
Looking back at my current code: I am allowing V4 to play sounds and set the count via the high byte of the third operand, but not allowing V5 style interrupts. That’s equivalent to #3 - hybrid behavior.
Options 2, 3, and 4 are all possible in my existing code without adding additional version checks - just altering the existing ones. Option 1 would require new checks…sigh.
I think option 2 is the simplest to explain in the standard, technically easy for interpreters to handle, and what most game writers would expect from a version between 3 and 5.
Option 2 or option 4 are probably what Infocom would have done if they’d ever decided to hack sound back into an ezip game.
I tried to check what Frotz does and from what I can tell, it hard-codes the loops for Lurking Horror and otherwise just lets any version game use V5 behaviour. So that wasn’t very helpful.
Heh, I just noticed that Blorb specifies that the looping chunk not be used in games which are not V3 Z-machine games. So option 2 would require a small update to the Blorb standard.
