Getting started · The game · The tape · The code · Findings
What is still open, keeping MEASURED and ASSUMED apart. What is measured carries its measurement; what is assumed is labelled as such and has not been written into the listing as if it were a fact.
0xBD00+n means "carries the Ring". What is measured is that 0x733E looks for the first unit with that bit, that the game loop checks whether that unit is on (0x68, 0x3F), and that it decides victory (0x7F7D) and defeat (0x9218). Everything points the same way, but the binary does not say it in so many words.0x16 and 0x17 are Sauron and Saruman. The chain is long: 0x72FD stores the bearer and does inc a to mark the row, and 0x7314 does dec a on the way back; so row = unit + 1 and row 0 is "Vuelve", making unit n the *n+1*th name in the list at 0x6B46. Counting gives Gollum, Sauron and Saruman. It fits with 0x6AE3 skipping exactly those two when painting armies, and with 0x7514 (choosing an enemy) accepting exactly {0x16, 0x17, >= 0x78}. It is a deduction, not a direct reading.0xB8E8-0xC600 and 0xE400-0xE678 are delimited and we know who reads them (0x6AC2, 0x6EAC, 0x8F7A, 0x92E4, 0x81A9, 0x8189, 0x7FF0), but they have not been broken down field by field. 0xB900 is called X and 0xBA00 Y because 0x8108 multiplies the first by 102, which is the column stride, and 0x8166 walks columns in the outer loop; that is consistent, not proven.
Partly closed. Reading the machine's decision code (see The machine) named several of these strips for good: 0xBB00/0xBC00 is the destination, 0xBD00 the troop type in its low nibble, 0xC200 the number that walking spends, 0xC500 how many figures the piece puts on a battle board and 0xC600 its state. And the index into all of them is the same index as the name list at 0x6B46, which BUSCA_EL_NOMBRE (0x6981) walks with the unit number: that is what makes piece 0x16 Sauron and 0x17 Saruman, and it matches the five places where the code singles those two out. What is still open are the high flag bits of 0xBD00 beyond bits 4 and 5, and the strips 0xC000, 0xC100 and 0xE600.
Drawing the map takes three passes. The second (0x7714) indexes 0x77B5 with the same low nibble the terrain pass already used (0x7687), and what it contributes could not be established.
The third pass of 0x7708 only paints if that bit is set. It is set from 0x8F70, 0x8044 and 0x80BD, but on what criterion was not settled.
0x6A76-0x6A94 takes the operand of 0x8333 — the month countdown, set to 255 at 0x7F4F — stores it multiplied by 16, and puts its high nibble minus one into the low nibble of 0xC000+bearer. With 255 in there, that leaves the countdown at 240 the first time and at 0 the second. Either it is a deliberate penalty, or that byte has a second use nobody has worked out. It is commented by describing what it does, without interpreting it.
0x9144 reads what 0x904D has just clearedIn the same routine, a few instructions apart: 0x904D zeroes 0x5E00+0x4FF — 0x6010 included — and 0x9144 then does ld hl,0x6010 / ld a,(hl) / ld (0x8B19),a. Either it is meant to read the battle board, or it is a Spectrum leftover where that byte lived somewhere else. The mechanism is commented, not the intent.
0x86AF works out 19 rows of tiles (ld c,0x13 at 0x86CC) but the drawing loop does 16×16. Three rows prepared and never seen.
They currently sit inside textos_de_los_paneles and deserve names of their own: 0x83F8-0x83FB, the four two-bit fills (00, FF, AA, 55), and 0x846F-0x8496, the five terrain textures 0x80BD picks from.