The 128 words includes all temporary variables and the pretty-printer. I'm still deciding if I like that `1` in the last place, or if I should show it as a `+` or something. I think it's misleading for folks who actually know Soundex.

I'm also relatively confident that there are optimisations I could make on the test logic. So much of it is "store, reload, load a comparator, add, skip on condition, etc etc" that there's bound to be room for a few dirty tricks. If I could, I'd fit a routine to tokenise an entire string of words into an array of hashes, and print the set.

Well now, I've finally had time to come back to this project and fix it up now that I'm done with my postgraduate degree.

I changed the encoding, because soundex can't distinguish between `SOUTHEAST` and `SOUTHWEST`. So I now use the most significant bit of the 12-bit hash to mean "this is soundex, not raw text". When it's raw text, you get one or two characters directly in the 12-bit word.

So this means that `S`, `SE`, `SW`, etc are all distinguished inexpensively. I've done analysis on the dictionaries for Hibernated, Trinity, Moonmist, and the Cloak of Darkness demo, and the collision rate is (I think) acceptable given the other factors that can disambiguate verbs and objects in the game grammar.

So, why am I doing this? What good could possibly come from a "soundex without enough digits" scheme?

Well, coding on the PDP-8 (or 12 or LINC) has taught me that the algorithms we think of as for "small machines" are all relative. People nowadays will think absolutely nothing of a process casually allocating more memory than any computer I owned in the 80s or 90s. And so you will find people touting efficient low-resource algorithms that will brag that they make do with a scant few kilobytes of memory for the index tables or trees they use. Such frugality!

Well, the PDP-8 most commonly came with 8k of core memory. Using 6 of those for a dictionary of possible words the player could type in just won't fit. The LINC only had 2k of core, and spent most of its time swapping to the random-access tapes it had!

So a couple years ago I found a paper describing a text compression algorithm for which I'm confident I can write a decompression algorithm in a page (128 machine words) of code, and had the idea to use a modified Soundex encoding to replace the input dictionary.

So I'll have a pass that tokenises all input into a string of these hashes, and the code for an object will include those single-machine-word hashes in a list of "these are the words you can use to refer to me". And grammar objects will help disambiguate verbs that collide (such as `L200`, which maps to both `LOCK` and `LOOK`, but nobody types `LOCK AT DOOR` or `LOOK DOOR WITH KEY`, so that's fine).

And one advantage is that this will make the confusions a little more understandable. Yeah, "lock" and "look" can be hard for humans to hear the difference in a noisy room, so it can be part of the charm that the game is a little fuzzy, less picky about how you spell words, but also has trouble telling `BLOOD` from `BLADE` without more information.

I had a busy week, so haven't been able to sit down and bang out any code for the ASCII text compression system, but that is definitely next. I'm basing it on https://doi.org/10.1093/comjnl/24.4.324 (EDIT: the author has put this up at http://www.jackpike.co.uk/36.Text%20compression%20using%20a%204%20bit%20coding%20scheme.pdf), but tuned for my 12-bit words.

One feature I worked out last night while drifting off to sleep is that if I make 0000 the "grab two nybbles as ASCII" symbol, it will natively handle a string of unpacked ASCII with only a little computation overhead (peanuts compared to waiting for the teletype ready signal!)