Running BASIC Code from OptROM

This is a place for collecting thoughts on how to embed and run BASIC code in an OptROM. Clearly, this is possible since UR2 implements Idea as a BASIC program.

Short Conversation from M100SIG

Fm: Stan Wong 70346,1267 To: Denny Thomas 76701,40

Paul's on the right track about the Basic interpreter. The Basic code never moves but there is a ROM call that interprets each tokenized statement. Other ROM routines find the next statement to execute. Its been a while but my memory is sort of dim on the subject but each BASIC statement in storage is prefixed with the line line followed by the statement tokens followed by a null. Three nulls indicate the end of the program (end-of-statement null followed by a line number of zero).

A small program could switch to the OptROM, read a BASIC line (tokenized) into RAM, switch back to system ROM, and then feed it to the interpreter loop. There is no housekeeping since BASIC takes care of it. Oops, I forgot, as part of each line I believe that there is also the address of the next statement. That needs to be fixed up also. Anyway, it's a fairly starightforward proposition. If there is any interest I can dive back into my notes and re-figure out what's what (in any case I got all my info from Robert Covington's ROM maps in the DLs).

Thoughts from Ken Pettit

I have looked a the BASIC interpreter quite a bit. The main program execution loop (for M100) is at address 0804h. The first few function calls perform things like checking for ON COM, ON TIME, CTRL-BREAK, etc. The middle part executes the next instruction, and the last part steps forward to the next instruction / line #. This routine would have to be rewritten to run in RAM and fetch BASIC lines from OptROM. Additionally, the routine below it would have to be rewritten too - it pushes the 0804h return address on the stack that most BASIC instructions use by doing a simple "RET' . This would have to push the address of the re-written RAM based loop.

The problem areas will be in handling the ON TIME, ON COM, ON KEY, and STOP (CTRL-BREAK uses the STOP instruction). From what I remember, these perform an absolute "JMP" into the ROM which then lead back to the 0804h loop and/or search for line numbered BASIC lines in RAM.

How the BASIC Interpreter Works

This disassembly of the Altair BASIC interpreter, though not the same code, should shed some light since it is so well commented (Phil Avery hipped me to this resource):

Altair BASIC Walk-Through

In particular, not the "Execution" section 1.9 which is relevant to this problem.

Running BASIC Programs: Excerpt from Hidden Powers of the TRS-80 Model 100 (Chris Morgan)

The next major area of memory contains the code that runs BASIC programs. This is the heart of the BASIC interpreter. This section extends from about 804h = 2052d to 871h = 2161d.

This code has to check several conditions as it keeps running your program. The first thing it checks is the communications line, by calling a routine located at 6D6Dh = 28,013d (see Chapter 7). Then it checks for an interrupt from the real-time clock by calling a routine at 4028h = 16424d (see Chapter 5). Next it checks for a break from the keyboard by calling a routine at 13F3h = 5107d (see Chapter 6).

The BASIC interpreter then looks for a colon indicating the next statement of a multiple statement on a BASIC command line. Finally, it checks for the end of the program. It returns to the command loop via a jump to 428h = 1064d if the program has indeed ended.

If the program has not ended, interpretation continues. The current line number is stored in location F67Ah = 63,098d, and then the interpreter dispatches to the routine to handle the keyword for the BASIC command currently under consideration. It points to the address table for BASIC commands. It is interesting to note that the last part of the dispatching routine (locations 858h = 2136d) uses the same code as is used by the RST 2 routine to check for numbers and skip over spaces.