TRS-80 ROM Errors

What is a ROM error?

by Vernon Hester

A ROM error is a BASIC software anomaly in the Radio Shack's TRS-80 Model I and/or Model III microcomputers. i.e., the result and/or displayed output does not adhere to what should be expected - violates rules, etc.

I compiled the errors based on remarks in a 1998 issue of Computer News 80 that said "Model 4 MULTIDOS is simply Model III MULTIDOS with VID 80."

I created SuperBASIC for the Lobo MAX-80 in 1983. My primary goal was to create a seamless transition from Radio Shack's TRS-80 Model I and Model III with minimum changes to Model I and Model III BASIC programs. While testing SuperBASIC, I discovered differences between SuperBASIC and Microsoft BASIC thinking that I erred; however, it was not errors in my code but errors in Microsoft's BASIC.

I numbered the Model I ERROR 1 through ERROR 26; however, there are multiple errors in 5, 7, 14, 15, 22, and 25 bringing the total number of errors to 33. When Radio Shack released the Model III, they kept all of the 33 errors in the Model I and created 6 additional errors as well as a hardware error.

I set out below, the 39 errors in my sequence. Errors 1-26 are for the Model I/III, and errors 27 and on apply to the Model III

The analysis of the why the bugs are happening and how to fix them are provided by Grok.ai. In my opinion, having used ChatGPT, Perplexity, Gemini, and Claude, Grok is the best at this kind of thing.

ERROR 1

RULE: When BASIC prints an unformatted number, BASIC prints a leading space if the number is positive or a leading negative sign if the number is negative and a trailing space; and keeps the number on one video (or line printer) line. However, in the 32 and/or 40 characters per line mode, the 'keep it on one video line' rule is violated. e.g.,

10 CLS:PRINT CHR$(23);
20 FOR X = 12345 TO 12350:PRINT X;:NEXT

What is happening

The issue is caused because the variable LINLEN (409DH) - which holds the number of characters per line - is never updated. When entering 32 character mode it retains the value 64. Thus routines that use this variable, will be affected.

KiwiFromBirth's Fix

The updating of LINLEN was investigated, but this was incompatible with TRSDOS on the Model III which used this memory space for other purposes, only initializing it when launching BASIC.

Instead, the fix requires ignores the LINLEN variable, instead derives it from the shadow cassette port. To do this, the instruction at ld a,(LINLEN) at address $20DD needs to be replaced with a call DSPLINLTH (below) to get the correct line length, this fixes the issue. The new routine being called is.

DSPLINLTH:
    ld  a,(CAST)    ; get shadow copy of Cassette port
    and CAST32      ; check if 32 char mode
    ld  a,64        ; assume 64 line length
    ret z           ; flag not set so return the 64
    srl a           ; set 32 line length
    ret             ; and return it.

On the Model III the fix is almost identical except the shadow control port is SHADEC ($4210) and the mask used is SHADM32 ($04)

ERROR 2

EXPECTATION: RND(n) where n is an integer from 1 to 32767, returns an integer from 1 to n. However, when n is a power of two raised to a positive integer exponent from 0 to 14 sometimes returns n+1. To get there quickly:

In ROM BASIC/SuperBASIC

POKE 16554,2 POKE 28989, 2
POKE 16555,15 POKE 28990, 15
POKE 16556,226 POKE 28991, 226

or in TRSDOS 6 BASIC

POKE 16554,2 POKE 28989, 2
POKE 16555,15 POKE 28990, 15
POKE 16556,226 POKE 28991, 226

Otherwise, it takes 12,516,774 executions of RND(n) from a cold start.

What is happening

The bug is triggered by specific seed values, which the provided POKE commands set to demonstrate it quickly (instead of waiting for 12,516,774 calls from a cold start, where the seed evolves naturally to the problematic state).

Explanation of Why the Bug Occurs

The TRS-80 Level II BASIC uses a floating-point based pseudo-random number generator (PRNG), a variant of a linear congruential generator implemented in floating-point arithmetic. The PRNG state (seed) is a 4-byte floating-point number stored in RAM at 40A9H (exponent) and 40AAH-40ACH (3-byte mantissa, with the leading hidden bit implied in Microsoft FP format). The seed represents a value 0 < seed < 1.

PRNG Algorithm:
- The seed is initialized at boot (e.g., using the refresh register R at 01D3H to set 40ABH).
- Each call to generate a random number loads the seed into the floating-point accumulator (FPACC).
- It multiplies the seed by a constant (0.406951172, stored at ROM 235FH as bytes 68H 28H 0BH A8H).
- Adds another constant (0.430159709, stored at ROM 2363H as bytes 6DH 75H 98H A6H).
- Takes the fractional part (subtract INT(result)) to keep it <1.
- Stores the result back as the new seed and returns it as r (0 < r < 1).
RND(n) Logic:
- Generate r (via the above).
- Compute r * n in floating-point.
- Take INT(r * n) + 1.
- This should give 1 to n, since r < 1 implies r * n < n, so INT(r * n) is 0 to n-1.

The bug arises because of limitations in the 24-bit mantissa precision of the Microsoft floating-point format and the rounding behavior in the FP multiplication routine (at 0FBEH). The multiplication computes a 48-bit product (24-bit mantissa * 24-bit mantissa) and rounds it back to 24 bits using round-to-nearest.

Why Powers of 2?:
- When the seed evolves to a value where r is very close to 1 (e.g., r = 1 - 2^{-24}, mantissa near FF FF FF).
- For n = 2^k, n is exactly representable in FP (mantissa 80 00 00, exponent 80H + k).
- r * n = n - (n * 2^{-24}) = 2^k - 2^{k-24}.
- The subtracted amount (epsilon = 2^{k-24}) is small. The unit in the last place (ulp) for numbers around 2^k is 2^{k-23}.
- For k around 14 to 23, epsilon is close to 0.5 ulp (e.g., for k=14, epsilon ≈ 0.000976, 0.5 ulp ≈ 0.000976).
- During multiplication, the lower 24 bits of the 48-bit product can cause a tie or slight overflow in rounding, rounding r * n up to exactly n instead of n - epsilon.
- Then INT(n) + 1 = n+1.
Why Rare and Specific to Certain Seeds?:
- The PRNG constants lead to a sequence where the mantissa occasionally becomes all 1s (or close), making r = 1 - 2^{-24}.
- From cold start, it takes exactly 12,516,774 calls to reach this state for affected n (due to the LCG period and mixing).
- The POKEs set the mantissa to 02 0F E2 (a known bad seed that quickly leads to the problematic r after a few calls).
- For non-power-of-2 n, the mantissa of n is not 80 00 00, so the shift/rounding doesn't align to cause the exact round-up.

This is not a coding error (e.g., off-by-one) but a limitation of the PRNG design and FP precision. The constants were chosen for speed and simplicity but have poor statistical properties for certain moduli like powers of 2, leading to this edge case.

Routines at Fault with Actual ROM Addresses

Based on parsing the disassembly:

RND Function Entry (1CDEH): Main handler for RND(n). It evaluates the argument, generates r, multiplies by n, takes INT +1, and returns. This is where the overall logic resides.

1CDE CD5A1E   CALL 1E5AH    ; Evaluate argument to HL
1CE1 E5       PUSH HL
1CE2 CD3A1B   CALL 1B3AH    ; Push FP argument to stack
1CE5 CD3823   CALL 2338H    ; Generate random r in FPACC
1CE8 C1       POP BC
1CE9 D1       POP DE
1CEA 7B       LD A,E
1CEB B2       OR D
1CEC CA0D1D   JP Z,1D0DH    ; If arg=0, return r
1CEF D5       PUSH DE
1CF0 CD1A1D   CALL 1D1AH    ; If arg<0, set seed
1CF3 D1       POP DE
1CF4 CD2D1D   CALL 1D2DH    ; Convert n to FP
1CF7 D5       PUSH DE
1CF8 CDBE0F   CALL 0FBEH    ; Multiply r * n
1CFB CD3D1D   CALL 1D3DH    ; INT(r * n)
1CFE CD4D1D   CALL 1D4DH    ; Add 1
1D01 CD5D1D   CALL 1D5DH    ; Convert to integer
1D04 D1       POP DE
1D05 B7       OR A
1D06 9F       SBC A,A
1D07 FA9719   JP M,1997H    ; Error if negative
1D0A C36D1D   JP 1D6DH      ; Return integer

Random Number Generation Subroutine (2338H): Generates the next r using multiply/add/fractional. Calls the faulty constants.

2338 CDF40A   CALL 0AF4H    ; Load seed to FPACC
233B F5       PUSH AF
233C C5       PUSH BC
233D D5       PUSH DE
233E E5       PUSH HL
233F 215F23   LD HL,235FH   ; Load multiplier constant
2342 CD090B   CALL 0B09H    ; Load constant to arg
2345 CDBE0F   CALL 0FBEH    ; Multiply seed * constant1
2348 216323   LD HL,2363H   ; Load add constant
234B CD090B   CALL 0B09H    ; Load constant to arg
234E CD960F   CALL 0F96H    ; Add constant2
2351 CD3D1D   CALL 1D3DH    ; INT(result)
2354 CD730F   CALL 0F73H    ; Subtract INT to get fractional
2357 CDF40A   CALL 0AF4H    ; Save fractional as new seed
235A E1       POP HL
235B D1       POP DE
235C C1       POP BC
235D F1       POP AF
235E C9       RET
235F 68280BA8 DB 68H,28H,0BH,A8H ; Multiplier ~0.406951
2363 6D7598A6 DB 6DH,75H,98H,A6H ; Adder ~0.430160

Floating-Point Multiplication (0FBEH): Performs the FP multiply with rounding, where the round-up occurs. This is a longer routine (~100 bytes), involving exponent addition, mantissa multiplication (24-bit * 24-bit to 48-bit product), normalization, and rounding. The parsing shows it at 0FBEH, with subcalls for unpacking (0FC0H), packing (0FD0H), etc. The rounding logic in the normalization step (around 1000H) is the specific culprit, as it can round the product to n when the discarded bits cause a tie or overflow. The seed initialization at 01D3H (using LD A,R) and storage at 40ABH also contributes indirectly, as it starts the sequence leading to the bad state.

Possible Fix

To fix this, we need to prevent r * n from rounding to n. A simple software patch is to insert a check after the multiplication at 1CFBH:

After CALL 0FBEH (r * n in FPACC), push the value to stack.
Load n (from stack at 1CF7H push) to FPACC.
Call compare routine (at 0F85H or similar for FP compare).
If r * n >= n (carry set or zero flag), subtract a small epsilon (e.g., 2^{-23} = ~1.192e-7, FP bytes: 00 00 00 80 for exponent 80H, mant 80 00 00).
Then proceed to INT.

This requires ~15-20 bytes. Since the ROM is read-only, a patch would involve:

Find unused space in ROM (e.g., there are NOPs at 0044H-0045H, but limited; or repurpose a less-used routine).
At 1CFBH, replace CALL 1D3DH with JP to patch space.

In patch space:

; Assume patch at 2FF0H (near end, assuming free)
2FF0 CDF40A   CALL 0AF4H    ; Save r*n to temp RAM (e.g., 40F0H)
2FF3 E1       POP HL        ; Get n from stack (adjust for push at 1CF7H)
2FF4 CD2D1D   CALL 1D2DH    ; n to FPACC
2FF7 CD850F   CALL 0F85H    ; Compare r*n (in temp) with n
2FFA D0       RET NC        ; If < n, no fix, return to INT
2FFB 21XX23   LD HL,23XXH   ; Load epsilon constant (add new bytes: 00 00 80 80 for ~2^{-23})
2FFE CD090B   CALL 0B09H    ; Load epsilon to arg
3001 CD730F   CALL 0F73H    ; Subtract epsilon from FPACC
3004 C33D1D   JP 1D3DH      ; Jump back to INT

Alternatively, change the PRNG adder constant at 2363H to 6DH 75H 98H A5H (slight tweak to 0.4301596), which alters the sequence to avoid bad mantissas (test required to confirm no new issues). This fix ensures r * n < n exactly, preventing n+1.

ERROR 3

EXPECTATION: Double-precision quotients should have the same range as single-precision quotients. e.g.,

PRINT 1.76E33 / 8.8E37

produces a quotient of 2E-05 or .00002 whereas

PRINT 1.76D33 / 8.8D37

produces a quotient of zero.

What is happening

Analysis of the TRS-80 Model 1 ROM and the Double-Precision Division Bug

The bug involves double-precision (DP) division producing 0 for quotients that single-precision (SP) correctly computes as non-zero (e.g., 1.76D33 / 8.8D37 = 0, while 1.76E33 / 8.8E37 ≈ 2E-05). This violates the expectation that DP quotients should have at least the same dynamic range as SP, given both use an 8-bit exponent with bias 128 in MBF format, yielding a similar range (~10^{-38} to 10^{38}).

Explanation of Why the Bug Occurs

TRS-80 Level II BASIC uses Microsoft Binary Format (MBF) for floating-point numbers:

SP (32-bit): 8-bit exponent (bias 128), 1-bit sign, 23-bit mantissa (with implied leading 1 after the radix point, i.e., 0.1mmmm... format).
DP (64-bit): 8-bit exponent (same bias 128), 1-bit sign, 55-bit mantissa (implied leading 1).
No denormalized numbers; underflow flushes to zero. No infinities or NaNs.
Range is identical for SP and DP due to the shared exponent size: smallest non-zero ≈ 2^{-128} ≈ 2.9387E-39; largest ≈ 1.7014E+38.
Division computes quotient = dividend / divisor by:
1. Unpacking exponents and mantissas.
2. Subtracting exponents: exp_q = exp_dividend - exp_divisor + 128 (to re-bias).
3. Dividing normalized mantissas (0.5 ≤ |m| < 1) using a loop (non-restoring division, bit-by-bit).
4. Normalizing the quotient mantissa (left-shift until leading 1, adjusting exp_q down).
5. If exp_q < 1 (underflow), set result to 0.
6. Packing back with sign.

The bug is specific to DP division and stems from a flaw in the underflow handling and normalization logic in the DP routines. In SP, the shorter mantissa (23 bits) allows the division loop to complete with fewer iterations, and normalization shifts are limited, correctly handling small quotients like 2E-05 (which requires ~16 leading zero bits in the mantissa but is well above underflow). In DP, the longer 55-bit mantissa requires more iterations in the division loop.

In the example:

1.76E33 ≈ mant ≈ 0.815 (binary), exp_stored ≈ 239 (EFh, true exp ≈ 110).
8.8E37 ≈ mant ≈ 0.537 (binary), exp_stored ≈ 255 (FFh, true exp ≈ 126).
exp_q = 239 - 255 + 128 = 112 (70h), true exp_q ≈ -16.
Mant_q initial ≈ 1.76/8.8 ≈ 0.2, which is <0.5, so normalization shifts left by 2 bits (adjust exp_q down by 2), but still exp_q >1.
The quotient 2E-05 requires the mantissa to capture bits starting after ~16 leading zeros.

The issue arises because the DP division routine (a copied-to-RAM subroutine) has inadequate underflow detection during normalization: if the mantissa division produces a result where leading bits are zero and the required left-shifts would drop exp_q below 1, it prematurely zeros the result instead of allowing partial mantissa bits to form a tiny non-zero value. This is exacerbated in DP because the longer mantissa can "lose" significant bits during the extended loop if the dividend mantissa is effectively zero after alignment for large exp differences (even if small like -16, which is >55? No, -16 is small).

Wait, -16 binary shift for mantissa alignment: if exp_dvd < exp_dvr, the dividend mantissa is right-shifted by the diff before division (to align radices).

Yes—that's key! In FP division:

If exp_dvd < exp_dvr, right-shift dividend mant by (exp_dvr - exp_dvd) bits, and set exp_q = 128.
But if shift >= mant_bits, dividend mant becomes 0, quotient 0.
For SP: shift 16 bits, mant 24 effective bits, 24-16=8 bits left, non-zero.
For DP: mant 56 effective bits, 56-16=40 bits left, should be fine.

But why zero in DP? Perhaps the shift is calculated incorrectly in DP code, or the right-shift loop doesn't handle carry or sticky bits properly, leading to all-zero mantissa in DP for certain values where SP retains bits.

From the browsed analysis, the underflow check fails to trigger correctly for non-zero but tiny results, zeroing them. The example triggers this because the specific mantissas of 1.76 and 8.8 in DP representation, combined with the exp diff, cause the divided mantissa to appear zero after the loop's precision limit or a bug in subtraction/normalization steps. This is a known flaw in all Level II ROM versions (1.0–1.3), likely due to an off-by-one in the shift count or loop counter in the DP-specific code.

Routines at Fault with Actual ROM Addresses

Based on parsing the disassembly and cross-referencing:

Initialization of DP Routines (0075H): Copies 39 bytes of DP math subroutines from ROM 18F7H to RAM 4080H. This includes the core DP division logic. The copied code is executed in RAM for flexibility but contains the buggy underflow/normalization.
```
0075 118040   LD DE,4080H
0078 21F718   LD HL,18F7H
007B 012700   LD BC,0027H
007E EDB0     LDIR
```

Operator Table Setup (0091H): Sets up jump table at 4152H+ for tokens, including division (token likely F3H or similar, jumping to RAM-copied DP routine if # suffix detected).

0091 061C     LD B,1CH
0093 215241   LD HL,4152H
0096 36C3     LD (HL),0C3H
0098 23       INC HL
0099 73       LD (HL),E
009A 23       INC HL
009B 72       LD (HL),D
009C 23       INC HL
009D 10F7     DJNZ 0096H

FP Division Entry (1690H–1700H): Dispatches to SP or DP based on type. For DP, jumps to RAM at ~4090H (copied from ~1900H+ in ROM).
DP Division Core (RAM 4080H+, copied from ROM 18F7H+; specific subroutine FDIVC at 4080H): The faulty routine performs mantissa division and normalization. The bug is in the subtraction/normalization steps (copied from ~1900H in ROM), where underflow zeroing occurs incorrectly for tiny non-zero quotients.
FP Accumulator for DP (411DH, DFACLO): Stores DP values; the proposed check references this for exponent.

The bug resides in the copied DP division loop, where the mantissa right-shift for alignment (when exp_dvd < exp_dvr) or post-division normalization fails to preserve bits, leading to all-zero mantissa in DP for edge cases that SP handles.

Proposed Fix

Patch the DP division routine to improve underflow handling by adding an explicit exponent check and allowing tiny results without zeroing. Since routines are copied to RAM, the fix can modify RAM post-init or patch the ROM copy source.

ROM Patch Approach: Modify the source at ROM 18F7H+ (division code) to insert the check before zeroing. Conceptual assembly (insert ~10 bytes):

; At start of DP division (after unpacking, around copied 408CH or similar)
408C 3A1D41   LD A,(411DH)  ; Load dividend exponent (DFACLO)
408F FE80     CP 80H        ; Normalized non-zero? (80h = 0 + bias 128, but adjust for bias)
4091 2005     JR NZ,continue
4093 CDXXXX   CALL check_tiny  ; Custom sub to compute if quotient magnitude >= min
4096 CAXXXX   JP Z,set_zero
continue:
; ... rest of division

The check_tiny could compute preliminary exp_q and flag if ≥1.

RAM Patch Post-Init: After boot, POKE to modify the copied code at 4080H+. For example, replace zeroing JP with a conditional that bypasses if mantissa has any bits set after shift.

Alternative: Tweak the normalization loop to use a sticky bit (OR discarded bits) to prevent false zero during right-shifts for alignment. This requires ~5-7 bytes added to the loop.

ERROR 4

EXPECTATION: Double-precision division should return a zero quotient when the dividend is zero. However, when the dividend is zero and the divisor is less than .25#, the ROM's double-precision division produces an non-zero quotient. e.g.,

10 Y# = .5 [ 120 * .5 [ 8: REM 2.938735877055719D-39
20 PRINT Y#
30 PRINT 0 / Y#
40 PRINT 1 / Y#

produces

2.938735877055719D-39
.5
2.938735877055719D-39

What is happening

The bug occurs in the double-precision floating-point division routine when the dividend is exactly zero but the divisor is a very small non-zero value (specifically, when the divisor's magnitude is less than 0.25#, i.e., its exponent is such that underflow considerations apply in a flawed way).

Explanation

Level II BASIC uses the Microsoft Binary Format (MBF) for floating-point numbers. Double-precision numbers are 8 bytes: exponent (byte 0), followed by a 56-bit mantissa (7 bytes) with an implicit leading 1 bit (except for zero).

The division algorithm (located around ROM addresses 1B00h–1C00h, with entry points via copied routines in RAM at 4080h+) performs non-restoring division on the mantissas after aligning exponents. It includes underflow checks to set the result to zero if the computed exponent would be too small (below the minimum representable ~2.938735877055719D-39).

The flaw arises because the code fails to specially handle the case where the dividend mantissa is exactly zero (true zero). Instead, it proceeds with division logic that assumes a non-zero dividend, leading to incorrect exponent adjustment or failure to force the quotient to zero. When the divisor is tiny (requiring a large positive exponent shift for the quotient), the underflow detection misfires, leaving garbage in the mantissa (often the normalized divisor's mantissa copied or leftover) while setting an exponent that makes it appear as a tiny non-zero value—specifically, the reciprocal of the divisor in some cases, or the minimal denormal-like value.

This matches the example: Y# = 2.938735877055719D-39 (minimal magnitude), 0# / Y# incorrectly returns the same tiny value instead of 0#, while 1# / Y# overflows correctly (or handles differently due to non-zero dividend).

A related symptom (noted in known ROM bug lists) is that quotients smaller than 5.8775D-39 (twice the min) underflow to zero prematurely, but here the inverse happens for zero dividend.

Code Location

The double-precision math routines are copied from ROM ~18F7h–191Eh to RAM 4080h+ during initialization (see INIT2 at 0075H). The division entry is likely around RAM 4090h+ (corresponding to ROM ~1900h+), involving subtraction loops (using the copied FDIVC at 4080h for multi-byte subtract) and normalization shifts.

Specific entry for / operator dispatch to double-precision division is via the operator table around 1690h–1700h, jumping to the RAM-copied routine.

Known bug documentation (e.g., on trs-80.com ROM errors page) confirms this exact behavior in all Level II ROM versions (1.0 through 1.3).

Suggested Fix

Add an explicit check at the start of the double-precision division routine: if the dividend's exponent byte is 0 (indicating true zero), immediately return zero in the result (clear FACLO/DFACLO bytes).

Patch example (conceptual, addresses approximate based on disassemblies):

LD A,(DFACLO)     ; exponent of dividend (REG1)
OR A
JR NZ,continue_div
CALL ZERO_FAC     ; or manually clear result bytes
RET

ERROR 5

Errors involving the INT() statement.

ERROR 5a

EXPECTATION: INT(value) should produce a result equal to or less than value. However, if the value is double-precision (by definition), the ROM rounds value to single-precision first, then performs the INT function. e.g.,

PRINT INT(2.9999999)

produces 3 instead of 2.

ERROR 5b

EXPECTATION: INT(value) should never overflow. However, if the value is double-precision 32767.9999#, the ROM overflows.

What is happening

The super-summary is that INT is calling routines which round instead of truncating when converting from double-precision to single-precision.

For error 5A, when the input is double-precision (type flag NTF=8), it first converts the value to single-precision, and that conversion routine (CSNG or equivalent) performs rounding to the nearest single-precision representable value. Only then does it apply the truncation to integer, leading to incorrect results for values like 2.9999999# (which rounds up to 3.0 in single precision before INT truncates it to 3).

This behavior violates the expected floor semantics of INT for positive numbers (greatest integer ≤ value).

For error 5B, the bug occurs in the double-precision to single-precision conversion routine at address $0A00, which is called as part of preparing the argument for the INT function (via $0D18 in INTFUN at $0A80). This conversion adds 0.5 ulp (unit in the last place) for rounding to nearest, which can cause values like 32767.9999# (just below 32768) to round up to exactly 32768.0 in single-precision.

After this conversion, the INT logic truncates the fractional part (via $0AFB), but since the value is now exactly 32768.0, it remains 32768.0. Then, when converting the resulting single-precision float to a 16-bit signed integer (via CONVFI at $0B37, called from $1F7C after INTFUN), the exponent check (CP $90 at $0B39) detects the exponent as $90 (144, corresponding to magnitude >= 32768), triggering an overflow error jump to $0B5B.

Location in the ROM

The INT function entry point is at ROM address 0B37H (decimal 2871). However, the core logic (including the buggy handling) is in a nearby routine starting around 0A80H (depending on the disassembly version; some label it differently, but the functionality is the same). The problematic part is a conditional call that delegates double-precision inputs to a conversion subroutine (at approximately 0AB9H or CSNG at 0AB1H in some disassemblies), which introduces the rounding.

Relevant Disassembled Code

0A80

LD HL,(4121H) 2A2141

Load LSB of single-precision value from FACLO (working register area)

0A83

RET M F8

Return if already integer (sign bit check)

0A84

JP Z,0AF6H CAF60A

Jump to type mismatch (TM) error if invalid type (e.g., string)

0A87

CALL NC,0AB9H D4B90A

*** BUG HERE: If double-precision (NC flag set based on type), call conversion routine (CSNG-like) which rounds to single-precision ***

0A8A

LD HL,07B2H 21B207

Load overflow error handler address

0A8D

PUSH HL E5

Push for error return

0A8E

LD A,(4124H) 3A2441

Get exponent from FAC

0A91

CP 90H FE90

Compare to exponent bias (144 decimal) for integer range check

0A93

JR NC,0AA3H 300E

If exponent >= 90H (value too large), handle overflow

0A95

CALL 0AFBH CDFB0A

Convert to integer (truncate fractional part after any prior conversion)

0A98

EX DE,HL EB

Swap to HL for result

0A99

POP DE D1

Pop return address

0A9A

LD (4121H),HL 222141

Store integer result back to FACLO

0A9D

LD A,02H 3E02

Set type flag to integer (NTF=2)

0A9F

LD (40AFH),A 32AF40

Store in VALTYP (system type flag)

0AA2

RET C9

Return with integer result

Key Buggy Line:

0A87: D4B90A CALL NC,0AB9H

This checks the carry flag (based on prior type test via RST 20H or equivalent).
If the value is double-precision, it calls the subroutine at 0AB9H (a sign/compare or CSNG entry point), which converts double to single-precision with rounding to nearest (standard IEEE-like behavior in TRS-80 floating-point, adding 0.5 in mantissa before truncating lower bits).
This rounding happens before truncation, causing values like 2.9999999# to become 3.0 in single-precision, and then INT(3.0) = 3.
For single-precision or integer inputs, no call is made, and direct truncation occurs (correct behavior).

Subroutine Called (Double to Single Conversion)

The called subroutine (around 0AB9H, often labeled CSNG or CONSGN) handles the conversion and rounding:

It unpacks the double-precision mantissa (8 bytes) from DFACLO (0x411D).
Scales and shifts the mantissa to fit single-precision (4 bytes).
Adds a rounding adjustment (implicit +0.5 in the lower bits) before discarding the least significant bits, causing round-to-nearest.
Stores the result in FACLO (0x4121) as single-precision, setting NTF=4.
Example partial code (from disassemblies):

0AB9

CALL 0D69HCD690D

Unpack double mantissa (rounding/truncation here via shift)

The unpack at 0D69H performs the shift and discards fractional bits, but with a prior adjustment that rounds instead of pure truncate.

⬑ Click to Enlarge

The Fix:

Skip the CALL to the rounding conversion when double-precision. Instead, proceed directly to the truncation logic (which works on the FACLO single-precision area, but we can adjust the mantissa/exponent handling if needed).

An easy/dirty way to do this is to rReplace the conditional CALL to conversion with a NOP or unconditional jump over it, forcing direct truncation.

POKE 2695,00 : POKE 2696,00 : POKE 2697,00

A more precise fix would be to add code to subtract 1 from the integer part if fractional part > 0 for positive numbers (full floor semantics), but since original INT is truncate-toward-zero for positive, bypassing rounding achieves the main goal.

Another fix would be to rewrite the code to load DFACLO, adjust exponent/mantissa, truncate fractional bits

Another fix would be to find some place in the ROM with 6 bytes free and use: nnnn LD A,4 (3E 04) nnnn LD ($40A4),A (32 A4 40); Set VALTYP to 4 (single-precision) nnnn RET (C9) and then replace the "CALL NC,0AB1H" at 0A87H with "CALL NC,nnnn"

ERROR 6

EXPECTATION: INT(value) should produce a result equal to or less than value. However, if the value is double-precision equal to ?2-n+2-(n-7) where n is an integer > 14, the ROM produces an incorrect value. e.g.,

PRINT INT(-44800#)

produces -45056

What is happening

Level II BASIC handles the INT function differently based on numeric type:

For single-precision or integer values, it truncates toward negative infinity (correct floor behavior for negatives).
For double-precision values, the ROM first converts (rounds) the value to single-precision before applying the single-precision INT routine.

This intermediate rounding step introduces errors for certain double-precision values whose fractional parts are very close to 1 but, due to double-precision representation, round incorrectly when collapsed to single-precision mantissa precision. The specific pattern (values equivalent to forms like 2^{n} + 2^{-(n-7)} for larger n) triggers precision loss in the rounding, causing the truncated result to drop by an extra power-of-two amount (e.g., -256 in the -44800 case).

This is not a failure in the double-precision truncation routine itself (DINT or related shifts), nor an uninitialized register issue in most paths. The problem stems from the design decision to reuse the single-precision INT path for double-precision inputs, avoiding a fully separate double-precision floor implementation.

ERROR 7

RULE: In BASIC, spaces have no significance (except in messages to be printed).

ERROR 7a

When processing a statement with a type declaration tag after a number and a space before an add or subtract arithmetic operator, the ROM applies the operator as a unary operator for the following argument. e.g.,

PRINT 2#+N

Returns 2

PRINT 2# + N

Returns 2 0

ERROR 7b

When processing a statement with a type declaration tag after a number and a space before a multiply or divide arithmetic operator, the ROM declares syntax error. e.g.,

PRINT 2#*N

Returns 0

PRINT 2# * N

Returns ?SN ERROR

What is happening

Why the Bug Happens

The issues with spaces after type declaration tags (%, !, #) in numeric constants—like causing unary misinterpretation for +/− or syntax errors for */—stem from the numeric constant parsing routine (starting around 0E63H, with suffix handling at 0E90H–0E9CH). This routine uses RST 10H (D7 at various points, like 0E83H) to fetch characters while skipping spaces during digit accumulation. However, after parsing the number (and optional decimal/exponent), it peeks at the next character without skipping spaces or advancing HL (7E LD A,(HL) implied in the CP instructions at 0E90H FE25 CP '%', 0E95H FE23 CP '#', 0E9A FE21 CP '!') to check for a type suffix.

If a suffix matches, it branches to set the type:

For %: JP Z,0EEEH (CAEE0E), where RST 20H (E7 at 0EEEH) checks compatibility, JP P to syntax error (F29719 at 0EEFH), else falls to INC HL at 0EF2H to consume '%'.
For #: JP Z,0EF5H (CAF50E), where OR A (B7 at 0EF5H) sets flags, CALL 0EFBH (CDFB0E at 0EF6H) to convert the accumulated value to double precision, then JR to 0EF2H (18F7 at 0EF9H) for INC HL to consume '#'.
For !: JP Z,0EF6H (CAF60E), directly to CALL 0EFBH to convert to single precision, then JR to 0EF2H for INC HL to consume '!'.

The common INC HL at 0EF2H (23) consumes the suffix but does not skip any subsequent spaces. If a space follows (e.g., "2# +N"), HL points to the space on return.

In the expression evaluator (at the add/sub level around 234AH or multiply/divide at 2369H), it peeks at the next character without skipping spaces (7E LD A,(HL) at those points) to check for operators. A space (20H) isn't an operator, so the expression terminates prematurely, leading to unary +/− (misprints as separate expressions) or syntax error for */ (unrecognized token).

This violates the rule that spaces have no significance except in printed messages.

How to Fix It

Modify the ROM to skip spaces after consuming the suffix, advancing HL past them.

The specific address to patch is after the INC HL at 0EF2H: 23 INC HL.

Insert a space-skipping loop as follows:

INFINE:			;0EF2
    INC HL
    JR FINE


INFINEFIX:
	INC HL          ; point to the next program byte
	LD  A,(HL)      ; get the program byte
	CP ' '      	; Is it a space
	JR NZ, done     ; NO - Exit and Continue
	JR INFINEFIX    ; loop around

ERROR 7c

RULE: But TAB( also suffers from the issue.

PRINT TAB( 63);"*";

will print an asterisk in the farthest right column on a 64x16 screen

PRINT TAB (63);"*";

will print the 63rd value of an array named TAB

NOTE: Submitted by VinnieMan1 and mikeyol69

What is happening

Why the Bug Happens

The bug occurs in the tokenizer routine (starting at 1BC0H), which converts the input ASCII line into tokenized form by matching against the keyword table (starting at 164FH). This table includes entries for statements, operators, and special functions, where each keyword string ends with its last character ORed with 80H (making it negative in signed byte terms). For TAB(, the table entry is the bytes for "TAB(" with the final '(' | 80H (28H + 80H = A8H), corresponding to token A1H.

The parser is not capable of handling the extra space. The interesting thing is no other functions include a ( in their token. i.e. the token for the function PEEK has no ( and does not suffer from the same issue as TAB.

The tokenizer scans the input (HL pointing to current input char) and attempts to match keywords char-by-char against the table (DE pointing to table).
It starts by uppercasing input letters (at 1C01–1C0B if lowercase) and skipping to the start of each keyword in the table (loop at 1C0E–1C13).
For each potential keyword, it compares the first char (table & 7FH vs. input at 1C18 B9 CP C).
If match, it advances table (INC DE at 1C1DH) and loads next table char (1C1EH 1A LD A,(DE)).
If the loaded char is positive (OR A at 1C1F, no M flag), it sets C = A (1C23H), optionally skips spaces for specific tokens like 8DH (at 1C25H–1C2A), advances input (INC HL at 1C2BH), loads next input char and uppers it (1C2CH–1C32), then compares (1C33 B9 CP C).
If match, loop back (1C34H JR Z,1C1D).
Crucially, if the next table char is negative (last char, like A8H for '('), it jumps to match success at 1C39H (via JP M at 1C20H) without advancing input (no INC HL) and without comparing the input char to (table char & 7FH).
This means the last character in keywords like TAB( (the '(') is not checked against the input, and input is not advanced past it. However, in practice, the parser later expects the ( to be present after the token A1H, but since the tokenizer assumes it without verification or consumption, it only matches if the structure aligns incidentally.
When a space is present ("TAB (63)"), after matching 'B' (positive table char), it advances input to the space (INC HL at 1C2BH), loads A = space (1C2CH), but the loop is for previous, and the next load is the last A8H, JP M without checking the space vs. 28H. But since the previous CP was for 'B', and the space is not involved in CP, but the match succeeds without consuming or checking the '(', but the space is advanced past? No, the INC HL is for the next positive char, but for last, no INC.
The net effect is that spaces are not skipped between keyword characters (only optionally for token 8DH at 1C29 RST 10H, which calls the space skipper at 1D78H). For "TAB (", the space after 'B' causes mismatch because the advance and compare at 1C2BH–1C33 would see space != next positive table char, but since for TAB( the '(' is last (negative), the jump at 1C20 skips the check, but the logic effectively requires consecutive chars without space for the matched prefix.
If no keyword match (after all table tries, RET Z at 1C17H pops to 1C3DH), it falls back to treating the sequence as a variable name (copying alphanum chars at 1C3DH onward).
Thus, with space, no match for TAB(, so "TAB" becomes variable TAB, spaces skipped (via RST 10H elsewhere), then '(' starts array subscript parsing (handled in expression evaluator at 2337H).
Without space, matches TAB( prefix (checks 'T''A''B', skips check for '(', but advances to '(', outputs A1H, leaves HL at '(', but parser handles it as function arg start.

This violates the "spaces have no significance" rule because the tokenizer's matching requires strict consecutivity for special chars like '('.

How to Fix It by KiwiFromBirth

The solution then is to remove the additonal ( leaving just TAB The interpreter will just parse the expression following the TAB keyword and if the expression is ( 63 ) - spacing not to important it will correctly parse the number consuming both brackets.

Remove the ( character from the TAB token in the keyword list - 1752H
Add a padding byte at the end of the reserved keyword list. 1821H
Code at $213D that consumes the trailing ) needs to be commented.

There is one issue: When an existing program is loaded (pre-tokenised) form there will be an issue with trailing ). Thus the program read would be interpreted as _TAB_10_)_ when infact the previous intention it shoudl have been _TAB(_10_)_ This is a result of the brackets not matching, ie the is an implicit ( in the TAB token. Thus for backwards compatibility we need to consume a trailing ) is it exists To do this the code.

    SYNTAX  (')')   ;213DH - rst 08h
    DEC     HL      ;213FH - decrement back, will consume latter

needs to be replaced with a CALL to

TABERFIX:
    GETCHR      ; get next char RST 10
    CP  ')'     ; if close bracket
    RET Z       ; found closing bracket, continue normally
    DEC HL      ; not a closing bracket, so DONT consume it.
    RET

ERROR 8

RULE: A PRINT USING statement with a negative sign at the end of the field prints a negative sign after negative numbers and prints a space for positive numbers. However, if the field specifiers in the string also has two asterisks at the beginning of the field, the ROM prints an asterisk instead of a space after a positive number.

10 PRINT USING "**####-";1234

Will output "**1234*"

What is happening

Why the Bug Happens

The ROM's formatting routine incorrectly applies the asterisk fill character to the trailing position for positive numbers, replacing the intended space with *.

Cause

The root cause is in the number formatting routine (starting around address 0FBEH, with key logic in 0FF5H–1033H). Here's a breakdown based on the disassembly:

The format flags are stored in memory (e.g., at 40D8H), including:
- Bit 2 (value 04H): Indicates trailing sign.
- Bit 5 (value 20H): Indicates asterisk fill for leading positions.
The routine initializes a buffer at 4130H with a space (' ') at the start.
If the asterisk fill flag is set (bit 5), the code at 0FFFH–100AH checks the buffer's starting character:
- It sets C to *.
- If the starting character is space (' ' ), it also sets B to * (at address 1009: LD B,C).
- It then sets the buffer start to * (LD (HL),C at 100AH), which handles leading fill correctly.
Later, at 102EH–1033H, the routine appends a character at the end of the formatted string:
- If the trailing sign flag is not set, it skips appending.
- If the trailing sign flag is set (bit 2), it appends B at the end (DEC HL; LD (HL),B at 1031H–1032H).
For positive numbers with trailing sign, the intended append character is space (' ').
However, the LD B,C at 1009H overwrites B with * if the asterisk fill flag is set and the buffer start was space (which it is for no front sign).
This causes B to become *, which is then appended at the end for positive numbers, violating the rule that the trailing position should always be space for positive values (regardless of leading fill).

So in the example (PRINT USING "**####-";1234):

The format parses to 6 digits/positions (**####) plus trailing sign flag.
For positive 1234, the buffer builds as **1234 + appended B (*), resulting in **1234*.
For negative, the routine places - explicitly (at 0FCFH), overriding the bug.

The leading fill (*) is handled separately and correctly; the bug is isolated to the trailing positive position being polluted by the fill flag.

How to Fix It

To fix this, modify the ROM to prevent B from being set to the fill character (*) while still allowing the leading buffer start to be set to *. This ensures the trailing positive is always space.

In the assembly source:

Remove or comment out the line at 1009H: LD B,C
This keeps B as ' ' (the original buffer start value), but the leading fill still works via LD (HL),C at 100AH.

If you have the ROM binary (not source), patch the byte at address 1009H:

Original byte: 41H (opcode for LD B,C)
Change to 00H (NOP)
This effectively disables the instruction, achieving the same effect.

After the patch, your example will output **1234 (space at end for positive), as intended. For negative values (e.g., -1234), it will correctly output **1234-. Leading asterisk fill remains unchanged.

This patch should not affect other formatting cases, as B is only used for the trailing positive append, and leading fill is handled independently.

ERROR 9

EXPECTATION: When a number is just under specific decimal magnitudes, the ROM prints a colon instead of 10. e.g.,

PRINT 9999999999999999 / 1D12 + 3D-13

What is happening

The bug occurs in the double-precision floating-point printing routine when formatting numbers in scientific notation just below powers of 10 (e.g., values like 9.999999999999999D+15, where the mantissa is slightly less than 10^16). The routine decides whether to use fixed-point or scientific notation and formats the exponent string ("D+nn" or "D-nn").

The super-short explanation is that it is putting a "10" in the SINGLE tens digit placeholder instead of having perceived a rollover into the hundredths and turning it into a 0. 30H + 10 = 3AH which is a colon.

Explanation

Level II BASIC uses MBF double-precision (8 bytes: exponent, 56-bit mantissa). When printing in scientific notation, it normalizes the mantissa to [1.0, 10.0) and computes the exponent adjustment. For values just below a power of 10 (e.g., the example computes approximately 9.999999999999999D+15 due to precision limits in the large integer division and tiny addition), the mantissa normalizes to nearly 10.0 (e.g., 9.999999999999999), but rounding/precision artifacts cause the code to misjudge the digit count or carry-over.

The flaw is an off-by-one error in the boundary check for when the mantissa rounds up to exactly 10.0 (which should increment the exponent and reset mantissa to 1.0). When the value is just under the threshold, the code incorrectly treats the exponent digits as "10" but stores/formats them starting from a buffer position or using a character code that results in ":" (ASCII $3A) being output instead of "10". This happens specifically at magnitude boundaries (powers of 10) due to how the exponent is converted to two ASCII digits without proper handling of the carry when digits sum to 10.

This ROM bug only triggers for double-precision (# suffix) in scientific notation near powers of 10.

Code Location

The double-precision to ASCII conversion and printing is in the floating-point output routines (around ROM $0E00–$1000, specifically the scientific notation formatter near $0F50–$1000). The exponent formatting (converting the binary exponent offset to "+nn" or "-nn") is around $0FA0 (integer print extension reused for exponent digits). The decision for scientific vs fixed and the buffer setup for "D" exponent marker is in the PRTNUM/PRTNBR dispatch around $20B0–$2100, branching to double-precision specific code copied/moved during init.

Suggested Fix

Patch the exponent digit formatting routine to properly handle the case when the tens digit is 1 and units is 0 (or carry from rounding). Conceptually it would be --- after computing the two exponent digits (tens in high nibble/low byte, units separate), add a check: if units == 0 and tens == 1, output '1','0' explicitly, or adjust the addition to ASCII '0' to avoid overflow to ':' (30H + 10 = 3AH).

A patch might add a conditional branch around the digit store (e.g., insert CP 10 : JR NZ,no_carry : INC tens_digit : LD units,'0').

Workaround in BASIC: Add a tiny epsilon to force over the boundary, e.g., PRINT expr + 1D-30 (adjust based on magnitude), or force fixed notation with PRINT USING.

ERROR 10

EXPECTATION: Double-precision subtraction should produce an difference accurate to 16 digits. However, the difference resulting from double precision subtraction is erroneous when the smaller operand's value is significantly less than the larger operand's value. e.g.,

10 Y# = .20#
20 X# = 1D16
30 J# = X# - Y# 'J# is valued incorrectly
40 PRINT J# - X# 'the result should be negative; however, it is positive (0.25 to be specific)

What is happening

The observed behavior in the TRS-80 Model I Level II BASIC is caused by a flaw in the double-precision floating-point addition/subtraction routine in the ROM (starting at address 0C70H for subtraction, which flips the sign of the subtrahend and falls into addition at 0C77H). Specifically, the multi-byte right shift operation used to align mantissas (called at 0D69H) does not explicitly clear the carry flag (CF) before beginning the bit-level shift loop (at 0D87H). This loop performs a chained right shift across the 7-byte mantissa using RRA instructions from the high byte (MSB/sign at 412DH) to low byte (LSB at 4127H), relying on CF to propagate bits between bytes.

Since CF is not reset to 0 before the first RRA on the MSB byte, an arbitrary value from prior operations may be shifted into bit 7 of the MSB after the shift. For floating-point values where the exponent difference requires a bit-level shift (i.e., not a multiple of 8), this corrupts the aligned mantissa of the smaller operand. In cases like 1D16 - 0.20# (or 0.25#), the difference is approximately 55 bits (remainder 7 after 6 full byte shifts), leading to an incorrect result during the subsequent mantissa addition/subtraction (at 0D33H or 0D45H). This manifests as J# being computed as if addition occurred instead of subtraction, resulting in J# > X# and thus J# - X# positive (e.g., 0.25 instead of -0.25).

This implementation error only affects scenarios with significant magnitude differences where the bit shift remainder is non-zero, as full-byte shifts (at 0D6BH) clear higher bytes to 0 properly.

Where is this happening

The bug in the double-precision subtraction routine stems from the mantissa alignment shift logic at address 0D69H (and its subroutines for byte shifts at 0D6BH and bit shifts at 0D87H). These shifts treat the entire mantissa block (including the sign bit in bit 7 of the high mantissa byte at address 412DH) as an unsigned value, inserting 0 into the high bit during right shifts. This overwrites the sign bit with 0 when shifting a negative value, effectively flipping its sign to positive. In the context of subtraction (entry at 0C70H), flipping the subtrahend's sign (XOR 80H at 0C74H) makes it negative if positive; if this negative value is the smaller operand and requires shifting, the sign flip during alignment causes the operation to effectively perform addition instead, leading to the erroneous positive result in cases with large magnitude differences.

To fix it, modify the code to handle the sign bit separately during shifts: save the sign, clear it (force positive for unsigned shift), perform the shift, then restore the sign. Patch the ROM by inserting the following instructions immediately before the CALL 0D69H at address 0CB0H (you may need to relocate nearby code or use free space at e.g., 0DD4H-0DD9H if space is tight):

LD HL,412DH
LD A,(HL)
AND 80H
PUSH A
LD A,(HL)
AND 7FH
LD (HL),A
CALL 0D69H
POP A
LD HL,412DH
OR (HL)
LD (HL),A

This ensures the sign is preserved while shifting only the magnitude, correcting the behavior for negative shifted operands without affecting positive ones or other FP operations.

ERROR 11

EXPECTATION: FOR-NEXT loops with valid integer values should complete. e.g.,

10 FOR J% = 0 TO 30000 STEP 5000
20 PRINT J%,
30 NEXT

What is happening

When adding STEP to the loop variable causes signed 16-bit overflow (exceeds ±32767), the arithmetic routine promotes the result to single precision. However, NEXT cannot store a single precision value back into an integer variable, so it throws ?OV ERROR instead of handling the overflow gracefully.

More precisely, NEXT calls integer ADD (0BD2H): adding STEP to index overflows ±32767 → promotes to single-precision in FAC (4121H–4124H, NTF=01H/4). Storing back to integer var fails type check in LET (1F21H) → OV.

Integer Increment in NEXT (22EAH+ path):
- NEXT loads the current loop variable value (from var ptr at stack +2–3) into HL as integer.
- Loads STEP (stack +10–11) into DE as signed 16-bit integer.
- Calls integer ADD at 0BD2H: HL = HL + DE (your variable + STEP).
- If no overflow (both MSBs same sign pre/post-add), stays integer (NTF=2/FFH at 40AFH); compare to TO (+12–13) using sign (+0/+4) to decide loop/continue.
Overflow Detection & Promotion (0BD2H Integer ADD):
- Uses signed comparison: XOR MSBs of HL/DE pre-add; detects carry/parity change post-add.
- On overflow (exceeds ±32767): Sets NTF=4 (single-precision), loads FAC (4121H–4124H) with promoted float value (your site: "on integer overflow +, -, & * return a single precision... in ACC").
- Result in FAC as single-precision (e.g., 35000 → 3.5E4 float).
Store-Back to Integer Variable (LET path after increment):
- NEXT calls LET (1F21H) to store new HL/FAC back to integer var (ptr from stack).
- LET checks NTF (40AFH): Integer expected (type byte 02H/FFH/-1 from var table).
- Type mismatch: Single-precision result (NTF=4/01H) vs integer var → ?OV ERROR (ERR=6) via TM path (but ROM maps overflow promotion failure to OV).
- Confirmed in ROM math docs (your site): Integer ops promote on overflow, but storing to int var fails.
Example Trace (FOR J% = 0 TO 30000 STEP 5000):
- Iterations: J%=0, 5000, 10000, 15000, 20000, 25000, 30000 (last good: 25000 + 5000 = 30000 ≤ 30000).
- Next NEXT: 30000 + 5000 = 35000 → overflow → FAC=35000.0 (single), NTF=01H.
- Store to J% (integer): LET detects type change → ?OV (not TM=13, as ROM classifies numeric promotion/store-fail as OV=6).
- Loop never wraps to negative (no SCF/SBC wraparound in ADD); promotion triggers immediate OV on store.

How to fix by KiwiSinceBirth:

The code issue is found in Code from address 22F9H to 2301H where the loop variable is advanced. This code is part of the NEXT loop processing.

22F9    CALL    IADD        ;ADD the loop and STEP integer values
22FC    LD      A,(VALTYP)  ;Get value type of result
22FF    CP      VTSNG       ;Is it Single Precision
2301    JP      Z,OVERR     ;**** Jump to OVERFLOW Error

In BASIC code a FOR NEXT loop using Integer % variable must be specified using only Integer values. The execution of the FOR statement itself will fail for any TO or STEP values that fall outside this range.

Thus, if the addition call IADD produces a single precision then by definition the loop itself has exceeded its bounds and should complete normally, proceeding the statement following the NEXT. This can be achieved by replacing the instruction at 2301H with a jp z,INTNXTOVER

2301	JP Z,INTNXTOVER

INTNXTOVER:
	POP	    HL      ; restore the loop variable pointer (2305)
	POP	    HL      ; restore the for entry pointer (2309)
	LD	    BC,6    ; need to consume 6 more bytes off the stack
	ADD	    HL,BC   ; which is passed as HL into the next routine
	JP	    LOOPDN  ; Normal NEXT completion of loop - 2324H

The code above is responsible for winding back the stack pointer address which it passes in HL to the LOOPDN routine.

ERROR 12

RULE: Logarithms - Regardless of the base, if the argument is 1 then the logarithm is zero, if the argument is > 1 then the logarithm is positive, and if the argument is > 0 and < 1 then the logarithm is negative. However, if the argument is just under 1, the ROMs LOG function produces a positive value. e.g.,

10 PRINT LOG(.99999994)

will display 8.26296E-08

What is happening

The bug occurs in the BASIC LOG function implementation within the TRS-80 Model I ROM, starting at address 0809H. This function handles the natural logarithm calculation using a series expansion based on the atanh formula after normalizing the floating-point mantissa.

Why It's Happening

The LOG function normalizes the input argument to extract the exponent and mantissa (m), where 1 ≤ m < 2. For arguments slightly less than 1 (e.g., 0.99999994), the exponent is -1, and the mantissa is slightly less than 2. The code then checks if m > √2 (approximately 1.414) and, if so, halves m (m = m / 2) and increments the exponent by 1. This results in an adjusted mantissa slightly less than 1.

The code then computes y = (m - 1) / (m + 1), which is negative when the adjusted m < 1. The logarithm is approximated using the series expansion 2 * atanh(y) = 2 * (y + y³/3 + y⁵/5 + ...). This series works for negative y, producing a negative result. However, the ROM code computes the series assuming y is positive (or takes |y|), but fails to negate the final result when y was originally negative. As a result, the output is a positive small value instead of the correct negative value.

The specific example (LOG(0.99999994) = 8.26296E-08) is the positive approximation of the absolute value, with the slight discrepancy from the exact |ln(0.99999994)| ≈ 6E-08 due to the limited precision of the series approximation and 32-bit MBF floating-point format.

Where It's Happening

The LOG entry point is at 0809H (CALL 0955H to check for positive argument, followed by normalization).

The mantissa adjustment (halving if m > √2) happens around 081A-0828h.

The y calculation and series expansion loop (where the sign mishandling occurs) is at 0869H-0892H, with the polynomial coefficients loaded from the table at 1479h.

The final assembly of the result (where the sign should be applied but isn't) is around 0841H-0847H and 0860H-0868h (pushing loop addresses and computing terms).

How to Fix It

The fix requires patching the ROM to check if the adjusted mantissa is less than 1 (indicating y < 0) after the adjustment and before the series, setting a flag (e.g., in a temporary memory location like M40F3 or an unused register). After the series computation (around 0869h loop end at M0892), if the flag is set, negate the FP result in the accumulator (at M4121-M4125) by XORing the high mantissa byte (M4122) with 80h to flip the sign bit.

A minimal patch could be:

At an available NOP or replaceable instruction after the series (e.g., near 0890H if there's space, or redirect with a JP to a user patch area).

Add code like:

LD A,(4124H) ; Load adjusted exp
CP 81h ; Compare to 81h (for m >=1)
JR NC, no_neg ; If >=, no negate
LD HL,4122H ; High mantissa
LD A,(HL)
XOR 80h ; Flip sign bit
LD (HL),A
no_neg: ...

ERROR 13

RULE: In base 10, rounding to k-digits examines digit k+1. If digit k+1 is 5 through 9, then digit k is adjusted up by one and carries to the most significant digit, if necessary. If digit k+1 is less than 5, then digit k is not adjusted. This should not get muddled with the conversion of base 2 to base 10.

PRINT 4/9

Four divided by nine should be: .444444 and not .444445

What is happening

The bug is a combination of binary floating-point representation inaccuracy and the decimal digit extraction/rounding logic in the numeric print routine.

Division Computation:
- Division operator dispatch routes through expression evaluator (e.g., calls around 2CB1H = CALL 2B02H for FP ops).
- FP division routine (around 2Bxx, calls to subtract/normalize).
- 4 and 9 exact in single-precision, but 4/9 = 0.4444... repeating cannot be exactly represented in binary FP (mantissa at 40A0H-40A7H). The stored value is the closest representable binary approximation: slightly greater than true 4/9 (positive bias from mantissa truncation).
PRINT Dispatch:
- PRINT statement ends with calls to numeric output, e.g., 01B9H = JP 2884H (string/FP print cleanup) and 00B8H = CALL 28A7H (related print prep).
- Numeric formatting entry around 2DCBH (seen in exponent/power paths, but shared for print).
Decimal Digit Extraction and Rounding (Key Bug Location):
- To print decimals, the routine repeatedly multiplies the fractional part by 10, takes integer part as digit, subtracts, repeats (standard banker's extraction).
- Multiply-by-10 loop involves CALLs to FP multiply (e.g., CALL 2E49H for add/digit logic).
- Digit rounding/guard check around 2F5FH-2FA1H area (guard digit tests, CP thresholds, ADD for round-up).
- The tiny positive epsilon in the internal value causes the remainder (after 5th 4) to be just over the 0.5 boundary for the 6th digit.
- Rounding logic (e.g., FE05 or similar CP, then INC digit) triggers round-up when guard >=5, turning the 6th 4 into 5.

Why This Case?

Repeating 4s amplify the binary approximation bias; the epsilon accumulates to tip the 6th/7th digit threshold upward. Other fractions (e.g., 1/3 = .333333) often have negative or neutral bias, rounding correctly.

ERROR 14

EXPECTATION: Double-precision division should perform correctly for absolute values that are from 2.938735877055719D-39 to 1.701411834604692D+38.

ERROR 14a

If the divisor is the minimum magnitude or the minimum magnitude times 2, then double-precision division errors. e.g.,

10 Z# = 1 / (2^125 + 2^125) * .25
15 'Line 10 values Z# with 2.938735877055719D-39
20 PRINT 1 / Z# 'displays 2.938735877055719D-39 instead of overflow

What is happening

Analysis of the TRS-80 Model 1 ROM and the Double-Precision Division Bug

The ROM uses Microsoft Binary Format (MBF) for floating-point: SP is 32-bit (8-bit exponent, 24-bit mantissa including implied leading 1), DP is 64-bit (8-bit exponent, 56-bit mantissa). The bug involves DP division failing for divisors at or near the minimum positive magnitude (≈2.938735877055719D-39, which is 2^{-128} with exponent 0 and normalized mantissa starting at 0.5). Instead of correct results or overflow, it produces zeros or copies of the minimal value.

In the example:

Z# = 1 / (2^125 + 2^125) * 0.25 = 0.25 / 2^{126} = 2^{-128} ≈ 2.938735877055719D-39 (min DP value).
1 / Z# should be ≈3.4028234663852886D+38, but since max DP is ≈1.701411834604692D+38, it should overflow (error or max value). Instead, it returns the min value (2.938735877055719D-39), indicating a failure in reciprocal handling for tiny divisors.

Why Does The Bug Occur

The DP division routine lacks proper checks for zero dividends or minimal-magnitude divisors, leading to underflow/overflow mishandling. The algorithm:

Unpacks operands: Exponent and mantissa from dividend (numerator) and divisor (denominator).
Subtracts exponents: exp_q = exp_dvd - exp_dvr + 128 (bias).
Aligns mantissas: If exp diff requires shifting the dividend mantissa right (when dvd < dvr in magnitude), bits are shifted out.
Performs non-restoring division on mantissas (bit-by-bit loop over 56 bits for DP).
Normalizes quotient: Left-shift mantissa until leading 1, decrementing exp_q per shift.
Underflow check: If exp_q <= 0 after normalization, set result to 0 (flush to zero, no subnormals in MBF).
Packs result with sign.

For tiny divisors (e.g., min magnitude ≈2^{-128}):

Reciprocal requires large exp_q (e.g., +128), but if divisor mantissa is exactly 0.5 (normalized min), the division loop may not propagate bits correctly, causing the quotient mantissa to underflow prematurely.
No explicit check for dividend == 0: Proceeds with division, copying residual mantissa bits (often from divisor) and setting invalid exp_q, resulting in non-zero garbage like the min value.
For min divisor: Alignment shift exceeds effective precision (56 bits), but the loop doesn't handle lost bits (no sticky bit), leading to all-zero quotient mantissa except in edge cases where it retains the min value.
Overflow avoidance fails: Should detect exp_q > 255 and error, but for reciprocals of min, it underflows the mantissa instead, flushing to min or zero.

This contrasts with SP (24-bit mantissa), where shorter precision avoids the issue for the same values. The bugs (labeled ERROR 3,4,14a,14b in analyses) are design flaws in MBF DP handling, present in all Level II ROM versions (1.0–1.3), due to missing zero-dividend paths and inadequate underflow detection in normalization.

Routines at Fault with Actual ROM Addresses

DP Routine Initialization (0075H): Copies 39 bytes (0027H) of DP math subroutines from ROM 18F7H to RAM 4080H. This includes the buggy division logic executed in RAM.
```
0075 118040   LD   DE,4080H
0078 21F718   LD   HL,18F7H
007B 012700   LD   BC,0027H
007E EDB0     LDIR
```
FP Division Dispatch (around 1690H–1700H, not in initial excerpt but referenced via operator table at 4152H+): Handles token for '/' and dispatches to SP or DP based on type (# suffix). Jumps to RAM-copied DP division (likely FDIVC at 4080H+).
DP Division Core (RAM 4080H+, copied from ROM 18F7H–191EH): Performs mantissa division and normalization. Faulty underflow/zero handling here; no explicit dividend-zero check, and normalization loop mishandles tiny reciprocals.
- Specific sub-parts: Mantissa alignment/shift (reuses general FP shift at ~0D69H), where right-shifts for tiny divisors lose bits without sticky, leading to false zero/underflow.
FP Normalization and Underflow (around 0D69H–0D87H): Shared routine for post-op normalization. Checks exp <=0 and zeros result, but fails for edge mantissas, propagating min value instead of overflowing.
DP Accumulator Storage (411DH, DFACLO): Holds DP exponent; routines load/check this but miss zero cases.

Proposed Fix

Patch the DP division routine to add explicit checks for zero dividend and minimal-magnitude divisor/underflow. Since code is copied to RAM, modify RAM post-init or patch ROM source at 18F7H+.

Insert at division entry (e.g., after unpack, around copied 408CH):

; Check if dividend exponent is 0 (zero value)
408C 3A1D41   LD   A,(411DH)     ; Load dividend exp (DFACLO)
408F B7       OR   A             ; Zero?
4090 2005     JR   NZ,continue   ; No, proceed
4092 CDA00D   CALL 0DA0H         ; Call zero-result routine (clear FPACC to 0#)
4095 C9       RET                ; Return zero
; Additional check for tiny divisor (exp_dvr == 0)
4096 3AXX41   LD   A,(divisor_exp) ; Load divisor exp
4099 B7       OR   A
409A C2YY40   JP   NZ,normal_div ; Not min, proceed
409D CDZZ0F   CALL overflow_check; Custom: If dividend non-zero, set overflow error
; ... rest of division

ROM Modification: Change copy source at 18F7H+ to include the check (~10 bytes). Burn new ROM or use emulator patch.
Workaround in BASIC: Check manually: IF divisor = 0 OR ABS(divisor) < 3D-39 THEN handle error ELSE result = dividend / divisor.

This ensures zero dividend returns zero, and tiny divisors trigger overflow for large reciprocals, matching expected range behavior.

ERROR 14b

If the dividend is the minimum magnitude or the minimum magnitude times 2, then double-precision division errors. e.g.,

10 Z# = 1 / (2^125 + 2^125) * .25
15 'Line 10 values Z# with 2.938735877055719D-39
20 PRINT Z# / 1 'displays 0 instead of 2.938735877055719D-39

What is happening

Analysis of the TRS-80 Model 1 ROM and the Double-Precision Division Bug

The bug is a variant of the previous DP division issues (labeled ERROR 14b in known bug lists), where division produces 0 when the dividend is at or near the minimum representable positive magnitude (≈2.938735877055719D-39, which is 2^{-128} in MBF DP format: exponent 01H, mantissa 80 00 00 00 00 00 00 00 representing 0.5 * 2^{-127}). For Z# / 1, the result should be Z# (identity), but underflows to 0 due to flawed normalization.

Full Explanation of Why the Bug Occurs

The TRS-80 Level II BASIC uses Microsoft Binary Format (MBF) for DP: 8-bit exponent (bias 129, so 00H = 0, 01H = 2^{-128}, up to FFH ≈ 2^{126}), 1 sign bit, 55-bit mantissa (implied leading 1, normalized to 0.5 ≤ |m| < 1). Division (quotient = dividend / divisor) involves:

Unpacking: Load dividend to primary accumulator (WRA1 at 411DH-4124H: mantissa LSB/MSB/exponent), divisor to alternate (WRA2 at 4127H-412EH).
Exponent computation: exp_q = exp_dvd - exp_dvr + 81H (bias adjustment, since bias is 129 but code uses +129 effectively via offsets).
Mantissa alignment: Right-shift the smaller-magnitude mantissa to align radices; lost bits not preserved (no sticky bit, causing precision loss).
Mantissa division: 56-bit non-restoring loop (subtract divisor from partial dividend, shift, set quotient bit; calls support at 4080H+).
Normalization: Left-shift quotient mantissa until leading 1, decrementing exp_q per shift.
Underflow/overflow: If exp_q <= 00H post-normalization, flush to 0 (no subnormals). If > FFH, overflow error.

For tiny dividends (exp_dvd = 01H, mantissa normalized at 80...):

For /1 (exp_dvr ≈ 81H for 1.0), exp_q = 01H - 81H + 81H = 01H (minimal).
If mantissa division produces a value <0.5 (e.g., due to alignment or subtraction rounding), normalization shifts left, decrementing exp_q to 00H or negative.
Code zeros the result (silent underflow) instead of preserving the tiny non-zero (no subnormal support).
SP (24-bit mantissa) avoids this for the same values due to shorter precision—fewer shifts needed, exp_q stays >=01H.
Bug specific to DP because longer mantissa (55 bits) allows more shifts before leading 1, pushing exp_q below threshold more easily for min values.

This affects all Level II ROM versions (1.0–1.3); it's a design flaw in MBF DP handling, not fixed in patches.

Routines at Fault with Actual ROM Addresses

DP Routine Initialization (0075H): Copies 39 bytes (0027H) of DP support subroutines (including division helpers) from ROM 18F7H-191EH to RAM 4080H-40A6H. This sets up the faulty mantissa operations used in division.
```
0075 118040   LD   DE,4080H
0078 21F718   LD   HL,18F7H
007B 012700   LD   BC,0027H
007E EDB0     LDIR
```

DP Division Entry (0DE5H): Main DP division handler (ACC# = ACC# / AACC#). Loads operands, computes exp diff, calls mantissa division loop, normalizes, and underflows to 0 if exp_q <=00H. Calls support at 4080H+ and normalization at 18F0H+

0DE5 F5       PUSH AF
0DE6 C5       PUSH BC
0DE7 D5       PUSH DE
0DE8 E5       PUSH HL
0DE9 3E08     LD   A,08H
0DEB 32AF40   LD   (40AFH),A
0DEE CD F0 18 CALL 18F0H
0DF1 CD B0 18 CALL 18B0H
0DF4 3A2441   LD   A,(4124H)
0DF7 D62E     SUB  (412EH)
0DF9 322441   LD   (4124H),A
0DFC CB7E     BIT  7,(HL)
0DFE 2805     JR   Z,0E05H
0E00 18XX     JR   DIV_LOOP    (to main loop at ~0DEFH)
; ... (alignment and sign handling)

Normalization and Underflow (18F0H): Normalizes DP in WRA1; checks exp <=00H and zeros. Faulty for min exp=01H—if shift needed, dec to 00H, zeros non-zero tiny.

18F0 3A2441   LD   A,(4124H)
18F3 FE01     CP   01H
18F5 DAC0XX   JP   C,UNDERFL   ;(zero if <01H)
18F8 CD10XX   CALL ALIGN       ;(shift/align)
18FB ...      ; Mantissa check
18FE UNDERFL: AF     XOR  A
1900 322441   LD   (4124H),A   ;(zero exp)
1903 AF       XOR  A           ;(clear mantissa bytes)
1904 321D41   LD   (411DH),A
; ... (clear other mantissa bytes)
190C C9       RET

Mantissa Division Support (4080H, copied from 18F7H): Low-level subtract/shift loop for 56 bits. Lacks sticky bit, loses precision for tiny, contributing to bad normalization.

4080 CD85XX   CALL SUBTRACT      ;(subtract divisor)
4083 3005     JR   NC,NO_BORROW
4085 ...      ; Add back, set bit 0
408A CD10XX   CALL SHIFT_RIGHT
408D 10F1     DJNZ LOOP

Alternate Accumulator (4127H-412EH, WRA2): Holds divisor; bug interacts with load at 0DF1H.

Proposed Fix

Patch the normalization routine to preserve tiny non-zero results by adjusting the underflow threshold—allow exp=00H as subnormal (denorm mantissa) or add sticky bit to detect any non-zero bits during shifts, preventing false zero. Since code is copied to RAM, patch RAM post-init (e.g., via POKE in BASIC). For permanent, modify ROM at 18F0H+ before copy.

RAM Patch (Post-Boot): After init, POKE to change underflow check at copied normalization (around 409AH, corresponding to ROM 18F5H). Replace CP 01H / JP C,ZERO with CP 00H / JP Z,ZERO (allow exp=00H as tiny).

BASIC POKE example (after cold start):

FOR I=0 TO 5: READ A: POKE &H409A+I,A: NEXT  ' Patch normalization
DATA &HFE,&H00,&HCA,&HXX,&HXX,&HC9  ' CP 00H / JP Z, zero_addr / RET

Exact assembly patch at 409AH (adjust zero_addr to existing zero handler ~40A0H):

409A FE00     CP   00H
409C CAA040   JP   Z,40A0H
409F C9       RET                ; bypass zero if exp>00H)
40A0 AF       XOR  A             ; zero code)
; ... (clear mant/exponent)

ROM Modification: At 18F5H (in normalization), change:

18F5 DAXX18   JP   C,18XXH       ; change to JP Z for exp==00H zero only

Add sticky: In shift loop (1910H), OR shifted-out bits into LSB.

1910 CB3E     SRL  (HL)          ; shift right)
1912 B6       OR   (HL)          ; OR previous LSB as sticky)
1913 77       LD   (HL),A

This fixes silent zeroing for min dividends, allowing non-zero tiny quotients. Test with example to confirm no new overflows.

ERROR 15

EXPECTATION: Single-precision division should perform correctly for absolute values that are from 2.93874E-39 to 1.70141E+38.

ERROR 15a

If the divisor is the minimum magnitude, then single-precision division errors. e.g.,

10 Z = 1 / (2^125 + 2^125) * .25 'values Z with 2.93874E-39
20 PRINT Z / 1 'displays 0 instead of 2.93874E-39

ERROR 15b

If the dividend is very large, then single precision division errors. e.g.,

10 PRINT 1.6E38 / .9 'displays 0 instead of overflow

MICROSOFT BASIC-80 release 5.0; i.e., BASIC 01.01.02

10 PRINT 1.5E38 / .9 'overflows instead of displaying 1.66667E38

What is happening

Background on TRS-80 Floating-Point Format (MBF - Microsoft Binary Format)

To understand the bug, we need a quick primer on how single-precision floating-point numbers are stored and manipulated in the TRS-80 ROM. This is based on Microsoft's Binary Format (MBF), used in many 8-bit BASICs:

Format (4 bytes, stored in little-endian order in memory, but processed MSB-first in routines):
- Byte 3 (highest address, e.g., often at offsets like 4124H in the Floating-Point Accumulator or FAC): Exponent (8 bits, 0-255).
  - Bias: +129 (e.g., 1.0 has exponent byte 81H/129 decimal, representing true exponent 0).
  - Special case: Exponent 00H represents exactly 0 (regardless of mantissa).
  - True exponent = (exponent byte) - 129.
  - Range: True exponents from -128 to +126 (exponent bytes 01H to FFH), giving values up to 1.7014118346046923E+38 (positive max) or down to 2.938735877E-39 (smallest positive normalized).
- Byte 2: High byte of mantissa (bit 7 is the sign bit: 0=positive, 1=negative; bits 6-0 are part of the 23-bit mantissa).
- Byte 1: Middle byte of mantissa.
- Byte 0 (lowest address): Low byte of mantissa.
Normalization: The mantissa is normalized to [1.0, 2.0) with an implicit leading 1 (not stored). Operations involve unpacking, aligning exponents, and renormalizing.
Key ROM Locations:
- FAC (Floating-Point Accumulator): Often at 4121H-4124H (mantissa low to exponent high; see e.g., loads/stores at 2C43, 15C6 in the disassembly).
- Temporary storage: Areas like 40F9H-40FDH, 4121H-4125H for operands (e.g., 26A5, 1343).
- Routines: FP ops are scattered but include unpacking (e.g., around 0955H), addition/subtraction (e.g., 12D4-13FF chunk), and normalization (e.g., 07B7H).

Division involves:

Computing result exponent: result_exp_byte = dividend_exp_byte - divisor_exp_byte + 129.
Dividing mantissas (24-bit integer division, essentially).
Normalizing: If the result mantissa >= 2.0, right-shift it and increment the exponent. If <1.0, left-shift and decrement exponent.
Checking for overflow/underflow and raising errors if needed.

The bug hits when the exponent calculation or post-division normalization would require an exponent > FFH (255), causing a wraparound to 00H (which represents 0).

Expected Behavior

For 1.6E38 / 0.9:
- This should compute ~1.777777777E+38.
- However, the maximum representable positive single-precision value is ~1.7014118346046923E+38 (exponent FFH/255, max mantissa).
- 1.777E+38 exceeds this, so it should overflow.
Correct handling: The ROM should detect exponent overflow (e.g., during addition or increment) and jump to an error handler, typically raising ?OV ERROR (Overflow Error). This is seen in other FP routines (e.g., checks around 15CB for exponent <81H, or carry checks in 1310-1318 for subtraction).

Instead, the result is 0, indicating the exponent byte was set to 00H due to unchecked overflow.

Why the Bug Occurs

The core issue is in the FP division routine (likely centered around calls to 13E2H, as seen in 15C0: CALL M,13E2H, which appears to handle signed division or reciprocal). Based on the disassembly and standard TRS-80 ROM behavior:

Step-by-Step Breakdown in the Division Process:
1. Load Operands:
  - Dividend (1.6E38): Approximates to exponent byte FFH (255, true exp = 255 - 129 = 126), with a mantissa representing ~1.6 * 1038 normalized to [1,2) * 2126.
  - Divisor (0.9): Normalized to ~1.8 * 2^-1 (mantissa 1.8, true exp = -1, exponent byte = -1 + 129 = 80H/128 decimal).
  - These are loaded into FAC (4121H-4124H) and temporary regs (e.g., via 0955H calls at 15BD, 1569).
2. Exponent Calculation (The Critical Flaw):
  - Compute result_exp_byte = dividend_exp - divisor_exp + 129.
    - 255 - 128 + 129 = (255 - 128) = 127, then 127 + 129 = 256.
  - This is done with 8-bit arithmetic (e.g., SUB and ADD opcodes in routines like 130C: SUB (HL), 1310: SBC A,(HL), or similar in division-specific code).
  - 256 overflows an 8-bit register (A or similar), wrapping to 00H (256 mod 256 = 0) with the carry flag set.
  - The ROM does not check the carry flag for overflow here (unlike in some addition/subtraction paths, e.g., 1318: JR NC,... or 134F: JR NC,...). Instead, it proceeds with the wrapped value.
  - Exponent 00H forces the result to be interpreted as exactly 0 (mantissa is ignored or cleared).
3. Mantissa Division and Normalization Aggravates It:
  - Mantissas are divided (similar to integer division in 1300-135C, with loops for shifting/subtracting).
  - For this example, the result mantissa would be >2.0 initially (since 1.777E+38 requires an extra bit), triggering a right-shift and exponent increment (e.g., via calls like 07B7H at 131A for normalization).
  - Incrementing an already maxed exponent (FFH -> 100H, but if pre-wrap it's 00H -> 01H) doesn't help; the lack of overflow check means it stays 0 or wraps again.
  - No error is raised; it falls through to return the malformed value (e.g., via RET at 1364 or similar).
Relevant Disassembly Evidence:
- Exponent Handling and Comparisons: See 15C6-15CB: LD A,(4124H); CP 81H; JR C,... – This checks if exponent <81H (129, i.e., true exp <0), branching to handle small numbers. No equivalent for >FFH.
- Arithmetic Loops with Unchecked Overflow: In 1300-132D (part of FP subroutines, possibly called by division): PUSH/POP sequences and subtractions (e.g., 130C: SUB (HL); 1310: SBC A,(HL)) compute differences without explicit >255 checks. Carry is used for borrowing (1318: JR NC,130AH), but not for upper-bound overflow.
- Normalization Calls: 131A: CALL 07B7H – Likely shifts mantissa and adjusts exponent. If exponent increments past FFH, it wraps (e.g., ADD A,something without checking carry out).
- Zero Result Path: Exponent set to 00H (as in data at 1364: multiple 00H bytes, possibly zero constants) leads to routines like 15D9-15DF, which load HL with tables (15E3H) including 00H values, effectively returning 0.
- Signed/Overflow Handling: 15C0: CALL M,13E2H (conditional on negative) and 15C3: CALL M,0982H (negate?) suggest division entry points, but the chunk from 12D4-13FF shows multi-byte ops that align with mantissa division—without overflow traps.

This bug only triggers for dividends near the max (~E+38) divided by values <1 (which increase magnitude). Smaller dividends work fine.

How to fix it

Patch 1: Core Exponent Calculation Fix (Minimal, 3 Bytes)

If ADD sets carry (sum >=256), it doesn't jump (NC is false), so fall through to original code? Wait, no—actually, for overflow we want to error, so better: DA B2 07 (JP C,07B2H) to jump on carry (overflow). The additional code detects overflow immediately and errors out.

Original Code

Original Code:
1310: SBC A,(HL)    ; Subtract exponent (multi-byte helper)
1312: ADD A,81H     ; Add bias
1314: (next instr, e.g., store A or JR)

Revised Code

1310: SBC A,(HL)    ; Subtract exponent
1312: ADD A,81H     ; Add bias
1314: JP NC,07B2H   ; If no carry (no overflow), continue normally (D2 = JP NC, then address 07B2H; 3 bytes)
1317: ...   (original next instr, shifted by 3 bytes if needed)

Patch 2: Normalization Increment Fix (Additional 4 Bytes, for Completeness)

This new code catches cases where normalization pushes an already-high exponent (e.g., FEH -> FFH -> 00H) over the edge. Combined with Patch 1, it covers both initial calc and post-division adjustments.

Original Code

Original Code:
094E: ...   (prior, e.g., LD HL,4124H)
0950: 34    INC (HL)      ; Increment exponent during normalization
0951: C0    RET NZ        ; Return if no zero (no wrap)
0952: C3B207 JP 07B2H     ; Existing overflow jump if INC caused zero (but this is underflow? Wait)

Revised Code

0950: 34    INC (HL)      ; Increment exponent
0951: 7E    LD A,(HL)     ; Load new exponent
0952: B7    OR A          ; Check if 00H (wrapped from FFH)
0953: CAB207 JP Z,07B2H   ; If zero, overflow error
0956: ...   (original continuation)

ERROR 16

EXPECTATION: PRINT USING should not clobber code from 4152H through 415BH disabling CVI, FN, CVS, and DEF. BASIC 01.01.02 just clobbers the space and 'i' in the " in " message.

10 A# = -2^53
20 B$=".#######################-"
30 PRINT USING B$;A#

What is happening

The bug in the TRS-80 Model 1 Level 2 BASIC ROM occurs in the PRINT USING routine, which overwrites memory locations from 4152H to 415BH. These addresses are part of the vector (jump) table set up during initialization (starting at address 0093H in the ROM), which contains JP instructions for various BASIC functions and keywords. Specifically, this corruption affects the entry points for CVI (Convert Integer to Integer), CVS (Convert String to String), FN (user-defined functions), and DEF (function/variable type definitions), rendering them unusable after the corruption occurs.

Cause

The overwrite is a buffer overflow in the formatting buffer (FBUFFR, located at 4130H and adjacent areas). When PRINT USING processes a double-precision floating-point number (like A# in the example) with a "complex" format string (e.g., one specifying many fractional digits via # placeholders), the routine builds an ASCII string representation of the number digit-by-digit. For large-magnitude numbers (such as -2^53, which is -9007199254740992) combined with a format that starts with a decimal point (implying zero integer digits) and requests 23 fractional digits:

The routine detects an "overflow" condition because the number's absolute value is >=1, but the format provides no space for integer digits.
It attempts to handle this by prefixing a '%' (overflow indicator) and then formatting the number anyway, which involves scaling, rounding, and extracting digits (potentially multiplying/dividing by powers of 10 to align the decimal point and extract fractional parts).
This process generates more data than the buffer can hold (the buffer is small, ~34 bytes before spilling into 4152H), leading to an overflow that writes garbage into the vector table.

The specific trigger in the example:

A# = -2^53: A very large negative double-precision value (exactly representable in the Microsoft BASIC floating-point format, which uses 8 bytes with an 8-bit exponent and 55-bit mantissa including implicit bit).
B$ = ".#######################-": Specifies a decimal point, 23 fractional digit placeholders (#), and a trailing minus sign for negatives. This is "complex" due to the high number of fractional digits and the overflow condition (large integer part with no integer field in the format).

Simpler formats or smaller numbers avoid the overflow because fewer digits are processed, staying within buffer bounds.

Location in the Code

The corruption originates in the PRINT USING handling routine, specifically the output formatting and buffer manipulation sections.

Entry into PRINT USING is via the PRINT command handler (token 95H), which checks for the USING keyword (token A3H) and branches to the formatting code around addresses 2CBDH–2FFFH (the "output handling" area in the listing, involving calls like 2338H for string evaluation, 0AF4H for format parsing, and loops for digit extraction at 2D00H+).
Buffer operations involve FBUFFR (4130H) for temporary string building, with loops (e.g., around 2F65H–2F74H for digit handling and 2FA1H for shifting/inserting characters) that can exceed bounds when processing excessive digits or overflow indicators.
Overwrite targets 4152H–415BH because that's immediately after the buffer area; the routine doesn't properly bounds-check writes during digit extraction/scaling for double-precision values.

Initialization of the affected area: At 0093H–00A8H, the ROM sets up the vector table with JP opcodes (C3H) and addresses, looping to fill 84 bytes (28 vectors * 3 bytes each). The bug trashes the first ~10 bytes of this table.

No other ROM routines directly write to 4152H post-init, confirming PRINT USING as the culprit.

ERROR 17

RULE: SIN(X) + SIN(-X) = 0. Unfortunately the ROM disobeys this rule.

10 FOR Y = 1 TO 100
20 X = Y / 100
30 PRINT SIN(X) + SIN(-X),
40 NEXT

What is happening

The sine function in this BASIC uses a polynomial approximation (likely a Taylor or Chebyshev series) over a reduced argument range (after modulo 2π and symmetry reductions). Floating-point arithmetic in the TRS-80's single-precision format (about 7-8 decimal digits of precision, similar to IEEE 754 single but with Microsoft Binary Format) introduces rounding errors during:

Argument reduction (dividing by 2π, which is irrational and approximated).
Polynomial evaluation (multiplications and additions accumulate tiny errors).
Handling the sign for negative arguments.

When computing SIN(-X), the routine negates the argument, computes the sine of the absolute value (or uses symmetry), and applies the negative sign. However, the approximation errors for SIN(X) and SIN(-X) are not perfectly symmetric due to these rounding effects. Their magnitudes are similar but not identical, so adding them doesn't cancel exactly to zero—instead, you get residuals on the order of 10^-7 to 10^-8 (or larger for some X).

This is common in floating-point trig implementations on vintage microcomputers (and even modern ones without extended precision guards). The errors are tiny relative to the function's scale (~1), but visible when summing opposites.

With this, it's not a outright bug in the sense of incorrect logic—it's a limitation of finite-precision approximation. Microsoft's BASIC prioritized speed and ROM size over ultimate accuracy. Similar small deviations appear in other 8-bit BASICs (e.g., Applesoft, Commodore).

ERROR 18

RULE: SIN(X) should be less than X. Unfortunately the ROM disobeys this rule.

10 PRINT "Testing ";
20 FOR Z = 1 TO 7
30 FOR X = 9 TO 1 STEP -1
40 Y = VAL(STR$(X) + "E-" + STR$(Z))
50 IF Y < SIN(Y) THEN D = D + 1:B = D:IF C = 0 THEN PRINT:C = D
60 IF B THEN PRINT TAB(((D - 1) AND 1) * 32)Y;SIN(Y);:IF (D - 1) AND 1 THEN PRINT
70 B = 0
80 NEXT
90 IF D = 0 THEN PRINT ".";
100 NEXT
110 IF POS(0) <> 0 THEN PRINT
120 IF D > 0 THEN PRINT
130 IF SIN(.01) + SIN(-.01) <> 0 THEN E = E + 1:PRINT SIN(.01), SIN(-.01)
140 IF SIN(.001) + SIN(-.001) <> 0 THEN E = E + 1:PRINT SIN(.001), SIN(-.001)
150 IF SIN(1E-4) + SIN(-1E-4) <> 0 THEN E = E + 1:PRINT SIN(1E-4), SIN(-1E-4)
160 IF E > 0 THEN PRINT
170 PRINT "Total errors";D + E

ERROR 19

EXPECTATION: PRINT USING without scientific specifier should display a negative sign if the value is <-9.999999999999999D+15. e.g.,

10 PRINT USING "##.##";-1D16

This prints % 1D+16 and should print %-1D+16

What is happening

The bug in the TRS-80 Model 1 Level 2 BASIC ROM's PRINT USING routine causes the negative sign to be omitted when formatting negative double-precision numbers with an absolute value of 10^16 or greater (i.e., <= -10000000000000000# or >= 10000000000000000#) in fixed-point mode without scientific notation specifiers (^^ or ^^ ^^).

Expected Behavior

For PRINT USING "##.##"; -1D16 (i.e., -10000000000000000#):

The format has limited space (2 integer digits + 2 fractional).
This triggers an overflow condition (% prefix).
The ROM should output %-1D+16 (or a close approximation, e.g., %-1.00D+16 depending on scaling), with the negative sign preserved.

Actual Behavior

It outputs % 1D+16 (positive mantissa with no sign), misleadingly showing a positive value despite the input being negative.

Cause

The issue lies in the double-precision formatting path within PRINT USING (primarily ROM addresses 2DC5H–2F3EH, involving overflow detection, scaling, and sign handling).

Microsoft BASIC double-precision numbers use an 8-byte format: 1-byte exponent (bias 129, range effectively allowing ~10^-308 to ~10^308) and 7-byte mantissa (56 bits, providing exactly 16 decimal digits of precision).
For absolute values >= 10^16 (which require 17 or more integer digits, exceeding the 16-digit precision), the routine internally switches to a D+E (scientific-like) notation to represent the number compactly, even without ^^ specifiers in the format string. This involves scaling the absolute value to a mantissa between 1 and 10 (extracting digits via repeated division/multiplication by 10) and computing the exponent.
It correctly detects negativity and sets a sign flag early (around 2DCDH, via a call to 0FBEH for floating-point evaluation).
However, during mantissa string building and exponent appending (loops at 2F1CH–2F3EH for overflow/% handling and digit output), the code clears or skips reapplying the sign flag specifically in this high-magnitude branch, treating the scaled mantissa as positive.
The % overflow prefix and exponent (+16) are added correctly, but the leading mantissa digits are output without the preceding -.

Values with absolute value < 10^16 (e.g., -9.999999999999999D+15, or -9999999999999999#) work correctly because they fit within 16 digits and stay in the pure fixed-point path with proper sign placement. The threshold exactly matches where the integer part exceeds the mantissas decimal precision, forcing the internal D+E shift.

Workarounds

Use a format with trailing - (e.g., PRINT USING "##.##-"; -1D16) — this forces a floating minus sign (space for positive, - for negative), resulting in % 1D+16- (still shows positive mantissa but trailing - indicates negative).
Force scientific notation with ^^ (e.g., PRINT USING "##.## ^^"; -1D16) to get proper - in the mantissa (e.g., -1.00D+16).
Avoid PRINT USING for such large values; use plain PRINT (which correctly shows -1D+16) or STR$ and manual formatting.

ERROR 20

EXPECTATION: When PRINT USING has scientific specifier the rounded value should 'scale' and not indicate the PRINT USING field is not large enough. The ROM fails this expectation. e.g.,

10 PRINT USING "##.##[[[[";-999999

Will output %-10.00E+05

What is happening

Step 1: Understanding the Expectation vs. Actual Behavior

Expectation: In PRINT USING with a scientific notation specifier (e.g., "##.##[[[["—likely a stand-in for "##.##" in TRS-80 BASIC, where "" indicates scientific notation with space for sign and exponent digits), the output should automatically "scale" (adjust the exponent) when rounding causes the mantissa to require more digits than specified. For example:
- Input: PRINT USING "##.##[[[["; -999999
- Expected: Something like -1.00E+06 (rounding -999999 to -1000000, scaling the exponent from +05 to +06, and fitting within the 2 digits before the decimal without overflow).
- This avoids indicating a field overflow.
Actual Behavior (Bug): The ROM outputs %-10.00E+05.
- The '%' prefix is Microsoft BASIC's standard indicator for "field overflow" (the number doesn't fit the specified format width).
- Here, -999999 is normalized to approximately -9.99999E+05. Rounding to two decimal places produces -10.00E+05 (due to carry-over from 9.99999 → 10.00000).
- However, "##.##" specifies 2 digits before the decimal (plus implied space for sign and decimal point), but "-10.00" requires effectively 3 digits for the mantissa ("1" + "0" + implied carry), plus the sign. This triggers overflow ('%') instead of scaling the exponent to fit (e.g., dividing mantissa by 10 and incrementing exponent to get -1.00E+06).
Why This Matters: Standard Microsoft BASIC (as in TRS-80 ROM) does not automatically scale the exponent on rounding carry-over in scientific notation. It treats the format as fixed-width, leading to '%' on overflow. The bug is that the ROM lacks logic to detect and handle rounding-induced digit overflow by adjusting the exponent, which would make the behavior more intuitive for large numbers.

Step 2: Root Cause Analysis Based on Disassembly

The bug occurs in the interplay between floating-point rounding/normalization and the PRINT USING formatting logic. Key areas:

Floating-Point Handling (e.g., around 08D7-10FF in typical TRS-80 ROM, partially visible in snippets):
- Routines like FPMULT (08D7), FPADD (096E), and especially ROUND (e.g., implied at 0FB8-0FE5 in similar ROMs) handle mantissa rounding.
- Rounding adds a constant (e.g., 0.5 * 10^(-precision)) to the FP accumulator (often at 4121-4124: exponent byte, mantissa bytes, sign).
- If carry occurs (e.g., 9.99999 → 10.00000), it increments the mantissa (e.g., via CALL 0FF8H or similar) but does not adjust the exponent unless explicitly normalized. In scientific mode, normalization is partial—it ensures the mantissa is in [1,10) or similar, but not always re-scaled for format width.
- In the snippets, see 0FC2: CALL 0FE9H (add rounding constant), 0FC5: CALL 100FH (normalize?), 0FC8: JR NC,... 0FCA: CALL 0FF8H (increment mantissa on carry). This is where carry-over happens without exponent adjustment for print formatting.
PRINT USING Parsing and Formatting (e.g., 2CB1-2E4A in snippets):
- This is the core of the bug. The routine starts at ~2CB1: CALL 2B02H (evaluate expression?), PUSH DE, RST 8H (syntax check), etc.
- Format string parsing happens in loops like 2CE7-2D48:
  - It scans for specifiers: '%' (2CEF: JP Z,2E17H—likely handles '%' as a format char or overflow), '.' (2D22: CP '.', JR Z,2D66H), '#' (2D11: CP '#', JR Z,2D4C), '+' (2D19: CP '+', LD A,08H, JR Z,2D06H), etc.
  - It builds a "template" for output, counting digits before/after decimal (B = digits before, D/E = flags/options).
  - For scientific notation ("[[[[" or ""), it sets flags (e.g., at 2D0C: CP '!', JP Z,2E14H; 2D11: CP '#') and prepares exponent output.
  - Rounding is applied during number conversion (e.g., CALL 196CH at 2C6A—likely loads/converts FP number to BCD/string for formatting).
  - Overflow check: At 2D16: DEC B, JP Z,2DFEH (likely jumps to overflow handler, which prefixes '%').
  - When rounding -9.99999E+05 → -10.00E+05, the mantissa digit count increases (from 1 to 2 before decimal), but the code doesn't check/re-scale. It detects B (digits before decimal) is exceeded and jumps to overflow (adding '%') without adjusting the exponent (e.g., no call to divide mantissa by 10 and INC exponent at 4121).
Output and Overflow Indication (e.g., 032A calls, 2CFD: LD A,'%', CALL 2E49H):
- Characters are output via CALL 032AH (print char).
- Overflow is flagged by prefixing '%' (e.g., at 2CFB: LD A,'%', CALL 2E49H—possibly a staging call before final output).
- In scientific mode, the exponent is appended (E+05), but the mantissa isn't re-normalized post-rounding to fit the width.

Why the Bug Happens (Sequence of Events)

Expression evaluation (-999999) loads to FPREG (4121-4124 as ~ exponent=85h or similar for E+05, mantissa=9.99999...).
Format parsing ("##.##[[[[") sets: digits_before=2 (##), digits_after=2 (.##), scientific_mode=on ([[[[ for E+xx).
Number is normalized to scientific form (-9.99999E+05).
Rounding adds to mantissa for 2 decimal places, causing carry-over to -10.00000E+05.
The code checks if mantissa fits (digits_before >= length of integer part). "-10" has 2 digits + sign, but format allows only 2 digits (assuming sign is extra), triggering overflow (JP to 2DFEH or similar).
No logic exists to detect this carry-induced overflow and scale: e.g., if mantissa >= 10^digits_before, divide mantissa by 10 (FP call), INC exponent, re-round.
Result: Outputs with '%' prefix, no scaling.

This matches typical Microsoft BASIC behavior but fails the "scale on rounding" expectation. The root cause is missing post-rounding normalization in scientific mode within the PRINT USING routine (around 2D00-2D6A and called FP routines).

Suggested Patches

To fix this, we need to insert logic after rounding to check for mantissa overflow due to carry, then scale (divide mantissa by 10, increment exponent) and reformat if needed. This keeps the output within the field without '%'.

There are two patches: a minimal one (simple, less risk) and a more robust one (handles edge cases like multiple carry-overs or signs). Patches are given as assembly code to insert/replace, with assumed addresses based on snippets (adjust if your ROM differs). Apply via hex editor or assembler (e.g., patch ROM at idle space or NOP-out/replace existing code). Test with edge cases: large positives/negatives, exact fits, small numbers.

Patch 1: Minimal Patch (Add Scaling Check After Rounding)

Location: Insert after the rounding carry handling in the FP routine used by PRINT USING. Based on snippets, this is likely after 0FCA (CALL 0FF8H—increment on carry) or in the formatting loop at 2D4C (before JP Z,2DFEH—overflow jump). I'll assume insertion at ~2D4D (after DEC B, before JP Z overflow).

Rationale: After rounding, check if the mantissa's integer part >= 10^digits_before (B reg). If so, scale.

Effect: For -999999, after rounding to 10.00E+05, detects mantissa >= 10^2 (100), scales to 1.00E+06. No '%'.

Size/Risk: Low (adds ~20-30 bytes total). Risk: Assumes FPREG format; test for underflow.

Patch Code (Insert ~12 bytes; find free space or overwrite NOPs/unused):

; Assume inserted at 2D4D (replace JP Z,2DFEH with CALL to this patch, then continue)
; Inputs: B = digits_before, FPREG at 4121-4124 (exponent at 4121, mantissa bytes follow)
PUSH BC         ; Save digits_before
PUSH HL         ; Save context
LD HL,(4122)    ; Load mantissa high bytes (adjust if FP format differs)
LD A,B          ; A = digits_before
LD BC,000Ah     ; 10 for power-of-10 check
CALL Power10    ; Subroutine: HL = 10^A (you may need to add this or inline)
; Compare mantissa >= 10^digits_before
OR A            ; Clear carry
SBC HL,BC       ; HL -= 10^digits_before (BC now holds it? Wait, adjust regs)
JR C,NoScale    ; No overflow, skip
; Scale: Divide mantissa by 10 (FP divide), INC exponent
CALL FPDiv10    ; Call FP divide-by-10 routine (e.g., existing at ~0A7F or add)
LD HL,4121      ; Exponent address
INC (HL)        ; Increment exponent

NoScale:
	POP HL
	POP BC
	; Now check if still overflow (rare), JP Z,2DFEH if yes, else continue
	DEC B ; Original code
	JP Z,2DFEH 		; Original overflow

Power10:
    LD HL,0001h   ; Start with 1
    OR A          ; If A=0, return 1
    RET Z

PowLoop:
    PUSH AF       ; Save counter
    LD DE,000Ah   ; 10
    CALL MulHLDE  ; HL = HL * 10 (assume existing MUL routine or inline)
    POP AF
    DEC A
    JR NZ,PowLoop
    RET

 FPDiv10:
    LD HL,FP10    ; Address of FP constant 10.0 (add to data section if needed)
    CALL LoadFP   ; Load to temp reg (assume existing)
    JP FPDIV      ; Call existing FP divide routine
	FP10: DB 81h, 20h, 00h, 00h  ; FP for 10.0 (exponent 81h, mantissa 0A0000h normalized)

Patch 2: Robust Patch (Handle Multiple Carry-Overs and Signs)

Location**: Replace/insert in the main formatting loop at ~2D15 (after CP '#', JR Z,2D4C) or after CALL 196CH (number load at 2C6A). This is safer as it's specific to PRINT USING.

Rationale**: Loop until no more scaling needed (handles extreme cases like 999.999 → 1000.00 → scale twice).

Effect: Handles cases like 99.999 → 100.00 → 10.00 → 1.00 (multiple scales). Supports negatives by preserving sign.

Size/Risk: Medium (adds ~40 bytes). Higher risk of stack overflow if not careful; test thoroughly for infinite loops (add max iterations).

Patch Code** (Insert ~25 bytes):

; Insert after rounding (e.g., after CALL 196CH at 2C6D)
PUSH AF ; Save flags
ScaleLoop:
; Check if integer digits > B (digits_before); assume subroutine CountIntDigits returns A = digit count of mantissa integer part
CALL CountIntDigits ; Add this: BCD-count digits in FP mantissa
CP B ; Compare to allowed
JR C,DoneScale ; Fits, done
; Scale: Divide by 10, INC exponent
CALL FPDiv10 ; As above
LD HL,4121
INC (HL)
; Handle sign if needed (e.g., if negative, adjust)
LD A,(4124) ; Sign byte (assuming 80h=negative)
OR A
JR Z,ScaleLoop ; Repeat if still overflow
; If negative, ensure mantissa sign preserved (may need FPABS/FPSIGN calls if exists)
JR ScaleLoop
DoneScale:
POP AF
; Continue original code (e.g., LD A,(HL) at 2C6D)
- **Additional Subroutines**:
- **CountIntDigits**: Convert mantissa to integer (e.g., CALL 0F8C BCDFLT), count non-zero digits before decimal.
  ```
  CountIntDigits:
    CALL BCDFLT   ; Convert FP to BCD/string (assume existing at ~0F8C)
    LD HL,BCD_BUF ; Buffer for BCD (define in RAM)
    LD A,0        ; Digit counter
  CountLoop:
    LD A,(HL)     ; Get digit
    OR A          ; Skip leading zeros?
    JR Z,Next
    INC A         ; Count digit
  Next:
    INC HL
    CP '.'        ; Stop at decimal
    JR NZ,CountLoop
    RET
  ```
- **FPDiv10**: As in Patch 1.

ERROR 21

EXPECTATION: Strings in a relational statement should work regardless of a concatenated expression. e.g.,

10 IF "h"+"m" = "hm" THEN PRINT "X"
20 IF "hm" = "h"+"m" THEN PRINT "Y"

Both lines should evaluate to true and print "X" and "Y" respectively, as "h"+"m" and "hm" are equivalent strings.

But while Line 10 executes correctly (evaluates to true, prints "X"), line 20 throws a "Type Mismatch" error during evaluation.

What is happening

Cause

The relational expression evaluator handles the left and right operands asymmetrically for string comparisons.

The left operand is evaluated using the full expression parser (entry point at ROM address 28A7H), which supports operators like + for string concatenation.
The right operand, when the left is a string (VALTYP=3 at 4020H), is evaluated using a simplified string parser (entry point at ROM address 2338H), intended for simple strings (literals or variables) without operator support.

This simplified parser cannot handle the + operator in concatenated expressions on the right side, leading to a parsing failure interpreted as a type mismatch (TM error thrown via call to error handler at 1997H).

The asymmetry arises because relational operations are parsed left-to-right with the relop applying after evaluating the add-level expression (where + is handled at levels like 2337H calls), but the right-side string evaluation skips full operator precedence handling to optimize for common cases (simple comparisons). This optimization flaw fails for complex right-side expressions.

Exact ROM Locations

Full expression evaluator entry (used for left operand): 28A7H (handles concatenation via operator loops, e.g., calls to add/concat decision at ~0B10AH based on VALTYP).
Simplified string evaluator entry (bugged call for right operand in string relations): 2338H (evaluates simple string terms; fails on + by not entering operator handling, leading to type check failure).
Type check and TM error trigger: Indirect via 1E5AH (type validation) and jumps to 1997H (error dispatch for TM, error code 0DH).
Relational handler (where the bugged call originates): Around 1B5FH–1B7FH (relop loop saves left via push to ARG/temp, checks VALTYP at 4020H, calls 2338H for right if string instead of 28A7H).
String comparison routine (executed if no error): 0B244H (length check then byte-by-byte memcmp).
Concatenation routine (works on left but fails parsing on right): 0B10AH (allocates temp string space, copies operands; called in full expr but skipped in simple parser).

The bugged path skips operator precedence, misinterpreting + as invalid in simple context.

ERROR 22

Issues with the VAL statement.

ERROR 22a

EXPECTATION: A statement with VAL(string) should return zero if the first character is not numeric. The ROM produces syntax error if the first character in a string is %.

What is happening

The bug in the VAL() function arises because the TRS-80 Level II BASIC ROM treats the % character specially as an integer type suffix (similar to ! for single-precision and # for double-precision). This suffix can appear at the end of numeric constants or variables to force a specific data type.

When VAL processes the string argument, it temporarily null-terminates the string descriptor (to treat it as a null-terminated ASCII string for parsing) and scans for a valid numeric literal. During this scan:

It skips leading whitespace.
It accepts optional + or -.
It then expects digits (or a decimal point in some cases).

If the first non-whitespace, non-sign character is a valid type suffix like % (with no preceding digits), the parser interprets this as an attempt to parse a typed constant like % (invalid integer literal with no value). Since no digits follow (or precede properly), it fails to form a valid number but in a way that triggers a type mismatch or syntax-related error during conversion, rather than cleanly returning 0.

In contrast:

"#10" — The # is a double-precision suffix, but parsing consumes the leading digits "10" first (valid number), treats # as the stopping non-numeric character, and successfully converts to 10 (ignoring the suffix after a value is found).
"X10" — "X" is not a recognized type suffix, so it's treated as an invalid starting character; parsing stops immediately with no number found, cleanly returning 0.

The % case hits an edge in the parsing logic where a lone (or leading) type suffix without a proper numeric body causes inconsistent handling—likely attempting to force an integer type on a non-existent/invalid value, leading to an error instead of fallback to 0.

This is a quirk of Microsoft's early BASIC implementations (inherited in later VB/VBA, where VAL("50.5%") explicitly raises a type mismatch for the same reason). The ROM prioritizes recognizing type-declaration suffixes even in string-to-number conversion, but the code path for a leading % doesn't gracefully recover.

To fix it in a patched ROM, modify the VAL routine (around the numeric parsing loop, likely near 2E60h-3000h range based on similar routines) to explicitly check for leading suffixes and treat them as non-numeric starts (forcing 0 return) or skip suffix recognition when no prior digits exist. Alternatively, add a pre-check for leading %, !, or # and force early exit to 0.

ERROR 22b

EXPECTATION: A statement with VAL(string) should not corrupt the BASIC program. The following program cannot execute in Microsoft BASIC.

10 ON ERROR GOTO 50
20 PRINT VAL("1E44")
30 PRINT MEM
40 END
50 RESUME NEXT

Best to fix up line 20 before you edit line 10

What is happening

Expectation

VAL("1E44") represents 1 × 10^44, far exceeding single-precision range (exponent limit ~38). The ROM should detect overflow during conversion, raise OV error (code at 1E5AH path), and with ON ERROR GOTO / RESUME NEXT, continue cleanly at line 30 (PRINT MEM). Free memory should remain unchanged, program intact.

Observed Behavior

OV error triggers, but BASIC program corrupts: line links overwritten, MEM drops dramatically (hundreds/thousands bytes "lost"), program often unLISTable, subsequent execution yields SN error or crash.

Exact Cause

The bug occurs in the scientific notation exponent application loop for string-to-floating-point conversion, used by VAL.

VAL Dispatch Entry:
- VAL function token leads to expression evaluation jump at 1A19H (C3191A JP 1A19H seen in cold start / expression paths).
- String argument for VAL evaluated, pointer in HL/DE, then calls general numeric parser at 19A2H (C3A219 JP 19A2H at 012FH).
Numeric String Parser (19A2H entry):
- Scans string for digits, '.', 'E' (scientific notation).
- Upon 'E', extracts exponent sign/value (code around 1ED9H-1Fxx for exponent processing).
- Mantissa initially converted to FP accumulator (FAC) at 40B1H-40B8H or similar.
- Exponent stored temporarily, then applied by loop: repeated multiply/divide FAC by 10 (using FP multiply at ~2Bxx / add routines).
Exponent Application Loop (key section around 2CB1H-2Fxx, specifically multiply-by-10 loop):
- For positive exponent (here +44), loop calls FP multiply by 10 (10 loaded into FAC2 temporarily).
- Each iteration: CALL to FP multiply (around 2E49H or 0FBEH pack/normalize).
- Overflow detection in FP pack at exponent byte (FAC at 40A0H-40A7H): if exponent > ~96H, sets carry/flags and jumps to OV error (CALL 1E5AH at paths like 1997H JP NZ,1997H).
The Corruption Trigger:
- For small exponents (<~38), loop runs few times → clean overflow or success.
- For extreme exponents like 44, loop runs 44 times, each multiply allocating temporary string descriptors in string space (downward from pointer at 40F9H "high string memory", managed via CALL 28A7H garbage/string alloc seen at multiple points e.g. 00B8H, 28A7H).
- Temporary strings created for intermediate "10" constant or mantissa copies during multiply (early Microsoft BASIC uses string-based FP for some ops).
- On overflow abort (mid-loop at high exponent), exit path fails to fully restore string pointers (40A0H temp buffer, 40A7H string start, 40F9H top).
- Unbalanced POPs or stray writes cause 40F9H (string top) to move downward into program text area (program stored upward from low RAM ~4200H+).
- This overwrites program line number pointers/tokens, corrupting the tokenized program.

Exact Problematic Instructions:

Exponent loop entry/exit: around 2DCBH-2E09H (repeated CALL 28A7H string alloc, CALL 0FBEH FP ops).
Overflow branch: 1997H (CD8D09 CALL 098DH then paths to error, seen in multiple FP routines).
Unclean temp cleanup: 2884H JP after partial restore (C38428 JP 2884H at 01B9H), but loop abort skips matched deallocs.
String pointer corruption visible post-error: 40F9H lowered, overlapping program.

Why Only Extreme Exponents?

Loop iterations proportional to |exponent|; only >38-40 trigger many temps + early overflow abort before full cleanup.

This is the exact inherited Microsoft BASIC flaw in Level II ROM: assumes reasonable exponents, no robust temp string rollback on FP error abort.

Fix: Insert pointer save/restore around exponent loop (e.g., PUSH/POP 40F9H pair before/after loop at ~2E00H), or limit exponent pre-check. No official patch; avoid large-exponent VAL in code.

ERROR 22c

EXPECTATION: A statement with VAL(string) should ignore leading spaces in the string. The ROM loses itself if a space precedes a positive or negative sign. e.g., the following program lines return a zero with the ROM

10 PRINT VAL(" -3")
20 PRINT VAL(" - 4")
30 PRINT VAL(" +7")
40 PRINT VAL(" + 8")

Radio Shack incorrectly states, "VAL will not always return the correct value of negative numbers although it does return the correct value of positive numbers." This is a half-baked excuse for the ROM error.

What is happening

Expectation

The VAL function should ignore leading whitespace (spaces) in the string argument, as whitespace is insignificant in BASIC numeric literals except in quoted strings. Standard behavior (seen in later BASICs) skips leading spaces before parsing the optional sign (+/-) and digits.

Examples like VAL(" -3"), VAL(" - 4"), VAL(" +7"), VAL(" + 8") should return -3, -4, +7, +8 respectively. Without the leading space (e.g., VAL("-3")), it works correctly.

Observed Behavior

With a leading space before the sign, VAL returns 0 in all cases.

Exact Cause from ROM Disassembly:

The bug is in the numeric string parser used by VAL, specifically in how it skips leading whitespace but fails to reapply the skip after detecting a sign.

VAL Dispatch and Parser Entry:
- VAL evaluates its string argument, then calls the general numeric conversion routine at 19A2H (JP 19A2H at 012FH: 012F C3A219 JP 19A2H).
- At 019DH: Entry point for input/numeric parsing (019D D7 RST 10H – get next char).
Leading Whitespace Skip (RST 10H at 019DH):
- RST 10H (address 0010H in ROM, but effective routine via calls) advances HL through the string, skipping spaces (CP ' ' at multiple points, e.g., related to 1D7DH FE20, 10D5H FE20, etc.).
- It stops at the first non-space character, leaving HL pointing to it and A containing that char.
Sign Handling (around 1FFFH-200x, but effective in parser flow):
- After skipping leading spaces, the parser checks for sign: CP '-' (FE2D) and CP '+' (FE2B) – seen at 0E78H/0E7EH, 0EB1H/0EB8H, 10E5H/10E8H, 1FFFH FE2D.
- If sign found, it sets a sign flag (often in a register or memory) and advances HL past the sign (INC HL).
The Bug:
- After consuming the sign and advancing HL, the parser does NOT re-invoke the whitespace skip routine (RST 10H or equivalent loop).
- If there was a space after the sign (as in " -3" → skip initial space → hit '-' → advance past '-' → now pointing to space before '3'), the next char is space (20H).
- The digit check (CP '0' to '9', e.g., FE30 at many points like 014BH, 1BEC) fails on space.
- No digits found → parser assumes no valid number → returns 0 (default for invalid numeric string).

Why Only When Space Precedes the Sign?

Without leading space ("-3"): Skip finds '-', handles sign, advances to '3' → parses digits correctly.
With leading space (" -3"): Skip to '-', handle sign, advance to space → space not skipped post-sign → treated as invalid → 0.
Multiple spaces or spaces elsewhere may trigger similar paths, but this specific pattern hits the post-sign no-reskip case.

Fix:

Patch to re-call whitespace skip (e.g., insert RST 10H or CALL to skip routine) immediately after handling the sign and INC HL. No official patch; avoid leading spaces before signs in VAL arguments.

ERROR 23

EXPECTATION: Statements that use floating point multiplication should be able to create a product that is less than the upper limit of the floating point range ?1.70141 x 10^38.

Microsoft BASIC indicates overflow if the product is => 8.507059 x 10^37. e.g., EXP(88) = 1.65163 x 10^38 which is less than 1.70141 x 10^38; however, Microsoft BASIC indicates overflow.

This is wrong because EXP(-88) = 6.05462E-39.

ERROR 24

EXPECTATION: Statements that use floating point division should be able to create a quotient that is greater than the lower limit of the floating point range ?2.93874 x 10^-39.

Microsoft BASIC returns a zero if the quotient is < 5.8775 x 10^-39. e.g., .5 / 8.50706 x 10^37 = 5.87747 x 10^-39

Note: Ira could not duplicate this. Assuming the above math was really .5/8.50706*10E-37 and 5.87747*10E-39, they both show the same result.

ERROR 25

Issues with Roots

ERROR 25a

EXPECTATION: Exponentiation where both the base and exponent is an small integer should produce a correct result. The ROM fails to meet this expectation. e.g.,

PRINT 3^12

returns 531442, but it should be 531441

PRINT 7^7

returns 823544, but it should be 823543

What is happening

The bug in the exponentiation operator (^) occurs because the implementation uses logarithmic exponentiation (base^exponent = EXP(exponent * LN(base))), relying on approximated series for natural log (LN) and exponential (EXP) functions. These polynomial approximations introduce small rounding errors in the Microsoft Binary Format (MBF) floating-point representation.

For small integer bases and exponents, the exact mathematical result is an integer within single-precision range (e.g., 3^12 = 531441, 7^7 = 823543). However, the accumulated errors in the LN → multiply → EXP chain cause the final result to be slightly higher than the true value—often by less than 1, but enough that rounding to the nearest representable float yields exact integer +1 (531442 and 823544) after normalization.

This is a known limitation of Microsoft's 8K/12K ROM BASIC floating-point math routines. It affects many vintage Microsoft BASIC implementations due to shared code heritage. The error is tiny relative to the magnitude (~10^-6 or smaller), but visible when the true result is an integer and the approximation overshoots just past the halfway point for rounding.

Where it happens

The power routine (likely around 2300h-2400h in the ROM, based on operator dispatch tables) calls the LN function (for the logarithm) and EXP (for the antilog). The series coefficients and evaluation loops in these subroutines (shared with other math functions) are the source of the approximation bias.

How to fix it

In a patched ROM, options include:

Adding a post-computation check: if the exponent is a small positive integer (e.g., ≤20) and the base is an integer, use iterative multiplication (repeated squaring or simple loop) to compute exactly, bypassing the log/exp path.
Adjusting the EXP or LN series coefficients slightly for better centering (though this risks regressing accuracy elsewhere).
After EXP, if the result is very close to an integer (fractional part near 0 or 1), force rounding down or to nearest even.

Many third-party enhanced BASICs (e.g., SuperBASIC or MULTIDOS patches) corrected this and similar math quirks for better precision on integer powers.

ERROR 25b

EXPECTATION: Square roots of perfect squares should produce a correct result. Microsoft BASIC fails to meet this expectation. e.g.,

PRINT SQR(625) - 25<>0

What is happening

The bug in the SQR() function occurs because the implementation uses a general-purpose approximation algorithm (likely a polynomial or iterative method, such as Newton-Raphson or a Chebyshev series, common in Microsoft BASIC math packs) that introduces small rounding errors in the Microsoft Binary Format (MBF) single-precision floating-point representation (approximately 7-8 decimal digits of precision).

For perfect squares like 625 (25^2), the exact mathematical square root is the integer 25, which is precisely representable in MBF floating-point. However, the approximation computes a value slightly off from the true root—often something like 24.999999999 or 25.000000001 due to accumulated errors in the series evaluation or iteration convergence. When subtracted from 25 (an exact integer), the result is a tiny non-zero value (e.g., on the order of 10^-8 to 10^-12), making SQR(625) - 25 <> 0 true.

This is a known limitation of the floating-point math routines in Microsoft's 8K/12K ROM BASIC (shared across TRS-80, Applesoft, and other contemporaries). The algorithm prioritizes speed and ROM space over detecting and correcting cases where the input is a perfect square. Similar tiny residuals appear in other trig/exponential functions but are particularly noticeable here because the expected result is an exact integer.

Where it happens
The SQR routine (likely in the 2200h-2300h range, dispatched from the function table) calls shared polynomial evaluation or iteration code (e.g., POLY series or root-finding loops). The error stems from the coefficients or convergence threshold not guaranteeing exactness for representable perfect squares.

How to fix it

In a patched ROM:

Add a pre-check: If the argument is a positive integer (or convertible to one without fraction), test for perfect square status (e.g., compute INT(SQR(arg)), square it back, and compare to arg). If it matches, return the exact integer root (converted to float).
Post-process the result: If the computed root squared is extremely close to the argument (within a small epsilon), snap to the nearest integer representation.
Use a dedicated integer square root path for arguments in a safe integer range.

ERROR 26

EXPECTATION: Editing a REM statement should not corrupt a BASIC program. However, if the REM statement - all REM - is 254 or 255 characters the BASIC program is corrupted.

Model III

The Model III ROM includes all of the 33 errors found in the Model I ROM; and, the Model III ROM has six additional errors.

In describing the additional MODEL III errors, I will be code specific; whereas, most of the Model I errors were created by Microsoft's code fundamentals and cannot be corrected without rewriting significant chunks of code.

With the capability to modify the Model III ROM code in a Model 4, I created 'fixes' (1 to 81 bytes) to code segments keeping as much of the original code as possible. Each of these 'fixes' were limited to a single area (one exception) and are independent of other 'fixes'. To fix floating point multiplication and division, I would have to completely change the way the resulting exponent is determined. This would create modifications to, at least, five areas.

ERROR 27

Location 0072H: Instruction here is JP 06CCH. Location 06CCH on the Model I contained the correct entry to BASIC from a machine language routine that moved the stack pointer. On the Model III, 0072H still has the instruction JP 06CCH; however, that is in the middle of the Model III's modified list routine. This is a bona fide screw up that was never fixed.

ERROR 28

Location 02B5H: Instruction here is LD SP,4288H. The instruction here should be LD SP,4388H because the Model III moved up the start of BASIC by 100H. This is another bona fide screw up that was never fixed.

ERROR 29

Location 02C3H: Instruction here is JP 06CCH. Location 06CCH on the Model I contained the correct entry to BASIC from a machine language routine that moved the stack pointer. On the Model III, 0072H still has the instruction JP 06CCH; however, that is in the middle of the Model III's modified list routine. This is the same jump foul up as ERROR 27.

In Model III BASIC, key SYSTEMENTER
then, at the *? prompt, press BREAK.

If you do this, the system will crash and restart, and you will get the CASS prompt.

ERROR 30

Issues at 034BH

ERROR 30a

Location 0348H: Instruction here is LD A,(403DH). 403DH is the code that is jumped to when port 0E0H has bit 3 reset (IOBUS interrupt). 403DH was used in the Model I to hold an image of what was outputted to port 0FFH. If bit 3 of port 0FFH is set then the Model I is in the 32 characters per line video mode. Another screw up. The Model III uses bit 2 of port 0ECH with image in 4210H.

ERROR 30b

Location 034BH: Instruction here is AND 08H. Wrong bit is tested. The correct instruction should be AND 04H.

Note by Vernon: Once Radio Shack explained the cursor movement when in the 32 characters per line video mode, Radio Shack did not fix the code. And, Radio Shack made Logical Systems modify TRSDOS 6 to behave the same way! However, with LSDOS 6.3, someone should have had the guts to correct the code.

ERROR 31

Issues with the Model III Stack Pointer

ERROR 31 part 1

The routine located at 06CCH in the Model I resets the stack pointer to the last CLEAR n address when returning from a machine language routine that moved the stack pointer. If the machine language routine did not move the stack pointer then a simple return would suffice; or, exit to 0A9AH to pass a value back to the variable used in the USR statement.

ERROR 31 part 2

The Model III does not have a routine to reset the stack pointer to the last CLEAR n address when returning from a machine language routine that moved the stack pointer. The code necessary is LD BC,1A18H followed by JP 19AEH. That's all of six bytes. Instead of wasting (what a waste!) 2K of the 14K ROM on ridiculous stuff, put the routine in the 3000H to 37FFH area; or, use 'dead' code created by Model III changes.