[TI ASM] Interrupts

[chickendude]

So I think I'm starting to get a grip on ISR's and how to use them, but what exactly do you do with them? Like, what are practical uses for interrupts in games?

[CoBB]

One obvious application is greyscale. Apart from that, you can use it for timing, e. g. to keep a constant framerate regardless of the amount of sprites drawn by having a frame refresh at every nth interrupt (I think Sqrxz does this) or just to run a clock of some sort (which can also be used direct events not initiated by the player). I can't think of anything else at the moment that would necessitate their use.

[Gambit]

If you want some more info on the latter part of what CoBB said (events), see Event Handler (oriented towards the 85/86, but you can adapt for the 83/83P/84P).

[Dwedit]

Multithreading is one place where you would want to use interrupts. You can have one part of the program be busy, and the other part be responsive. Another use of interrupts would be an emergency Quit key, so if the main program crashes, but interrupts are still working and enabled, you can still exit the program.

Yet another use of interrupts would be a FPS counter. On my TI83, there were ~106.13 interrupts per second, you can do the math to calculate frames per second, or do other timing independent of program speed.

[threefingeredguy]

On the 83+SE/84+/84+SE you can set them and the timers to certain settings to produce sounds at constant frequencies.

[chickendude]

Thanks for the link, I read through it and that seems fairly handy. An event handler would standardize the speed throughout the program, wouldn't it? It would be just as fast with one ship moving as with three or four?

And Dwedit, with multithreading... Do you mean, for example, that while waiting for the user to press a key or to make a selection, an AI script could be running in the background (as an interrupt) planning the AI's next move?

Sorry for all the questions, I've just always been interested in interrupts, but they've seemed so far away...

[Dwedit]

With multithreading, it wouldn't really be so much running in the interrupt handler, it would actually switch over to a different task, work on that, then an interrupt happens and it switches back to the main task. By pushing and popping all registers, and moving the stack pointer, you can give each task their own set of registers and stack.
The interrupt handler is small, so that part would just switch the task over.

So you can have two tasks, each running at slightly less than half speed. If you write in a way for the tasks to say they are idle, and request running a different task, then a small task like moving a cursor might get 3% CPU usage, and the AI could get 96% CPU usage.

[Liazon]

Apart from that, you can use it for timing, e. g. to keep a constant framerate regardless of the amount of sprites drawn by having a frame refresh at every nth interrupt

That's a great idea I can't believe I didn't think of!!!!

It solves my framerate problem because right now, if the screen's scrolling, the sprite looks too blurry on my 68k, but it looks fine on the edge of the map when the camera no longer follows the sprite.

What's even better, is I've got like 7 interrupts I could possibly disable, although it's safer to only disable 1 and 5. So now I can still have my regular timer as a second interrupt because I'm going to have to disable 1 and 5 for low level key input.

[chickendude]

So you'd have a counter within the interrupt, and if it was between, say, 0 and 90, you'd run one script, and if it was between 91 and 100, you'd jump to the other...

As far as the stack goes, I'm not too familiar with all the tricks people use it to do. Would you just increase (or rather, decrease, I believe?) the stack pointer maybe 30 bytes when you switch to the second script to give the first script 30 bytes of stack space and the second script the rest of it? Then, pushing and popping the registers between the scripts wouldn't get mixed?