There was some discussion about Infocom’s interpreter source turning up in this thread, and I said “Taking this to private chat”.
Here’s what turned up!
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.)
I have another one, an ‘ibmzip’, written in C.
… now where I can find time to actual IF coding re. history of IF coding ?
seriously, thanks for the 'terp side of “The Drive” !!
Best regards from Italy,
ps. I hope to surface from the depths of Zmachine 'terps in time to write my post-mortem of creative cooking…
You can post that one.
:) I just put up the “micros” directory as it was passed to me.
I will eventually add this stuff to my https://eblong.com/infocom/ page, but I want to wait a few weeks so that it’s not news any more.
Yeah, okay. I will, just as soon as I get around to scanning it for personal information. Hopefully soon. Maybe this weekend? We’ll see.
starting to unravel the enigma of mini-zork II
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)
Best regards from Italy,
THIS is amazing, gentlemen! Wow.
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!
I suppose historicalsource should clone it.
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”.)
Slashdot picked up the story.
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.
For z3 there are Mini-Zork 1 & 2 and Craverly Heights. All three around 50 kB.
For z5 there are Werner Quest 1-4 (55 kB) and Zork 285 (38 kB).
How much space do you have to play with?
EDIT: I think there are a couple of games done in PunyInform that is even smaler.
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.
And here is a bunch of code for the IBM terps:
I looked through the files for personal information. I have added no Readme, or anything else. Have fun.
Regarding this comment in the README:
Not sure which BASIC this is. The
xzip.bin file starts with the bytes “CBM”, but the
*.bas files don’t look like C64 BASIC to me.
Maybe it’s GW-BASIC? I tried running the .bas files through GitHub - danvk/gwbasic-decoder: Convert binary GW-BASIC programs back to text and the result looked plausible, at least. (NB: I’ve never used GW-BASIC.)
Hm, yeah, the tokens look right for that. Thanks.