The value ln(exp 1) yields the 40-bit result (81h 00h 00h 00h 01h), which is incorrect. Could it be possible, directly in the FP Calculator routine (offset 25: “ln”), to test whether the input is e and, if so, return 1 ? And perhaps also add new constants for e and ln(2)? PRINT LN(EXP 1) returns 1.

It is curious that there is an error in log₂(e), since this is equivalent to ln(e) / ln(2). ln(e) = 1, this results in 1 / ln(2) which in the LG ROM v1.08 returns the correct 40-bit value (81h 38h AAh 3Bh 29h). Therefore, the error must lie in the rounding performed when calculating ln(exp 1).

Visionary brilliance but especially from the ZX81 onward, development was carried out in a series of extremely short cycles, almost always driven by commercial urgency and minimal cost targets. With a bit more strategic planning, it could have been a “proto-ST/Amiga” two years ahead of their time.

Thank you so much for your comment and for the detailed explanations. It’s always a privilege to learn from someone who knows the Spectrum ROM architecture so well. The care taken to ensure precision perfectly illustrates the kind of engineering that could have taken the Sinclair line even further.

The processor executes just 2 iterations, but nothing stops us from increasing that count for greater precision. I wonder whether, in terms of the algorithm’s average speed, it is more advantageous to use a fixed number of iterations or to loop until the error falls below the target precision.

In Basic:
INPUT "X=";X
EXPO = INT(LN X / LN 2) + 1
MANT = X / (2 ^ EXPO)
LSB = EXPO - INT(EXPO/2)*2
IF LSB = 0 THEN GO TO 80
EXPO = EXPO + 1
MANT = MANT / 2
80 LET X0 = 0.6862915 * MANT + 0.34314575
X1 = (X / X0 + X0) / 2
X2 = (X / X1 + X1) / 2
ROOT = (2 ^ (EXPO / 2)) * X2
PRINT "SQR = "; ROOT

Regarding the SQR calculation, I'm also analyzing what was implemented in the Intel 8231 math coprocessor, widely used at the time with Z80. This processor uses Chebyshev polynomials for all derived functions, except for the SQR, where it uses a linear approximation and the Newton-Raphson method.

Thank you so much for the detailed explanation and in-depth insight into the behavior of the SQR function. I detected this Behavior because I'm trying to rewrite the Circle and ARC routines from the ROM, using Bresenham's circle algorithm, similar to the one used in the DRAW-LINE routine.

Recently I’ve been using this fantastic ROM and noticed that the new SQR routine uses mem-3 and mem-4 as scratch registers. Calling it mid-calculation will corrupt any user data stored there unless explicitly saved/restored. No internal backup is performed. Is this behavior expected?

But isn’t that basically a bug in the original arcade? The effect looks pretty weird. Still, your attention to accuracy is remarkable.

That’s impressive work! Do you have a place where we can download or try out your version of the program?