IntyBASIC Exit End Stop Quit under JzIntv?

[First Spear]

What is the best way to properly quit an IntyBASIC program, so when it is running under jzIntv it returns to the launching environment (eg command prompt/console)?

 

I put a label at the end of my program, code happens to be running in ROM segment 5:

 

ExitThis:
Wait

Voice Init

Wait
Play Off

 

 

I have a main loop, and on keypress it does a GOTO ExitThis. However, the loop then continues on and the program does not simply "fall out".

 

I don't remember why I never asked this before. I know in a real cart there is no such thing as an exit, but I do want to do a graceful end under emulation while testing.

 

Thanks.

[carlsson]

Is there even a such thing that from the emulated environment cause the emulator to quit? It would assume writing to some otherwise unused memory address would trigger the exit function.

 

I suppose you can on purpose make the emulator go "out of the woods", i.e. crash but not sure if that is what you mean by graceful exit.

[+DZ-Jay]

What is the best way to properly quit an IntyBASIC program, so when it is running under jzIntv it returns to the launching environment (eg command prompt/console)?

 

I put a label at the end of my program, code happens to be running in ROM segment 5:

 

ExitThis:

Wait

Voice Init

Wait

Play Off

 

 

I have a main loop, and on keypress it does a GOTO ExitThis. However, the loop then continues on and the program does not simply "fall out".

 

I don't remember why I never asked this before. I know in a real cart there is no such thing as an exit, but I do want to do a graceful end under emulation while testing.

 

Thanks.

 

There is no such thing as "exiting to the launching environment" from the game program. The emulator will quit cleanly and gracefully. Perhaps what you are trying to avoid is a "HLT" that crashes the emulation and drops to the debugger inadvertently?

 

However, if you want this for development purposes (recall, there is no "quitting" the Intellivision console, except by turning it off or resetting it), then you can create a simple debug script that does the following:

• Sets a breakpoint ("b") on an "exit" branch in your code.
• Then issues the quit ("q") command to the debugger.

You can invoke the debug script from the launch command-line by adding the following options "-d --script={path}". The debug script is just a list of debugger commands, one on each line, like this:

; Script to quit from the program (???)
r               ; Run program, do not halt execution
h               ; Enable CPU history tracking
b MY_EXIT_SUB   ; Break on reaching this spot
d               ; Dump CPU history to file
q               ; Quit debugger 

For your purposes, you only need the first ("r"), third ("b"), and last ("q") commands. Just make sure that "MY_EXIT_SUB" is a suitable label that is only reached when you are ready to quit. The first one ("r") is important, otherwise, running the emulation with the debugger enabled will halt the program and start at the debugger command prompt.

 

However, I don't know what would be the advantage of that over just quitting the debugger manually. *shrug* In fact, the latter is "cleaner," since it doesn't require non-production-ready or special-development-time code that needs to be removed before release.

 

(Remember that any code you change or remove when turning a "development" build to a "production" one introduces yet another chance for bugs to creep in, and needs to be tested thoroughly. I speak from experience: the "critical bug" included in the original Christmas Carol release came from a last minute "optimization" related to the removal of what appeared to be inert "dead code.")

 

-dZ.

Edited January 4, 2019 by DZ-Jay

[+DZ-Jay]

Is there even a such thing that from the emulated environment cause the emulator to quit?

 

Not the emulator directly, but you can instruct the online debugger to quit jzIntv altogether, and the debugger can be scripted. *shrug* I can't fathom a good reason for this other than avoiding the effort of hitting F1, but everyone's mileage may vary.

[intvnut]

jzIntv will exit when it thinks the program has crashed. An "ASM HLT" will accomplish that.

 

On a real Intellivision, HLT will halt the CPU and prevent it from taking interrupts. If you're using an LTO Flash, it should pop you back to the LTO Flash menu.

[+DZ-Jay]

jzIntv will exit when it thinks the program has crashed. An "ASM HLT" will accomplish that.

 

On a real Intellivision, HLT will halt the CPU and prevent it from taking interrupts. If you're using an LTO Flash, it should pop you back to the LTO Flash menu.

 

Yes, but if the original point was to "quit gracefully," a HLT doesn't sound like the right thing to do -- especially if the emulator quits with a STDERR code.

 

-dZ.

[intvnut]

 

Yes, but if the original point was to "quit gracefully," a HLT doesn't sound like the right thing to do -- especially if the emulator quits with a STDERR code.

 

It prints "HALT!" and the address at which we halted, and does exit with status 1 (which is what I think you mean by "STDERR code").

.

HALT! PC=700D Instr =       2974 MS =      236860

.

It's the most graceful mechanism I currently have, unfortunately, unless you want to use a debugger script. I do need to change that, as my eventual goal is to allow writing unit tests with jzIntv. That's one reason jzIntv comes with a "batch mode" emulator now as well (jzintv_batch).

[+DZ-Jay]

 

It prints "HALT!" and the address at which we halted, and does exit with status 1 (which is what I think you mean by "STDERR code").

.

HALT! PC=700D Instr =       2974 MS =      236860

.

It's the most graceful mechanism I currently have, unfortunately, unless you want to use a debugger script. I do need to change that, as my eventual goal is to allow writing unit tests with jzIntv. That's one reason jzIntv comes with a "batch mode" emulator now as well (jzintv_batch).

 

Yes, I meant an error status code (non-zero).

 

The debugger script sounds to me like a cleaner version (which I think was the original request). Besides, it's not like an onerous thing: you can use the same script for all your programs and you just "set it and forget it."