PLANE ANNOYING for Sinclair ZX-81
by Kriss Buddle
from Your Computer, January 1984

Kriss Buddle taxes your thinking and perceiving facilities with a
tantalisingly mind-blowing puzzle for the ZX-81. A worthy rival for
Rubik's Cube.


[This is a good idea, but spoiled by the shambles of a BASIC listing ]
[printed in the mag. I had to hack it around a bit to get it at least]
[working, but it's still not very satisfactory.                  JimG]
[Found a correction in the Feb'84 issue, page 45:                    ]
["Lines 500 to 600 in the ZX81 Plane Annoying program, January, have"]
["been corrupted. The correct lines are given below."                ]
[(Now included in program.)                                      JimG]


Some time ago, before taking my first plunge into the world of machine
code, I played a pub Pac-Man machine and was startled to find myself
suddenly faced with one side of a scrambled Rubik's Cube and being
told to sort it out! You probably know the one I mean. This gave me
the idea for a slightly more complex game, based on the Cube.

Having sweated over a Basic program I found it to be slow and
requiring vast amounts of memory. I therefore decided that machine
code was the only answer. During the time it took me to translate the
original program the inevitable happened - someone released an almost
identical game for the Spectrum. However, it is still a good game and,
as I have never seen a ZX-81 implementation, here it is in all its
glory.

Basically you are presented with a 16x16 plane, each 8x8 corner of
which is composed of a different character. You may choose how many
smaller squares the plane is to be split into and also have the choice
of an easy or a difficult mode to play in. [There is no explanation of
how to do this in the program. JimG]

The machine then scrambles the plane by randomly scrolling rows and
columns, thus mixing up the characters. Your not inconsiderable task
is to restore the plane to its original pattern. If you manage to do
this you are given the number of moves it took. The whole object is to
take as few moves as possible.

The machine code section occupies 652 bytes, so you will have to
create a REM statement followed by at least 652 Xs or any other
character. To check that you have the correct number of bytes in the
REM type:
	PRINT PEEK 16511+256*PEEK 16512-2 (+NEWLINE)
This should give a value of 652 or more. If you obtain less, then keep
on typing. FAST mode is less tiresome.

Having reserved the space, use one of the many hex loaders, previously
published in this and other magazines and books, to enter the code in
the hex dump. Remember there are no spaces between the pairs of digits
when entering the code.

The machine code has been written in the form of a series of sub-
routines, each performing a specific task. Not only does this make
debugging easier - especially without the help of an assembler,
compiler or monitor - but also simplifies the disassembly and
understanding of the code.

The main module is a keyboard scanner which calls the ROM routine at
02BB (hex), decides which key is being pressed and then calls the
relevant subroutine.

The decimal addresses in Listing 1 mark the beginning of each sub-
routine in the program and by PEEKing these addresses the following
values should be obtained, thereby proving that the code is probably
correct:

	16514 - 118
	16618 - 205
	16677 - 42
	16718 - 42
	16771 - 42
	16807 - 42
	16850 - 237
	16887 - 237 [see note]
	16951 - 237
	16997 - 237
	17042 - 42
	17121 - 6
	17134 - 33
	17160 - 62

[Note: The byte at 16887 is E1, which is 225;]
[the nearest ED (237) is at 16880.       JimG]

If all these values are correct then delete the hex loader line by
line and type, as a direct command:
	POKE 16510,0
This will give you a non-erasable REM line. Then SAVE the REM
statement to tape as a precaution.

The Basic part of the program is a lot friendlier than the machine
code. [Hah! JimG] Keeping your REM statement in memory, type in
Listing 2 as written and again SAVE the entire thing to tape by typing:
	RUN 5000 (+NEWLINE)

The program should now auto-run and the invitation to see the
instructions or play the game should be on the screen. Until you have
actually seen the plane the instructions could be a little confusing,
unless you have a vivid imagination, hence the short demonstration at
the end of the instruction pages.

The puzzle is simple to play but difficult to describe and to finish.
The demonstration is in easy mode where the cursors control individ-
ual rows and columns on the plane.

In difficult mode the cursors are twice as wide and can only move
adjacent pairs of rows and columns, but still maintain the smaller
units into which the plane has been split. I said it was easier to
play than to explain.

Lines 290 and 2000 are identical and very important. Not only do they
provide a visual clue as to which corner the characters belong in, but
the machine code uses them to prevent the cursors running off the
screen and causing an irrevocable crash.


Variables

A$  Holds various messages and is used to store values in string form
    for use in several parts of the program.
I$  Used as input from player and temporarily holds option choices.
X   Holds the size of division selected by the player.
L   Used to call USR routines (LET L=USR ...) instead of RAND USR, as
    that way a randomness is preserved, otherwise the random numbers
    always start from the same seed.
N+F Loop control variables.

