ZX Computings - OpenLibra

I first became aware of the bug
in the Sinclair 8K ROM after
writing a fairly fast BASIC program
to obtain the smallest
prime factor of any odd number
up to 2 32 - 1 in a matter of
seconds rather than minutes.
When I tried the program out on
2 32 - 5, the largest prime
number in this range, it seemed
to be taking a long time to run.
On breaking in and checking the
divisor, I found that it had gone
well past the square root of the
number (about 65536). On
checking the square root, I
found that the ZX81 was
holding a 12 digit number {instead
of 65536) as the square
root of the 10 digit number
2 32 - 5.
Further investigation revealed
errors in exponentiation and
even in subtraction. In the
event all these errors were to
trace back to a programming
mistake in subtraction. To see
how they arose, it is best to
follow a simple example
through to its source.
The ZX81 gives SQR {%)
correctly as .5. But SQR .25 is
given as 1.3591409. Listing
the ROM shows that SQR X is
evaluated as X**.5. The instruction
"PRINT .25**.5"
gives the same wrong answer
1.3591409. The function
X**Y in turn is evaluated as
EXP (Y • LN X). The instruction
"PRINT LN .25" returns the
answer 0.61370564 instead
of - 1.3862944. Two has
been added to the correct
answer. At this stage we could
well suspect that addition is at
fault.
The last stage of detection
requires one to split the LN
routine in two, by uploading it
into RAM and running it there.
Happily this works. At least the
first half runs and that is all we
need. To evaluate LN X the
ZX81 has to add the log of the
exponent and the log of the
mantissa of X. In the case of
.25, the log of the exponent is
correctly evaluated as - 2 log
insight
Frank O'Hara looks at the bug in the
original 8K ROM, and explains how it
occurred. He reveals a new bug which
only comes to light when running a
zx printer, and gives a checking
routine which prints the powers of
two from two squared to two to the
32nd, exactly.
2. The log of the mantissa
should then yield zero. But .25
is held approximately on the
ZX81, unlike (%), which is held
exactly. The result of this is that
log of the mantissa comes out
as - !6 32 , an approximation to
zero. Finally, the sum of - 2 log
2 and - Vi 32 adds two to the
correct answer because of the
bug in subtraction.
This brings us to the source
of the bug in subtraction.
Because subtraction just
changes the sign and adds, it
will help to think of simply adding
on a negative number, (n
floating point addition, the addend
(ie the number being added
on) has to be lined up with
the other number (the
"augend") to make the addition
possible. If the addend is
too small to make any ap-
10 FOR R=0 TO 31
20 LPR INT RT 1.. R . .0P0P65
30 NEXT R
10 PRINT RT
FROM 1 TO
20 LET N = 1
2,. 3;
32" ,
POWERS OF" J?
30 FOR X = 1 TO 32
40 LET N=2*.W
50 LET R = INT (N./10P.1
60 LET B=N-1O0*R
70 PRINT " " RND X