How the text is stored and told

The game has 177 messages, 80 room descriptions and names and 61 object names, and holds none of them as text. A message is a small program for RUN_MESSAGE, and a name is three dictionary references. This page takes one message apart, runs it for three different speakers through the game's own code, measures what the scheme saves, and follows the text to the screen.

The bytecode

RUN_MESSAGE walks the message a byte at a time (read):

The control codes, with their handlers read from the table:

And the common words, the byte that stands for each:

One message, taken apart

The message at $AF20 is one of the wounds a fight can print. Each element as RUN_MESSAGE reads it, and what the game printed while it was the element in hand -- probed at $72F4, where RUN_MESSAGE picks up the next element, and at PRINT_CHAR -- for three speakers: the player attacking Thorin with the sword, Thorin attacking the player with it, and the warg attacking the wood elf bare-handed (so there is no instrument's noun to print):

Whole, as the three printed it:

• you to thorin: “you brandish your sword, but thorin is on guard.”
• thorin to you: “thorin brandishes his sword, but you are on guard.”
• vicious warg to wood elf: “the vicious warg brandishes his, but the elf is on guard.”

Each was started at the beginning of a story line. Where the next word would have passed the 42nd column, PRINT_WORD began a new line before it -- the (new line) in the table -- and the full stop that ends the message is followed by one too.

9 elements, 11 bytes. The same bytes say YOU or THORIN, YOUR or HIS, ARE or IS; and the verb agrees with its subject: PRINT_WORD adds an ending when the sentence is about someone other than the player (ACTING ($B6EA) not zero), if the word allows one (bit 7 of its second dictionary byte) and its flags do not forbid it: $40 always inflects, $50 never, $10 agrees with the target instead of the actor, anything else with the actor.

Endings and articles

The ending is named by bits 5-7 of the word's third byte, from ENDINGS; the fourth is how CARRY becomes CARRIES -- a backspace takes the Y back off:

A noun's reference carries its article (ARTICLE): bit 7 marks a proper name, printed with no article and a capital (except YOU); otherwise bits 4-6 pick one of four from ARTICLES -- or, in the input window and while an action is being narrated, from the second four, which say THE for everything but SOME:

Sentences about actions are not stored at all: NARRATE_ACTION builds them from the action's pattern (see How a sentence is understood), which is why the characters' doings read so alike.

What it saves

Measured over all 177 stored messages, $AD7D on, walked by the build's decoder (the same tests RUN_MESSAGE makes): 2397 bytes hold 611 word references, 413 common-word bytes, 526 literal characters and 227 control codes. Spelled out, the fixed text is 5645 characters with its spaces -- 3560 from the references, 1559 from the common words and 526 literals -- so 2.4 characters to the byte before any name is printed. Run through RUN_MESSAGE itself with the player speaking, the 159 messages that do not print something a caller pushed (18 do) printed 5898 characters from 2259 bytes: 2.6 to 1. A room or object name costs six bytes -- three references -- however long its words, and there are 80 rooms and 61 objects. The word list the messages draw on, SECOND_LIST, is reached by no index at all: a message names each word by its offset.

Six places inside messages are ways in of their own: five share another message's tail (the east bank of the black river is the end of the west bank's description), and one starts on the second byte of a word reference, which it reads as a control code.

To the screen: two windows

Everything goes out through PRINT_CHAR, which asks PRINT_GATE first: nothing is printed unless the action is for real (DOING_IT) and printing is on (the actor can be seen). Then INPUT_STYLE ($B701) chooses the window. The story goes to STORY_CHAR: row 17, in the game's own six-pixel font (FONT, drawn by NARROW_CHAR at any pixel, so 42 columns fit), every letter lower case except the first of a sentence, the whole window scrolling up over the picture. The parser's replies, the prompt and the tape messages go to INPUT_CHAR: rows 19-23, in the ROM's font and capitals. The screen after the line followed on the parsing page and then XYZZY, drawn from screen memory:

The story above the wavy divider, scrolled up over where Bag End's picture was; below it the input window, with the prompt and the parser's complaint about XYZZY.

Line breaking. PRINT_WORD builds each word in WORD_BUFFER first and, if it would not fit on the line, starts a new one before it: words are never split (read, and visible above).

The pause. At the end of each story line STORY_CHAR counts down NO_PAUSE_LINES ($B716); while it lasts there is no pause, and once it is 0 the game polls the keyboard up to 32768 times before scrolling -- about 0.58 s by the instruction timings -- or less if a key is pressed. The main loop sets it to 9 before every line typed. Measured on the line followed on the parsing page, the time from the end of each story line to its scroll:

The first nine lines scroll at once; the first of them waited only for the ENTER the line was typed with to be let go. From the tenth, each line waits the full count.

What is confirmed, and what is not

• Run when this page was built: the element walk and the three renderings, the printed-character count, and the pauses.
• Read: the bytecode's grammar (proved by the build, which walks every message and checks that every pointer into them lands on a start or a known way in), the endings' and articles' choice.
• Not checked: EMPTY's ending, which would print EMPTYIES if the word were ever inflected; and which callers push the values codes $00, $01, $04 and $13 print.