I filed http://inform7.com/mantis/view.php?id=1354 years and years ago, just to have somewhere to collect my thoughts on the issue. As you say, the benefit is niche.
2 Likes
The question of how to work around the hard limitation of 64 KB dynmem for Z-code story files was the subject of some debate many years ago, when a z9 format was discussed on the Z-machine mailing list. Unfortunately, there was no proposal which wouldn’t also necessitate Inform code to be written quite differently for z9 compared to z5 and z8, making large changes to the library necessary, making many library extensions useless and break code for games which someone started to make for z5 or z8 and then found that it got too big and needed z9.
Anyway, if you want a large game to run smoothly on a machine with 64 KB of RAM in total, you will need to have the target platform in mind when writing the game. Not only do you want to keep dynamic memory usage low, you also want to make sure there is not so much code that is run every turn or almost every turn. Much of the parser is code that is run every turn, and so you need a library that is a lot more compact and preferably more performance-oriented than the regular Inform 6 library.
Also you need to mind what kind of content you’re trying to squeeze into the game. If you want long descriptions of locations and items, and have the items respond in clever ways to many actions, that’s probably fine - it doesn’t use much dynamic memory, and the code is only needed when you interact with that object. If you have an extensive before-routine for a statue in the garden, that code can be paged out once you enter the house or leave the garden in some other way, to make room for other code. However, if you have ten NPCs which all have their own clever routines to try to accomplish goals of their own, seek out their own paths through the map etc, that will probably bog down the machine.
If you have a look at Infocom’s games, they always designed their games in a way that made the game fast enough on the target machine. If a puzzle turned out too big or needed too much CPU, it had to be reworked or scrapped.
Cloak of Darkness currently compiles to a z5 file weighing in at 50 KB using I6 lib 6/12. The very same game can be built as a z3 file with Metrocenter’84 (not yet released) and take up 21 KB, or PunyInform (not yet ready for production use) and take up 17.5 KB. I think these libraries will be the way to go for anyone who is serious about writing I6 games for 8-bit platforms.
Or to put it another way - there’s no reason to act surpised that a game that was developed and tested on a machine with a 3 GHz CPU and 8 GB of RAM turns out to be slow on a machine with a 0.001 GHz CPU and 0.00006 GB of RAM.
3 Likes
(may it please the court, it was meant as a friendly question)
1 Like
I never doubted it was a friendly question. I just saw this as a good opportunity to share what I’ve learnt about making Z-code games run on 8-bit computers. There seems to be an increasing interest in this now, and I’m glad to see and help promote that surge in interest.
2 Likes
I’ve been looking at what would be required for I6 to support static memory arrays. It’s doable, but it’s not a trivial hack.
My experiment doesn’t fully work yet, but it’s getting closer. I’ll post against when I have something demostratable.
4 Likes
That sounds very interesting!
Is this doable without breaking the Z-code standard and/or existing terps?
Yep, it would just put the arrays into static memory. See section 1.1 of the standard.
1 Like
ZIL could always do this (and ZILF can today); it just wasn’t a feature that the Inform compiler ever bothered with. Even in early versions, Graham wasn’t aiming at the extreme optimization tricks needed to run on a C64 interpreter.
1 Like
While I think being able to put arrays in static memory is a good idea, it will only help for arrays that aren’t needed all the time, or large arrays where different parts of the array are needed in different sections of the game. If the game reads little pieces here and there from the array every turn, the situation won’t be much different from having the array in dynamic memory - either there is room to keep the data it in RAM all the time, or the terp will be constantly swapping.
Ozmoo is really great. I have one suggestion though:
Most emulators can run at a very high speed. I like that as I get the best from both worlds: The atmospheric look of the c64 without being slow. But if you do that with Ozmoo, the player will get lots of spaces between words when typing because the “space key” is set to repeat and the emulator is “too fast”. This looks very messy. A similar problem is present when hitting “backpace” to delete typed characters.
I see no reason why any key should repeat, as it can be avoided with a simple Poke:
POKE 650,127
Unfortunately, many players don’t know how to enter pokes, which probably requires that the player has found an Action Replay cartridge file somewhere and know how to freeze a game and enter a poke.
Thus it would be great if repeating keys were disabled by default in Ozmoo, or at least it could be an option to turn off repeating keys.
Thanks for reading 
2 Likes
(someone in this situation would probably find it easier to enter the value in the emulator’s built-in monitor than track down a freezer cart image, but yes, you make a good point.)
In the interim, I’ve found that it’s safe to run around 200% without repeat, although I guess typing styles may factor in a bit.
Do arcade game Z-machine hacks count on key repeat being a thing?
1 Like
Good idea. We’ll include this in the next release.
/Fredrik
2 Likes
Place names are not displayed in reverse video for versions higher than 3 ?
Well, it’s up to the game. In Z5 the game can check which capabilities the interpreter has, and Ozmoo will report that it can do reverse video and different text colours, but not bold text.
If the game tries to print something as bold (like the Inform 6 library does with location names), it will just come out as plain text. If the game tries to print it as reverse video, it will come out as reverse video.
I said reverse video instead of bold, but you still answered my question.