Hello,
I have made a program in ASM, what text displayed. Very simple.
The only thing is, when I click at ON on my calculator. The rest of my program will executed really fast and it doesn't wait at b_call(_getKey)
I think there is some kind of "ON-flag" and when that flag is ON, than will be in the rest of the program b_call(_getKey) skipped.
Greetings,
oguh
Interesting. I don't believe there is an 'ON-flag' and I don't remember exactly what causes that -- but I'm sure someone like Kerm knows a solution
You could try looking at the source for
ONBLOCK, which uses interrupts.
Code: res onInterrupt,(iy+onFlags)
bcall(_getKey)
That should do it, I think.
Thanks to calc84maniac the problem is solved.
Thanks,
oguh
calc84maniac wrote:
Code: res onInterrupt,(iy+onFlags)
bcall(_getKey)
That should do it, I think. And that's the ON flag. Thanks for that, calc84!
To unnecessarily tack on additional information, that flag is also responsible for "ERR:BREAK" when running an assembly program from within a BASIC program.
When the calculator turns off, it sits and waits for an ON interrupt to occur. When it does, the TI-OS' interrupt handler realizes the calculator is off, turns it on, and then jumps to _Mon, the TI-OS system monitor. That's the event-driven core of the OS that is responsible for the homescreen, Y= editor, GRAPH screen, the program editor, (in fact all contexts), pull-down menus, etc. It's why your program doesn't return when you call _PowerOff; it never gives control back to you, it just moves onward to _Mon (and never cleans up where your assembly program was copied to userMem, which is why you get memory leaks when turning off your calculator from within _getKey).
If it was already on, then it just sets onInterrupt,(iy+onFlags) from within the interrupt handler.
The TI-OS checks that from within the BASIC parser to decide whether to throw ERR:BREAK and break out of a BASIC program.
Indeed; when I was about halfway through my z80 ASM programming career between the present and my first forays into z80, I discovered that that's how the TI-OS works, and I was quite surprised. I always assumed it was a much more linear model, where the homescreen was something akin to a "main loop", and the other functionality like the graphscreen, the program editor, running programs, running apps were more or less called from that main loop.
Lol, I assumed the exact same;)