Interpreters for the Apple 2, C-64, Amiga, Atari ST, and many other machines. Most of this is assembly. A few interpreters are written in C. The MacOS one is in Pascal, as that was the Mac’s original development language.
I’ve combed over everything to (a) make sure there’s no personal information included, and (b) document everything I could figure out in the README.
This contains the first public information about the “G-Machine”, the graphical VM Infocom invented to handle Fooblitzky and no other game ever. The interpreter is called “GRIP” or “DIP” (I saw both names used.)
This has the same sort of architecture as the Z-machine, but it’s a definitely a different spec. Different header format, different opcodes, no dictionary or object tree. See https://github.com/erkyrath/infocom-zcode-terps/blob/master/unix/dipdefs.h for an overview. (The implementation is clearly a hacked-up ZIP.)
0800 MSTART EQU $0800 ; START OF FREE PROGRAM RAM
[...]
0E00 ZIP EQU MSTART+$600 ; START OF EXECUTABLE CODE
2A00 ZBEGIN EQU ZIP+$1C00 ; START OF Z-CODE (ASSUME 7K ZIP
FFFF-29FF = D600 dec (D600)= 54784. As expected, larger than minizork I but smaller than minizork II by 906 bytes… I should need another analysis of minizork II’s ZIL source, but seems that the hypothesis that minizork II was scrapped because can’t be pruned to size is valid.
(actually, the zcode space was smaller than 54784 bytes, because of the non-bankswitchable color RAM @ D800-DBFF)
now, I doubt that in the surviving codebase is preserved the peculiar loading mechanism of the minizorkes, but generally the overall idea (exploiting the 64’s unique bankswitching for cramming a very small z-code) seems confirmed (note that in loading into the ROM aerea, the code/data loaded is transparently written in the “RAM under ROM” of the 64)
Thanks for doing this. When you originally denied knowledge of this source code, I tried to private message you, but you had that turned off. So I emailed Jason Scott to ask if he would add it to the historicalsource repo. No reply so far, but now it’s moot. So glad this is public now!
Yeah, I have private forum messaging off, sorry. I try to keep track of important discussions via email. If stuff arrives through other channels, I lose track of it and fail to follow up.
(You can always ping me publicly and say “Hey, chat me up privately”.)
I managed to build the Acorn (BBC Model B) version by minimally converting the source code to CA65 syntax. See https://stardot.org.uk/forums/viewtopic.php?p=408915#p408915 for slightly more information. Finding suitable .z3 files which will work with it seems to be a bit of a challenge.
Quick update. The code as found tramples over low memory on the BBC. In particular it locates its stack in the area used for sound generation. Despite a comment to this effect in the code, it then proceeds to print the BELL character, thus making a sound, thus using some of the sound workspace, thus (depending on the game) corrupting it’s own stack. Changing the memory map to exclude this area allows (small) Inform6/PunyInform games such as Cloak of Darkness to run.
Obviously none of this is terribly practical, but it has been a fun weekend project to get this far.
Realistically, I’ve got about 20Kb of memory for the resident part of the game + space for caching the rest. I have mini Zork working. Available space on a 100Kb 40 track disk is 70Kb (because the program only uses 8/10 sectors/track to make the math easier! A 200Kb 80 track disk would allow 150kb.
Having got this working, I’m not planning on doing much more with it. After all it’s a historical artifact rather than a practical ongoing interpreter, given that we have the much more capable Ozmoo on the BBC.
It’s Z3 only.
When time permits, it might be fun to see which of the Infocom originals it will actually run.
My game (Duck! Me?) is too large (in terms of the resident part) to run on a BBC Model B, although it will run painfully slowly on a BBC Master 128. Ozmoo runs it much better.
