While in it original form it can already be useful (esp. for embedded apps), the original Tiny Basic interpreter is very rudimentary and is lacking many features. During the same time, another Tiny Basic version emerged. It was a classic interpreter (no intermediary code) but had a bit bigger feature support. 

With some minor tweaks, I was able to largely close the gap. What is missing:

• Multiple statements on same line (there is limited support: only in run mode, and only after INPUT, LET, POKE, PUSH, POP statements. FOR/NEXT must be own statement, PRINT already uses ":", and for GOTO / GOSUB / RETURN makes little sense as they "jump" and not continue execution)
• Logical operators in assignments
• Specifying field length when printing values

On the flip-side:

• TB executed on Basic CPU is >5x faster than same Basic code on classic Tiny Basic interpreter on 8080 (35s vs. 197s both running at 25MHz)
• Better handling of control codes (all ASCII control codes can be embedded in the print string using ^, including CR (^M))

Here is the list of new capabilities and how they were implemented. Depending on the feature, changes were needed in any of the code layers (interpreter or microcode), or in hardware itself (Basic CPU)

:T2    BC T3, "%"        //factors separated by modulo
    JS FACT
    LN 27            //a % b = USR(27, a, b)
    SX 1
    SX 5
    SX 1
    SX 4            //rearrange stack so that 0x001B (USR code) is at the bottom
    SX 1            //swap TOS and NOS
    SX 3
    SX 1
    SX 2
    US
    BR T0
:T3       RT

:F2       BC F2ABS, "PEEK"    // peek function
    LN 20            // peek is usr(20, param, param), always PEEK8
    JS FUNC
    BR F2CONT

// POKE
:POKE    BC RETN, "POKE"
    LN 24        //POKE = usr(24, address, byte)
    JS EXPR        //address
    BC *, ","    //expect comma
    JS EXPR        //byte value
    US
    SP        //drop usr() return value
    NX

The CPU and the microcode both support the full functionality, it is just a matter of which version of interpreter is presented to the CPU:

• Original from 1976
• Extended from 2025

In the project, both are present and can be selected by flip of the switch. This can be done safely when the interpreter is in command mode, waiting for input (executing GL instruction). To differentiate, different prompt characters are used ( > original, vs. : extended)

I implemented FS (FOR start) and FE (NEXT) to leave on top of evaluation stack the line number of next instruction to be executed, which can be:

This way, FOR/NEXT branching boils down to executing a GO instruction. Which already has the GOTO cache hooked up, so FOR / NEXT loops can benefit from caching too.

Comparing the benchmark results for Basic code on original interpreter vs. the extended, the extended runs 3% faster:

• Multiple assignments in LET save some parsing time
• FOR/NEXT instead of IF/GOTO saves parsing individual statements while still using the GOTO cache.

Extended, at 100MHz:

Original, also at 100MHz: