Detect if TI Basic is running a program

[+retroclouds]

Is there an easy way to detect -from an assembly program running on the ISR-, if TI Basic is in command mode or if it is running a program?

 

Please note, that I’m talking about TI Basic as included in the TI-99/4a console.

I’m not talking about Extended Basic or any of the derived basics in a cartridge or FG99.

 

Perhaps, some background information. I’m jumping into TI Basic out of my Stevie editor after setting a ISR that allows me to return to the editor. The way I’ve implemented right now is plain easy, but also kinda cool. I just check the sound address in scratchpad memory.

If it’s set it just returns to the editor. Reason why it’s kinda cool is, that as soon as TI Basic honks because of a syntax error or similar, you are returned to the Stevie editor.

Will probably change that in the future, but as it is now it’s really easy to return to the editor.

 

What I have in mind is, that after I jump into TI Basic the ISR kicks in and pokes TI Basic tokens into VDP memory.

Or is it possible to setup VDP memory in advance and jump into TI Basic without it going through its initialisation where it clears VDP memory?

 

[Tursi]

Yes... this is what Classic99 injects into TI BASIC programs to detect if they are breakpointed (when creating a BASIC loader cart, there's an option to prevent that )

* The protection code itself - checks if the BASIC program is still running.
* if not, it resets the console.
PROTECT
	MOV @>8344,R0	* Test state - 0=not running
	JEQ REBOOT
	MOV R11,R0      * Save return address (CLEAR test only uses R12)
	BL @>0020		* use the console routine to check CLEAR
	JEQ REBOOT
	B *R0			* all okay
	
REBOOT
	CLR @>83C4		* Disable interrupt
	BLWP @>0000		* reset
	

The first test shows 1 when running and 0 when not running, unfortunately, pressing FCTN-4 to break the program doesn't clear the flag until the user presses enter at the prompt (any command, even empty). That's why I added the FCTN-4 check too. (If the program exits naturally, it resets to 0, but if an error occurs it is set to 0xff until the user presses enter).

 

I suspect my code should be testing not equal to 1 rather than equal to 0, to catch errors too... but that's okay.

 

I don't know where this info came from though... so there may be a better way.

 

[+retroclouds]

Thanks @Tursi that is most valuable.

I knew there was a tool out there. Just could not recall that it was built right into classic99.