TOWER OF HANOI
by Kenneth Baker
from ZX Computing Feb/Mar.1985

[This article was originally printed in the Oct/Nov.1984 issue, but]
[the machine code hex dump listing was not printed. As the program ]
[is written entirely in machine code this introduced a fatal flaw  ]
[into the proceedings ...                                     JimG.]

Kenneth Baker of Southampton has written the ultimate
version of this game in machine code for the 16K ZX81.


Invented about 100 years ago by the French mathematician
Edouard Lucas, The Tower of Hanoi is perhaps the most
fascinating and enduring of all puzzles. The object is to
transfer the six parts of the Tower from position 'A' to
position 'C' in the least possible moves, and without ever
placing a larger block upon a smaller one. Position 'B' is
used throughout as a temporary store.

To transfer a block from 'A' to 'B', simply input AB. If the
move is valid the transfer will be made, and the score
incremented by 1. The program is designed to reject any
illegal moves.

In this six-tier version of the puzzle, the least possible
moves is 63, and the maximum allowed is 99 - when the
computer will decide that the player is doing so badly that
it will automatically call a restart to the program. Restart
can be called at any time by pressing 'R', and the only
other active key, apart from the transfer keys ABC, is 'F',
which will clear the program from memory.

To put the player on the right track, the first few moves
are AB AC BC ... but to say more might be to deprive the
player of hours of hair-tearing frustration.

At the end of each game a caption containing a suitable
comment as to the status of the final score will appear on
the screen. Please remember that the least possible moves is
63.

The program is written entirely in Machine Code, which must
be entered most carefully. The code is arranged in 139 lines
of 11 HEX pairs: the first nine pairs representing the
actual code, whilst the last two contain a checksum which is
an addition of the code values in the line plus the line
number. In this way, if any line should contain an error, or
even if the wrong line is entered by mistake, it will be
rejected with a request for the line to be re-entered.

Each line of 11 pairs should be entered together as a
string, with one space between each pair. It should be
noted, particularly if any other method of input is used,
that the last two pairs are NOT instructions.


Making Space

The biggest problem with entering large Machine Code
routines into the ZX81 is being able to create large enough
REM statements in order to store them. The method chosen
here is to form a REM statement of 120 characters in Line 4,
and duplicating it 9 times in Lines 5-13 by the following
method:

4 REM xxxxx(120 characters)xxxxx
EDIT
Change the Line No. to 5
Press N/L
EDIT
Change the Line No. to 6,
and so on, until Line 13 is reached.

The size of Line 4 is then adjusted to encompass the 9
ensuing lines, which will result in a REM statement with the
required number of 1254 bytes. When a REM statement is
created in this way, it is most important to stabilize it
with the addition of at least one line afterwards - hence
the apparently redundant REM in Line 14 of the program,
which must be left in tact when the HEX LOADER is deleted.

Purely by the way, should you wish to use this technique in
your own programs, the number of bytes per number of lines
can be found by using the formula: ((C+6)/L)-6 where C = the
total characters required, and L = the number of lines. To
avoid fractional answers, the odd byte or two can be added
to the total characters. The best way to determine the
number of lines is to factorize (C+6), again adding the odd
byte until a convenient balance is reached. The length of
the first line is then poked with (C+2).

When the code has been successfully entered, lines 15 to 55
can be removed, and the final instruction, before saving and
running the program, is to POKE 16543,127; this will make
the REM statement invisible, but can be omitted if my flair
for cosmetic surgery is not to your taste.


--
Another Fine Product transcribed by:
Jim Grimwood (jimg@globalnet.co.uk), Weardale, England
--
