Concluding my series about Dark Tower and the chip family that powered it…

Unlike the first-generation TMS1000, which had 32 bytes (bytes, not kilobytes!) of RAM, the unit in Dark Tower, the TMS1400, had twice that: 64 bytes of RAM. As perspective, this single sentence using ASCII takes 64 bytes!

Reverse Assembly

Gazoxtahagen summarizes:

Sean Riddle has extracted the Texas Instruments TMS-1400 chip from a Dark Tower (it turns out the Dark Tower is just kind of a fancy calculator) and has dumped the contents of the ROM online. From there, a fellow named Brett Wyer modified a known TMS-1000 disassembler, ran things through the MAME emulator for live debugging (MAME supports these TMS chips, because of course it does!), and long story short, we now have access to the actual Dark Tower code, which Wyer has annotated with comments.

Memory Map

Bytes weren’t the basic unit of the TMS1000 family: nybbles were. Nybbles are half-bytes, consisting of four binary digits.

So, in Dark Tower, the amount of gold, food and warriors that a player has are stored as two-nybble BCD (Binary-Coded Decimal) representations rather than as traditional binary numbers. The same with the amount of gold and warriors the dragon has, the price of goods in the bazaar, how many brigands are being fought or live in the Dark Tower. Bret Wyer has prepared a complete memory map, as best he could reverse-engineer it:

Dark Tower memory map

Source: Brett Wyer, https://github.com/ratsputin/Dark-Tower/tree/master

There is a lot that is not in this memory map. As a result, the game couldn’t enforce everything. For instance, the console had no knowledge of the territories on the board, so you could skip from the bazaar to the tomb or sanctuary just by pressing the button, as if they were adjacent (they never are). (Yes, I sometimes cheated as a kid.) Two of the spaces had the same meaning “Tomb/Ruin” and “Sanctuary/Citadel”. You weren’t supposed to visit any citadel but your own. Again not enforced by the tower.

Nor did the tower track if you had a Pegasus token (if it awarded you a second one, you weren’t supposed to take it). The first inventory flag tracked if you had the scout, sword, healer, or beast. No Pegasus. The second inventory flag tracked which keys you had.

Combat

You could encounter brigands when moving through an empty square, when exploring a tomb or ruin, and when attacking the Dark Tower. The number of brigands in the Dark Tower was random but based on difficulty level. Outside the Tower the number was random but similar to how many warriors you had. If you had 10 warriors, you were never going to be attacked by 60 brigands.

Dark Tower’s combat system was unique. Immediately obvious to the player: whenever your warriors lost, one warrior would be killed; whenever the brigands lost, half the warriors would be killed. That said, outnumbered warriors or brigands could win.

I never had figured out how combat worked. I’d even recorded a bunch of combats to a notepad, trying to figure it out.

Some of the hypotheses were interesting from other people trying to reverse engineer it. A Java implementation used the following: “This basically takes the proportional delta between the Warriors and Brigands, and scales them up and down from a 50% victory with the same number, to a best-case Warrior percentage of 75% and a worst-case of 25%.”

It wasn’t until Gaxotahagen analyzed the code that we found the real answer. Multiply the number of brigands by a random number from 1 to 4, then do the same for the number of warriors. Award ties to the human.

Haggling

Haggling was described in the manual as being 50/50, but actually haggling had a 75% chance of working the first time, then 50/50, unless the price was at 1, in which case haggling failed 100% of the time.

Conclusion

Dark Tower captured the imagination of a generation. Many of us were inspired to program apps like it or to study it in detail. The community has worked together to finally decipher the last of its secrets.

See also:

Photo Credit: Rick Burbage