Ive noticed TTFn has a few ZX80/81 programs that arent in the standard .O
and .P formats, so I thought I would convert them as appropriate so that
they can be used with the widest range of emulators. Ive attached new
versions of each program, although for some it was only necessary to rename
the file extension. [ PF ]

.Z81
Ive converted snapshot files in .Z81 format to .P format:
- YC8208w208EcologicalModelling.z81
- SP8209w003014TreasureHunt.z81
- HW83073020025Dodgem.z81

The .z81 snapshot format saves a dump of the entire ZX81 memory, which is
quite wasteful (resulting in larger files) and would only be useful if the
program held data in RAM that SAVE would not access, e.g. data above
RAMTOP. However, none of these programs do that and so there is no
advantage using .Z81 over .P format. In fact, it could prove a disadvantage
since the snapshots includes the stack and these might contain return
addresses into the BASIC interpreter in the ROM. Since there were 2
editions of the ZX81 ROM (let alone clones machines of the ZX81), such
addresses could differ between them and so the snapshots might only work
with one ROM version or the other (I havent tested for this issue). The .P
format does not suffer from this problem and so is more portable. [ PF ]


--


All The Fun Of The Fair

Recreate the thrill and skill of the shooting gallery
with Jack Knight's game for the Spectrum.


The scene is a fairground booth, with a gaily striped awning at the top and a
red counter with Shooting Gallery emblazoned on it in gold. Inside, nine
light-coloured balls are bobbing up and down on air jets  and the game is to
shoot them off.

On the counter is your rifle sight, which can be moved under the air nozzle
of any ball. The pointer can be moved on the sight to represent the position
to be fired at. You're got 10 shots for your money, so take aim and fire.
Sounds easy? Try it!

You aim using the cursor keys, and use zero to fire. A counter displays the
score and high score. If you want another game, just clear the screen, and a
new game should start almost immediately.

My main problem in designing this game was how to stop a ball, once
destroyed, from reappearing. This was overcome by using DIM, and changing the
appropriately-numbered string in the PRINT statement from a ball graphic to
a blank space.

The only user-defined graphics used are for the balls and one of the five
parts of the main sight. I've converted the binary numbers to decimal to
save the tedium of BINing. The balls are GRAPHICS + A; the parts of
the rifle sight, GRAPHICS + B.


Variables
a,b,c     line positions of the balls (3 to a variable)
aa,bb,cc  allow for a, b,c to be +1 or -1
e         column position of rifle sight
g         line position of pointer
DIM q()   identifies the individual ball (for removal from game)
s         score
j         shots
k,l,m     store previous ball position for the blotting-out
d         random reversal of balls
i         avoids a series of e+l's
n,p,q     control variables
p


How it works
REM statements clearly identify the component parts
 100-220   continuously print (and blot out) the balls, reverse their
           direction at top and bottom and, where specified by RND, use
           INKEY$ to jump to sub-routines.
 400-470   count number of shots and if 10 exceeded jump program to end;
           check by ATTR whether a character space fired at is empty;
           if not there must be a ball there, so reduce the bal string to
           nil, increase the score and, if the maximum of 45, jump to the
           end routine.
 700-830   set the scene, make provision for score and high score.
1000-1800  assign variables.
1900-1920  print the rifle sight and pointer in a sub-routine to avoid
           re-printing each time the main loop is gone through.
2000-2600  create the graphics, assigning the ball to A and the part of the
           rifle sight to B.
3000-3300  at game end print comment on the score.
4000-4800  offer a new game and, if accepted, deal with high score, clear
           the screen as necessary, take the program through the variables
           and the sight and pointer re-printing, to the main loop.


Hints on conversion
There should be no problems in conversion after a study of the documentation
and the listing.

--
from Home Computing Weekly, 19th July 1983



DODGEM
by Ian Beynon
from Home Computing Weekly, 19th July 1983

How long will you survive?
Dodgem is addictive, challenging  and fast, thanks to machine code. And
it's not as daunting to type in as it looks, if you follow Ian Beynon's
tips. You'll need a ZX81 plus RAM pack.

The idea of Dodgem is 10 survive for as long as possible without hitting
any of the obstacles which appear in your path. You also leave a deadly
trail of waste fuel wherever you go which must not be touched at all costs.
You can move either up, down, left or right using the cursor keys and have
three lives. Sounds easy? Well just try it! Any score over 1,000 is pretty
good.

Dodgem runs on any ZX81 with 4K of RAM or more due to the method used to
POKE characters onto the screen. The actual game is written entirely in
machine code and stored within a REM statement at the beginning of the
program.In order to enter Dodgem first of all type in the following
program, making sure line 1 is at least 390 characters long as this is
where the machine code is going to be stored.

1 REM ..(at least 390 characters).....
10 POKE 16510,0
20 FOR N=16314 to 16903
30 INPUT A
40 POKE N,A
50 SCROLL
60 PRINT N,A
70 NEXT N

When you have entered the above program. RUN it and enter the decimal
numbers provided in Listing 1. The five-figure numbers on the left should
not be entered as these are the addresses of where the numbers are being
stored.

Enter each line of numbers in turn starting from the top and working from
Left to right remembering to press NEWLINE after each number (ie 0 (N/L) 33
(N/L) 34 (N/L) etc.) If you should happen to enter a wrong number make a
note of the address at which the error occurred and then correct it
afterwards with a direct POKE command (eg if address 16706 should have
contained 238 then enter POKE 16706,238)

When you have finished entering the machine code immediately enter the
program in Listing 2.

Before you RUN the program you should first SAVE it just in case you have
programmed in an error which will probably result in a crash.

If this does happen then use the machine code loader program with lines 30
and 40 deleted and line 60 changed to PRINT N, PEEK N to check through your
entries - Any mistakes should now come to light and can be corrected.

Memory locations of interest include;
16522 speed of game (normally 10, 1 = impossible 20 = slow)
16515 character code for left key
16516 character code for down key
16517 character code for up key
16518 character code for right key

POKEing location 16515 enables you to define your own keys for the game.
For example, if you wanted X to control your downward movement then enter
POKE 16516, CODE "X".

The only two variables used in the game are those that keep track of the
score and high score. The high score is contained within the BASIC variable
HS while the current game score, which is updated by part of the machine
code, resides in memory Locations 16519 and 16520 and is evaluated by the
expression:

PEEK 16519 + 256 x PEEK 16520.

Program by Ian Beynon
Published in Home Computing Weekly (19th, July, 1983)