It’s the original compression rate. If you define the original, uncompressed text as 8-bits for every character, L9’s algorithm compressed it down to about 56-58% of the uncompressed size.
It should be interesting to see what happens in version 3. They changed the character encoding completely between 2 and 3.
I was under the impression that they used 16 bits to store lookup codes for words and word fragments stored in a dictionary.
For example, the number “752” (stored in 2 bytes) might represent the word “Snowball” (8 bytes). If that word were used 3 times, then it would use 14 (6+8) bytes as the lookup codes and dictionary word, instead of 24 bytes as plain text.
The reason I thought they used 16 bits for lookup codes is that 8 bits would only provide 256 different values.
That’s version 3 and version 4.
In version 3 and 4 they used 12 bits for the lookup codes/characters where values below 0xf80 pointed to one of up to 3968 dictionary words. If the value is greater than 0xf80 the corresponding 7-bit ASCII is printed. The remaining 4 bits in the 16-bits word are used to controll if a pre-space or post-space should be printed and the case of the printed dictionary word.
Exactly 0xf80 is a divider between a word and its synonyms. These messages are used when parsing the user input.
So how did they manage to fit Colossal Adventure into 32 Kb? I thought the text of the original Colossal Cave Adventure was around 300 Kb?
Not at all. “advent.dat” from the Fortran port is 55k, and that includes the room exit tables, score tables, and some other data.
Looking at the Woods 350 pts version from 1977 the fortran dat-file is 54.2 kB. This file contains a bit more than messages but it’s certainly not 300 kB.
The messages in Colossal Cave are 36.708 bytes and this is compressed down to 18.519 bytes. This one had a better abbreviation table a guess for that is roughly 50%.
Edit. @zarf beat me to it!
here are two quotes from mike austin that might be relevant:
Yes, there were quite a few 16K versions [of Colossal Adventure] in the early days. The main difference was usually that the text was precised down to a very small size. I don’t have a comprehensive list unfortunately.
We targeted computers down to about 8K. I have a feeling we may have done a 4K version [of Colossal Adventure] at some point. The text usually compressed to about 25% of its original size.
I’ve just found out where I got the 300 Kb figure from. This Wikipedia entry says that it “required about 60k words (nearly 300kB) of core memory”.
The version 3 of Colossal Cave Adventure use 13.073 bytes for the messages (not counting the dictionary). I have a hard time believing they could fit the full game on 4K without simplifying the text.
Yes, both the early versions of Colossal Adventure and Adventure Quest were available in 16K versions as well as 32K ones. (I was the one who posted those comments you quoted on that article)
http://8bitag.com/info/level-9.html
From the very first advertisement:
“A complete, full scale version of the original classic mainframe game “Adventure”. You’ll find all of the treasures, creatures and rooms that you will have seen hinted at in computer magazines.”
“And the standard end-game, with only 2 locations, has been enlarged by a new ending with over 70 extra rooms! No one else gives you this bonus.”
“Each adventure has over 200 individually described locations…”
“…16K or 32K of memory… The versions differ only in the size of text descriptions…”
Unfortunately we can’t see just how cut-down the text in the 16K versions were.
Hopefully, the future archiving of Level 9’s work will uncover these “lost” 16K versions and other interesting landmarks such as their early game Fantasy.
(As an aside, there were some other faithful 16K versions of “Colossal Cave” out there, such as Syrtis’ highly-regarded version for the Nascom. That one does exist in 16K and 32K form, so you can compare the two versions… Syrtis Adventure )
Can you make l9dis-32win work? trying to exe return to eden, worm and lancelot but to no avail, can’t make it work!
Welcome to the forum!
I did with several games, but I compiled from source 
(I don’t know if the Windows exe works)
Its been a while since I worked with this, but l9dis_win32 is just a compilation of the c++ code in VS2019 with all references fixed. The code-base and logic is unchanged.
What is it that is not working? Is it that the program won’t run at all or that it won’t decode the sources you try?
First, the l9dis only works on version 3 and 4 games (and not all of them either, as I remember). The workflow I use is (and I just tried it and it works with Return to Eden, v3 and Worm in Paradise, v3):
1. Start game in emulator. I use VICE for C64, but it should work with a Spectrum one too.
2. When the game is loaded and running, Save a memory dump from the emulator. In VICE
this is becomes the <game>.vsf.
3. Extract the actual game-data from this memory dump with the program l9cut (or l9cut_win32).
I call the result <game>.dat. ie. i9cut <game>.vfs <game>.dat
4. Run l9dis (or l9dis_win32) on the <game>.dat to disassemble.
Reading thru the dissasembled code of several of the games, it looks like a primitive BASIC code with just a few commands in a low level fashion, which I deem pretty effective. Most of the other authoring tools include too many commands which are just stylised rewrites of simpler operations such as (quill/paw/daad) AT X meaning IF FLAG38 = X. I understand that banks are mere memory swaps (…) and the scripting blocks with those =, =>, += and the like and those gotos and gosubs and returns make it a simple code flow, although I don’t get why value comparisons are preceded by # (IF G043 == #00 GOTO 00232 [#00e8]). Few commands play in favour of creativity and pure text mathematics on screen, which I like in text adventures rather than the syndrome for simulation adhered by Inform and other authorihng tools’ users. I’m looking forward for the level 9 a-code specs and authoring tools to being available in github.
My mistake. It finally worked. I had a wrong path… I could disassemble the DOS .DATs without any problem. Tks!
Soooo… I guess the end game is to have with A-Code what we have with ZIL, that is we can create a game in A-Code and compile/assemble into a playable game file?
Yes. Correct.
The team of BBC Micro adventurers over at Stardot, are also doing some work on investigating the Level 9 game Lords of Time, looking at aspects such as the compression code…
https://stardot.org.uk/forums/viewtopic.php?f=40&t=24268