Infocom-zcode-terps: Historical source code for Infocom's Z-machine interpreters
github.com
github.com
https://github.com/devshane/zork
http://mirrors.ibiblio.org/interactive-fiction/games/source/...
One detail I vividly remember is reading a listing deep in some cavern that said something about MEMQ
Object: 122: stack of listings
There is an enormous stack of line-printer paper here. It is barely
readable and totally unintelligable.
Initial:
There is a gigantic pile of line-printer output here. Although the
paper once contained useful information, almost nothing can be
distinguished now.
Flag1: -8176 (burn take read visible)
Size: 70
Room: 137 (Tomb of the Unknown Implementer)
Read:
<DEFINE FEEL-FREE (LOSER)
<TELL "FEEL FREE, CHOMPER!">
<MEMQ ......
The rest is, alas, unintelligable (as were the implementers).The labels were in fact numbers, not just numeric strings, since there was a computed GOTO that took an expression to jump to.
I wonder what aspect of coding today will seem to coders a half-century from now to have been not, sympathy for the machine, but excessive kowtowing towards it?
(I would suggest order-dependent alternative trees, but Hope provides an example of starting with order independence and subsequently reverting to what programmers traditionally expect)
At least an assembler lets you set strings for all your jump points...
It's the real deal!
https://virtuallyfun.com/2023/11/21/zork-for-the-pdp-11-rt-1...
Later:
> if (datname = init(argc,argv)) THEN > gamfile = datname;
The programmer apparently really hated this quirk of C syntax.
Me too.
I don't see mention of a license in the repo, but I wonder if informal permission was given to make the sources public?
In this case, it is very unlikely no one cares and not wishes to see this in public.
The last time I saw assembler was in a bloody history class :P
Mind you, old school game developers were absolute gangsters and gave 0 shits about anything except things working and that's what I appreciates about them.
It's just bloody hard to read, unless you wrote it, and wrote it recently. You effectively have to have the state of the register set in your mind the whole time.
Lots of C code from back then is just as impenetrable though. It has structure but it's terse and mechanical. Everyone rolling their own lists and hash tables and string functions in every program, lots of unrolled loops, etc. Different constraints. Memory & CPU was expensive.
Even today many cool performance tricks require understanding the bytecodes of the underlying language runtimes.