Posted December 23, 2024 by Christopher Drum
#z-machine #infocom #inform
It's been a good week of significant progress and I believe (🤞) I've hit a significant milestone in compatibility. Three games in particular were giving me strange troubles, and all three are working (?) at this time.
This game revealed a misunderstanding of how object properties are referenced in memory. Every object has a set of properties that live at a specific memory address. The documentation alludes to, but never directly reveals the implications of, the ability for a z-machine to decode data bi-directionally. In fact, the documentation is kind of lying in a way when it says of the `get_prop_len` opcode, "The result is the length (in bytes) of the property starting at address baddr. This is stored in some bits of the byte at baddr − 1"
Not so fast!
If we think more deeply about the implications of how data can be decoded bi-directionally, *and* we think about how z5 games sometimes store this particular value in 2-bytes, "This is stored in some bits of the byte at baddr-1" is not always true! Sometime that data is stored at baddr-2. This off-by-one-byte problem kept Border Zone from resolving in-scope objects properly.
Getting Pico-8's draw routines to play nicely with z-machine expectations has been a bit of a challenge. I'm sure this is true of anyone writing an interpreter for systems with tight restrictions; newer games have reasonable expectations of minimal video hardware availability that far exceeds what older systems (and simulations of older systems) can provide.
That said, I've managed to wrangle things well enough to get Photopia to roughly display itself in accordance with expectations. Title card-style quotes (like at the very beginning of the game) appear to be hard-coded to dimensions and do not flex to fit a variety of screen sizes. There's really not much I can do about that. Trinity had the same problem, and the solution wound up being a modification of the original source code. The .gif above demonstrates color-switching and screen manipulations the game performs being rendered accurately.
My white whale, this debugging cycle. This is a much more modern v8 game and it baffled me for a while. It played just fine, but refused to show the input ">" whatsoever. So it was "playable" in the sense that it accepted and responded to input, even if you couldn't see what you were typing.
The solution to this does, however, break the test suite called Praxix.z5. Long story short, Pico-8 uses signed 16.16 fixed point numbers in its operating space. Some opcodes calculate a target memory address from a base address + an offset. If the offset is value 0x8000 or above, Pico-8 treats this as a negative number, by default. According to Praxix, this is a valid possibility. However Lost Pig provides a case where the base address is 0x0000 and the offset is 0x9014 and this is supposed to be treated as a POSITIVE offset.
I'm working on a fix that will keep both Praxix and Lost Pig happy. This is being discussed with the developer community on IntFiction forums. You can follow along, if you'd like. IntFiction forum discussion about Lost Pig troubles.