Option ROM Programming - Revision history

64.81.88.222: /* Concept: Running BASIC code from OptROM */

2008-02-22T18:31:56Z

Concept: Running BASIC code from OptROM

← Older revision		Revision as of 11:31, 22 February 2008
Line 1:		Line 1:
	[[Running BASIC Code from OptROM]]		[[Running BASIC Code from OptROM]]

	~~== Concept: Running BASIC code from OptROM ==~~

	~~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. It's 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 option rom, 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).~~

	~~From conversation with Kenneth Pettit:~~

	~~Hi John,~~

	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.

	As for the BASIC debugger, I have the advantage of being able to "see" what the CPU and ROM are doing and can intervene with the "Almighty hand of God" as needed to perform debug operations. So the debugger isn't bound by the same rules as running from OptROM, but it does need to be aware of the interpreter operation.

64.81.88.222 at 18:31, 22 February 2008

2008-02-22T18:31:09Z

← Older revision		Revision as of 11:31, 22 February 2008
Line 1:		Line 1:
	[Running BASIC Code from OptROM]		[[Running BASIC Code from OptROM]]

	== Concept: Running BASIC code from OptROM ==		== Concept: Running BASIC code from OptROM ==

64.81.88.222: /* Concept: Running BASIC code from OptROM */

2008-02-22T18:30:51Z

Concept: Running BASIC code from OptROM

← Older revision		Revision as of 11:30, 22 February 2008
Line 1:		Line 1:
			[Running BASIC Code from OptROM]

	== Concept: Running BASIC code from OptROM ==		== Concept: Running BASIC code from OptROM ==

64.81.88.222: /* Concept: Running BASIC code from OptROM */

2008-02-22T18:06:57Z

Concept: Running BASIC code from OptROM

← Older revision		Revision as of 11:06, 22 February 2008
Line 20:		Line 20:
	re-figure out what's what (in any case I got all my info from Robert		re-figure out what's what (in any case I got all my info from Robert
	Covington's ROM maps in the DLs).		Covington's ROM maps in the DLs).

			From conversation with Kenneth Pettit:

			Hi John,

			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.

			As for the BASIC debugger, I have the advantage of being able to "see" what the CPU and ROM are doing and can intervene with the "Almighty hand of God" as needed to perform debug operations. So the debugger isn't bound by the same rules as running from OptROM, but it does need to be aware of the interpreter operation.

64.81.88.222: New page: == Concept: Running BASIC code from OptROM == 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 th...

2008-02-22T00:46:46Z

New page: == Concept: Running BASIC code from OptROM == 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 th...

New page

== Concept: Running BASIC code from OptROM ==

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. It's 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 option rom, 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).