TRS-80 ROM Errors

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.

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

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.

Two changes are required
• 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

What is happening

Why the Bug Happens

Cause

How to Fix It

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.

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.

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.

1. 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.
2. 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).
3. 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.
4. 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.

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: ...

What is happening and Fix by KiwiSinceBirth

Single precision numbers in Level 2 BASIC occupy 3 bytes for the mantissa, of which one bit is the sign. Thus there are 23 bits available where only 20 bits are actually required. The extra three bits are still stored and used in computation and display purposes. Issues seem to relate to the handling of these extra bits, specifically as it relates to the extra bits causing rounding issues during any computation. The display routines themselves truncate with rounding Single Prevision values.

How do you fix?

At 1222H, replace the call FOUNVC with a jp FOUNDBFIX ...

FOUNDBFIX:
	CALL SINGLEFIX	; apply the fix - See BUGFIX 2 for this routine
	CALL FOUNVC		;1222 - compare the ACCumulator to 999999.5
	JP FOUNDV1		; continue

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

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

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:

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

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

Why the Bug Occurs

How to fix it

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)

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)

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)

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)

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.

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).

What is happening

The SIN(X) function in Level II BASIC uses a Taylor series approximation after range reduction:

• X is reduced to |X| mod 2π (using constants for π at ROM addresses like ~22xxH–23xxH).
• For small reduced angles, it evaluates a polynomial: sin(x) ≈ x - x³/6 + x⁵/120 - ... (typically 5–7 terms in Microsoft implementations).
• The coefficients are stored as MBF constants in ROM (e.g., around 22xxH for the series eval routine).

The bug arises from accumulated rounding errors in the series summation and the limited precision of single-precision MBF (≈7 decimal digits). For certain tiny X (often 10^{-6} to 10^{-8} range), the positive higher-order terms (x⁵/120 etc.) — combined with rounding up in intermediate FP additions/multiplies — can make the computed SIN(X) slightly larger than X, violating the inequality.

This is **not** a coding error per se but a limitation of the polynomial approximation and the lack of higher precision or error bounding in the math pack. Similar tiny overshoots appear in COS(), ATN(), etc., but SIN(X) > X for small X is particularly noticeable and violates a fundamental trig identity expectation.

Related: The page also notes nearby bugs like SIN(X) + SIN(-X) ≠ 0 for some small X (asymmetry due to the same approximation rounding), tested in lines 130–150 of the example.

Routines at Fault with Actual ROM Addresses

• SIN entry point: Around 1FxxH–2000H (dispatched from function table; calls range reduction then series eval).
• Polynomial evaluation: Shared routine (likely ~22xxH–23xxH) for series summation using Horner's method or similar.
• FP add/multiply: 0F96H (add), 0FBEH (multiply) — rounding in these contributes to the overshoot.
• π constant and reduction: Constants near 22xxH–236xH (used in X mod 2π).

Possible Fix

A patch could force SIN(X) = X for |X| below a small threshold (e.g., 1E-5) where the series error dominates, or use more terms/higher precision intermediates (but requires significant ROM space). Many enhanced BASICs (e.g., SuperBASIC, later patches) tweaked the coefficients or added snap-to bounds for tiny arguments.

Workaround: For critical trig work with tiny angles, use the small-angle approximation directly (SIN(X) ≈ X) or avoid values near the problematic range.

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.

What is happening

Step 1: Understanding the Expectation vs. Actual Behavior

Step 2: Root Cause Analysis Based on Disassembly

Why the Bug Happens (Sequence of Events)

Suggested Patches

; 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)

; 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.

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.

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.

What is happening

Expectation

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.

1. 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).
2. 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.
3. 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).
4. 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.

What is happening

The Level II BASIC floating-point routines use Microsoft Binary Format (MBF) single-precision: 8-bit exponent (bias 128), 23-bit mantissa (implied leading 1), sign bit. The largest representable positive value is approximately 1.7014118 × 10³⁸ (exponent byte FFH, mantissa near 7F FF FF).

However, the overflow detection in the FP multiply routine (0FBEH) and normalization/packing code (around 0FD0H–1000H region) is overly conservative:

• During multiplication or repeated ×10 in EXP(), the intermediate exponent is checked before final normalization.
• If the tentative exponent exceeds a threshold ≈ FEH (corresponding to ≈8.507 × 10³⁷ after normalization), it jumps to overflow (1997H) even if the final normalized result would fit within FFH.
• This happens because the packing routine does not always re-normalize aggressively enough after addition/multiplication carry, or it errs on the safe side to avoid producing an invalid exponent byte.

For EXP(88):

• EXP(x) = e^x ≈ repeated multiplies by e (≈2.71828) or internal series.
• The internal computation pushes the intermediate value past the conservative threshold, triggering OV even though the mathematical result is representable.

This is an inherited Microsoft math pack limitation — similar premature overflow occurs in other early Microsoft BASICs. The EXP implementation (around 22xxH–23xxH) uses a series or repeated multiply that exacerbates the issue for large arguments.

Routines at Fault with Actual ROM Addresses

• FP multiply: 0FBEH — core multiplication with overflow check.
• FP pack/normalize: Around 0FD0H+ — where overflow is detected (exponent > certain value → jump to 1997H).
• EXP function: Dispatched around 1FxxH–2000H, uses repeated multiply or series evaluation that hits the threshold.

Possible Fix

A patch could relax the overflow check in the packing routine (allow exponent up to FFH before error) or use a more careful series implementation for EXP. Many third-party BASIC extensions (e.g., SuperBASIC) adjusted this threshold or used alternative algorithms for large exponents.

Workaround: For large exponents, compute in parts (e.g., EXP(88) = EXP(80) × EXP(8)) and hope intermediate results stay below the threshold, or use logarithms manually.

What is happening

MBF single-precision underflows to zero when the normalized exponent would be < 1 (true exponent ≈ -127 after bias). The smallest positive value is ≈2.93874 × 10⁻³⁹ (exponent 01H, mantissa 80 00 00).

In division (via reciprocal multiply or direct mantissa division):

• Exponents subtract: exp_q = exp_dividend - exp_divisor + 128.
• If exp_divisor >> exp_dividend, the dividend mantissa is right-shifted before division.
• If the shift ≥ 24 bits (mantissa width), the dividend becomes zero → quotient zero.
• Otherwise, division proceeds, followed by normalization (left-shift) and underflow check.

The original example (0.5 / 8.50706E+37) produces a quotient near 5.877 × 10⁻³⁹, which is **above** the flush-to-zero threshold. In emulators and real hardware, it returns non-zero (or very close), matching expectation. The claimed "5.8775 × 10⁻³⁹ cutoff" does not exist as a hard threshold — underflow is exponent-based, not value-based at that exact point.

This entry likely stems from a miscalculation (possible typo in exponent sign or magnitude) or confusion with double-precision behavior in edge cases (see ERROR 3 for related discussion). No reproducible premature underflow at exactly 5.8775 × 10⁻³⁹ has been confirmed in Level II BASIC.

Routines at Fault with Actual ROM Addresses

• Division logic: Around 1D2DH (convert arg), reciprocal via multiply, or direct in some paths.
• FP multiply (used for reciprocal): 0FBEH.
• Underflow check: In normalization/pack (around 0FD0H+) — if exp_q < 1 after shifts, result = 0.

Possible Fix / Status

No fix needed for the claimed example, as it behaves correctly. If any subtle underflow asymmetry exists in rare mantissa cases, it would require patching the right-shift/division loop to preserve sticky/guard bits — but this is minor and not worth ROM space in most cases.

Workaround: None required for typical use; the FP system flushes underflow symmetrically near the documented limit.

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.

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.

What is happening

In TRS-80 Level II BASIC, program lines are stored tokenized: 2-byte pointer to next line, 2-byte line number, tokenized statements, and a 00H terminator. REM statements are special: after the REM token (8FH), the rest of the line is stored as literal ASCII text (no further tokenization).

The editor uses a fixed-size input buffer called LINBUF, located at 40D4H (256 bytes total, but effective safe space is ~255 bytes before overflow risk). When you enter EDIT mode for a line:

1. The ROM first de-tokenizes the existing line into LINBUF:
   • Converts line number to ASCII digits (e.g., "10 " → 3 bytes for line 10).
   • Outputs "REM" (3 bytes).
   • Adds a space or colon if needed (multi-statement lines).
   • Copies the literal comment text byte-for-byte.
2. For a 255-character REM comment:
   • Line number ASCII: 2–5 bytes (e.g., "10000 " = 6 bytes).
   • "REM ": 4 bytes.
   • Comment text: 255 bytes.
   • Total: ~265 bytes → overflows LINBUF (past 41D3H).
3. Overflow writes into adjacent RAM areas, which may include:
   • Temporary string pointer table (TEMPPT at ~41A3H).
   • Variable table start (if low memory is used).
   • Even parts of the program area or stack in extreme cases.

When you press ENTER after editing (even if unchanged), the buffer is re-tokenized and copied back to program memory. The overflowed bytes can:

• Corrupt next-line pointers → LIST shows garbage or truncated lines.
• Overwrite variable names/types → runtime errors or crashes.
• Damage string descriptors → mysterious string behavior or memory corruption.

This is a classic fixed-buffer overflow bug in Microsoft's editor routines. Shorter REM lines leave enough headroom for the extra bytes added during de-tokenization (line number + "REM "). Model III BASIC inherited this exact issue unchanged.

Routines at Fault with Actual ROM Addresses

• EDIT command entry: Around 1A00H–1A50H (parses line number, finds line, calls de-tokenize).
• De-tokenize routine: ~1B00H–1B80H (converts tokens to text; copies literal bytes for REM and strings).
• Editor input loop: ~1A5AH+ (handles character insert/delete, cursor movement; advances in LINBUF at 40D4H).
• Re-tokenize / insert line on ENTER: ~19A2H (numeric parser entry) and ~1A98H+ (line insertion logic).
• LINBUF buffer: Fixed at 40D4H (256-byte area: 40D4H → 41D3H).

Possible Fix

A ROM patch could add a length check before or during de-tokenization:

• Count bytes written to LINBUF.
• If > 250 (safe margin), abort with "?LS ERROR" or similar.

Some third-party DOSes (e.g., NEWDOS/80 patches, MULTIDOS) or enhanced BASICs extended the line length or used dynamic buffers to avoid this. No official Radio Shack fix was ever released.

Workaround: Keep REM lines under 240–250 characters total (including "REM "). Split long comments across multiple REM lines, or store long text in DATA statements instead.

What is happening

The SET command builds a CHR$(xxx) graphic block, it doesn't actually put a dot on the screen. The ROM code checks to see if the character is not graphic or not graphic. If its graphic, it builds on the character forming the dot pattern. If it's not graphic, it resets it to a blank first, and then builds. The problem is, to test for graphic or not it tests the value by checking the M flag, which means its only going to properly reset the character if the character is less than 128. The ROM never checks to see if the character is more than 192, so it just adds more bits to that character.

The code which handles that is:

0176 B7        OR    A          ; CHECK IT
0177 FA7C01    JP    M,$017C    ; SKIP IF GRAPHIC
017A 3E80      LD    A,$80      ; GRAPHIC BLANK
017C 47        LD    B,A        ; SAVE SCREEN BYTE

Fix

George Phillips suggests that replacement code (which is 1 byte too long) would be:

LD  B,80H
   CP  64
   JP  NV,NOT_GFX
   LD  B,A
not_gfx: ... 

George explains that this works because as signed values the graphics characters are -128 .. -65. Subtract 64 as the compare does and they will overflow due to the result (-192 .. -129) not fitting in a signed byte. The special characters are -64 .. -1 and don't overflow. And none of the ASCII characters from 0 .. 127 overflow either.