+retroclouds Posted September 11, 2021 Share Posted September 11, 2021 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? Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 11, 2021 Share Posted September 11, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted September 11, 2021 Author Share Posted September 11, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.