intfiction.org

The Interactive Fiction Community Forum
It is currently Tue Jan 15, 2019 10:02 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Nov 26, 2018 1:48 pm 
Offline

Joined: Wed Jun 17, 2009 5:29 am
Posts: 24
zarf wrote:
Putting that in the flags bit seems like a slight category error. The interpreter should know where to find the game file before loading it in. The disk layout is between the interpreter and whoever packages up the game, not a Z-spec question.


Agreed. Also note that this flag disappeared in version 4. I bet the people who designed the Z-machine did their best from the start, but learnt a lot from creating games using the Z-machine and so they created several new versions of the Z-machine over the years, fixing mistakes and adding new features.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Mon Nov 26, 2018 2:41 pm 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 123
fredrik wrote:
zarf wrote:
Putting that in the flags bit seems like a slight category error. The interpreter should know where to find the game file before loading it in. The disk layout is between the interpreter and whoever packages up the game, not a Z-spec question.


Agreed. Also note that this flag disappeared in version 4. I bet the people who designed the Z-machine did their best from the start, but learnt a lot from creating games using the Z-machine and so they created several new versions of the Z-machine over the years, fixing mistakes and adding new features.


Hmm. I mean, yeah, I agree with the two of you that it's inelegant. But I think it's a slight category error to refer to this as a slight category error.

Infocom made all these games, and this system. Then the system was reverse-engineered, and through that process we (the community) reached a common understanding of what the various parts of the system were supposed to be doing. The role of the interpreter is this, the role of the game is that. But if it turns out that our understanding of the system is slightly askew, then surely the error is in our understanding. Otherwise it's like claiming that the universe is wrong to be relativistic, since Newton's laws are so much simpler.

It's not that hard to come up with a use case for it: A game might want to supply custom messages for save and restore actions. After a successful save, a game might print "Shiver me timbers! Yer progress be saved. Now replace the game disk into the ol' floppy bay, and hit ye return, old salt!". But if the game is distributed on a two-sided disk, with the swap-on-demand data on side B, it should perhaps print "Now replace the game disk, keel-side up, into the ol' floppy bay" instead. Hence the need for a header bit, so the game can distinguish between the two cases without breaking character.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Mon Nov 26, 2018 3:23 pm 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 123
Less fanciful rationale: We know that some v3 games would fit on a single Atari disk, and some would need two disks. It might not be possible to distinguish between end-of-file and load error. So there needs to be some way for the interpreter to know whether it's loading a single-disk game or a multi-disk game. For a multi-disk game, loading is supposed to stop exactly at the resident-memory boundary (where we prompt for disk two). This could be solved by having two versions of the interpreter (one for small games and one for large games), but that leads to double-maintenance and a risk for mix-ups. It's much easier to have a single Atari interpreter, and then to include the unmodified game file if it fits on the same disk, otherwise split it and set a flag in the file that we're splitting.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Mon Nov 26, 2018 4:01 pm 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5880
Quote:
But if it turns out that our understanding of the system is slightly askew, then surely the error is in our understanding.


We've been implementing the Z-machine and writing games for it for more than twice as long as Infocom did.

We can say they were wrong if we want to. :)

Quote:
It's much easier to have a single Atari interpreter, and then to include the unmodified game file if it fits on the same disk, otherwise split it and set a flag in the file that we're splitting.


I don't know how the Atari disk layout works, but it would be just as sensible -- probably more sensible -- to include a block of interpreter config information which is not part of the Z-code file.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Nov 27, 2018 12:50 am 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 123
zarf wrote:
I don't know how the Atari disk layout works, but it would be just as sensible -- probably more sensible -- to include a block of interpreter config information which is not part of the Z-code file.


By modern standards and sensibilities, I agree. But the world of microcomputer software was different back then. I looked up the Atari disk format. Each disk comprises 720 sectors, and each sector is 128 bytes (of which up to 125 are actual file data). Adding an extra configuration file is going to eat up a whopping 128 bytes, whereas setting an otherwise unused bit in the header has zero overhead. For a game with a size that's already close to the limit, that extra sector might push it into a two-disk game, doubling the mastering costs.

Of course, it would have been possible to solve this with zero overhead in a number of ways. Encoding it in the filename comes to mind. But again, perhaps the people at Infocom viewed the z-file header in a different light than we do now. Perhaps they thought of the header as precisely such a config file.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Nov 27, 2018 3:27 am 
Offline

Joined: Sat Oct 17, 2015 5:48 am
Posts: 97
perhaps the "different light" is that the header is akin to the metadata of today ? (just awake, my apologies if I have wrote something stupid...)

Best regards from Italy,
dott. Piergiorgio.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Nov 27, 2018 4:21 am 
Offline

Joined: Wed Jun 17, 2009 5:29 am
Posts: 24
zarf wrote:
I don't know how the Atari disk layout works, but it would be just as sensible -- probably more sensible -- to include a block of interpreter config information which is not part of the Z-code file.


Coincidentally, this is exactly what Ozmoo does. It stores all config information on track 19, sector 0-1 on the boot disk. This includes data on:

* Which disks are part of this game (2-4 disks) and what their names are
* Which sectors on each disk are used for story data
* The sector interleave factor used
* Which parts of the story file are pre-loaded into memory when the game has loaded
* Which parts of the story file are suggested for pre-loading before the game starts but the interpreter will need to load them itself, if it wants to
* Build ID, so the interpreter can tell if a certain disk belongs to the same build.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Nov 27, 2018 11:29 am 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 123
Here's yet another angle. (I'm not trying to be contrarian, I just think this is an intriguing philosophical question that ties into IF system design and reverse-engineering.)

Consider a present-day Z-code interpreter that doesn't support pictures or sounds, but is capable of loading both zblorb files and raw z-images. Once the game is up and running, this interpreter only needs to be concerned with the raw z-image. But when loading the game from a zblorb file, it needs to extract the z-image from inside it. So there are two different ways of loading the same game, depending on how the game data is organized on disk. Sound familiar?

How does the interpreter distinguish between the two cases (extracting from zblorb, vs. treating the entire file as a z-image)? If the ultimate goal is to have clear-cut categories, information about the container format (or lack thereof) needs to be stored outside the game file. This follows from the same argument that says that the Atari interpreter shouldn't deduce the file format based on a header bit. For our present-day interpreter, the format information could be supplied as a command-line argument, or by the filename extension, for instance. But in practice, what any well-designed interpreter will do is to look at the header of the file. If the zblorb magic-number is there, use the zblorb loading routine. Otherwise, use the raw z-image loading routine.

Now, a possible counter-argument is that the zblorb header is sealed off from the game data. While it is stored together with the z-image in the same file, there is no way to access this data from within the running game, and because of this strict separation, there is no category violation. But the z-image header is part of an interface between the game and the interpreter, and interfaces are essentially contracts; they can have arbitrary rules. Suppose there's a rule saying that the running z-code isn't allowed to depend on the value of this flag. For instance, that the value of the flag is undefined once the game is running, except that in all current implementations it just happens to remain at its original value. Such a rule provides just the same strict separation, by design! But it's impossible to deduce that such a rule exists, merely from reverse-engineering the existing implementations.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Thu Nov 29, 2018 7:29 am 
Offline

Joined: Wed Jun 17, 2009 5:29 am
Posts: 24
The header of a Z-code file isn't a file header at all. That's why there is no magic number in there saying it's a Z-code file. The entire file is a memory image of a computer, the Z-machine, and the header is the first part of that memory image.

Every single bit in the header is there as a means of communication between the Z-code program and the computer it runs on (the Z-machine), except for the bit we're discussing here. The Z-code program couldn't care less about whether it's distributed on one or two disks, so there's no need for communication regarding that fact. That's why this information shouldn't be in the Z-code header.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Thu Nov 29, 2018 8:22 am 
Offline
User avatar

Joined: Thu Aug 22, 2013 2:48 pm
Posts: 123
And yet it moves.

_________________
Dialog. Tethered.


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group