making C co-routines suspend, using timer interrupts?

[gtoal]

I'm working on a game that can be redrawn within the 50hz frame rate but which does a huge number-crunching computation whenever the human makes a move. I've been mulling over a general mechanism for this situation, which comes up a lot...


Here's a sketch of what I'm thinking might be possible...


static int long_computation_started = 0;

void do_some_long_computation(void) {
 long_computation_started = 1;
 // code to do number crunching that may take more than say 100,000 cycles to complete
 // and has no simple way of running in smaller chunks...
 long_computation_started = 0;
}

// main loop

for (;;) {
  Wait_Recal();

  Start_timer();                            // start a timer that will fire in just under 30,000 cycles

  // perform game logic and graphics that are known to finish in less than 30,000 cycles
  do_simple_computations();

  draw_frame();

  // we now have a variable number of cycles available until the end of the next scheduled Wait_Recal()
  if (long_computation_started == 0 && /* the computation is needed...*/) {
    start_thread(do_some_long_computation);  // runs until hit by interrupt, just short of 30000 cycles
                                             // since last Wait_Recal().  Information for "rti" is stored
                                             // in a static area for later.
  } else if (long_computation_started) {
     resume_thread();                        // restarts thread that was suspended on previous frame.
                                             // restores registers, jumps to where previous call was
                                             // interrupted.  Note that this code is still running as
                                             // a foreground process, it is not running as an interrupt
                                             // routine.  Again it runs until just short of when a WaitRecal()
                                             // is due.
  }

  // Either start_thread or resume_thread can return normally when the long background computation
  // is complete.  But if the computation is still running when the timer goes off, start_thread or
  // resume_thread will also return to here but with the computation unfinished and the info for
  // resuming on the next cycle stored in a static area ready for the next resume_thread()
}



The code that implements the thread may need to set up its own private stack. Can't rely on just using
static variables because simple C expression evaluation can make use of the stack and an interrupt may
hit during that part of the computation. So needs to be handled much like coroutines.

So the overall philosophy is *NOT* to run in an interrupt routine, but to run in the foreground until
interrupted, and return to the foreground loop when that happens. This is very much standard coroutines
except that the coroutine execution is stopped on a timer interrupt. The code then goes on to perform
a Wait_Recal() as it normaly would have, within the 30,000 cycle limit since the last one, and relies on
the normal computation and drawing being done in noticably less than that amount of time - for example in
27000 or 28000 cycles, with only a few thousand cycles free for the longer 'background' computation.

That's the theory. Now I have to think of a way to implement it (with your help...)

[Malban]

Hm.
Actually...

I think it might be easier to just use the T2 interrupt directly.

If you are sure the complete game w/o the subroutine is guaranteed to be under 30000 cycles.

Setup the T2 WaitRecal timer

Start mainloop, which always ends with a CWAI

In the main loop only do the long computation (or run into cwai)

The waitrecal does its usual work + everything that is NOT the long instruction - and always end in
an RTI ...

No worries about stack corruption, since the long thing is the only one that is ever intrrupted...

[gtoal]

Apr 28, 2020 9:57:42 GMT -5 Malban said:

Hm.
Actually...

I think it might be easier to just use the T2 interrupt directly.

If you are sure the complete game w/o the subroutine is guaranteed to be under 30000 cycles.

Setup the T2 WaitRecal timer

Start mainloop, which always ends with a CWAI

In the main loop only do the long computation (or run into cwai)

The waitrecal does its usual work + everything that is NOT the long instruction - and always end in
an RTI ...

No worries about stack corruption, since the long thing is the only one that is ever intrrupted...

Are you talking about setjmp and longjmp?  If not how do you re-enter the long computation?

And if you only do the long computation in the main loop, are you suggesting doing the graphics in the interrupt service routine?

Do you mean that I implement my own replacement WaitRecal()?

Sorry, not really following the details of your suggestion, could you sketch it out as a skeleton C code like I did above please?

G

[Peer]

Out of pure curiosity, what is this complicated number crunching alogrithm that you say can't be divided into smaller chunks?

Cheers,

Peer

[Malban]

Ok...

Working code:

I don't know what happens if the "gameloop" takes MORE than the T2 timer though.

Probably "long" will never happen than - and as soon as the 6809 interrupt is enabled - the interrupt function is called again...


#include <vectrex.h>

#define IRQ_6809_MASK 0x10
#define ENABLE_IRQ_6809 asm("andcc #0xef")
#define DISABLE_IRQ_6809 asm("orcc #0x10")

// does not return, since we use the
// actual waitRecal "shortcut" to jump to "set_refresh" and return from there
__attribute__((noinline)) void iWaitRecal() // if inlined, the JMP -> RTS goes astray!!!
{
Vec_Loop_Count++;
// I assume EVERYTHING is done with DP = D0
// BSR     DP_to_D0        ;DP to I/O
asm("jmp 0xF1A2"); // Set_Refresh
}
static int longWorkEnabled = 0;
static volatile int counter = 0;
static volatile int counterDummy = 0;

__attribute__((interrupt)) static void  gameLoop(void)
{
// for anything except the t2 timer we want to rti immediately.
if ((dp_VIA_int_flags & 0x20) == 0) return;

// DISABLE_IRQ_6809;

// do one "game loop"
char buffer[4] ={' ',' ',' ','\x80'};
buffer[3] = ((char)(counter & 0x7))+'0';
iWaitRecal(); // resets T2, resets IRQ, resets vectors
Intensity_5F();
dp_VIA_t1_cnt_lo = 0x80; // set scale = 80
Print_Str_d(100, -60, "LONG THING: \x80");
Print_Str_d(80, -40,buffer);
longWorkEnabled = 1;

// ENABLE_IRQ_6809;
}
#define IRQBASE 0xCBF8 // this must be IRQ not FIRQ!
unsigned long volatile * const IRQ = (unsigned long *) (IRQBASE+1);
unsigned int volatile * const IRQ_INST = (unsigned int *) IRQBASE;

#define WAIT_VALUE 15

int main(void)
{
*IRQ_INST = (unsigned int)0x7e; // JMP ... this is actually code!, first a JMP instruction
*IRQ = (unsigned long)&gameLoop; // to Address

// ensure timer is sensible to start with
dp_VIA_t2 = Vec_Rfrsh; // in RAM the BIOS default value of T2 = 30000 cycles


// enable T2 interrupt generation in VIA
dp_VIA_int_enable |= 0x20;
ENABLE_IRQ_6809;

while (1)
{
if (longWorkEnabled)
{
// do something long
for (unsigned long i1=0; i1<WAIT_VALUE; i1++)
{
for (unsigned long i2=0; i2<WAIT_VALUE; i2++)
{
for (unsigned long i3=0; i3<WAIT_VALUE; i3++)
{
for (unsigned long i4=0; i4<WAIT_VALUE; i4++)
{
// prevent optimizing loops away!
counterDummy++;
}
}
}
}
counter++;
}
asm("CWAI  #0xef"); // Wait for interrupt to happen
}
return 1; // cold reset - NOT REACHED
}



[Malban]

Hm the more I think about it - it is probably best in the gameloop to NOT change the IRQ flags, I think the cwai and rti handle that...

[gtoal]

Apr 28, 2020 16:05:36 GMT -5 Malban said:

Ok...

Working code:

Oh wow, you wrote actual working code!  I was just asking for a 10 line sketch so I could understand what you were trying to explain, but this is great, thanks!!!  I can use this as-is, once the game is working!

Peer:  the problem in this case *might* be breakable into smaller chunks with some effort, but in general a large computation is not going to be.  Think of something like a chess program for example, or a Scrabble program.  Or the 3d rendering calculations for Battlezone :-)

But to answer your question, Peer, it is an N^2 loop over a set of on-screen lines, to detect which lines intersect with other lines.  The code is at gtoal.com/vectrex/wangle/main.c.html and we're discussing it on Facebook at the moment. 

Thanks again Malban,

Graham

[gtoal]

So your gameloop drawing code is being done in the interrupt routine??? OK, that's the step I wouldn't have considered, because my own previous experiments with interrupt-driven I/O were not very successful - a few calls would work but others wouldn't, and the slightest change to my code would blow everything up (and I don't mean the asteroids... :-) ) But that may have been down to something stupid on my part, I would imagine your version of this is going to be robust - I can't wait to try it! (So I won't - heading there right now...)

So I understand now. My idea had been to draw in the foreground and compute in the ISR; your version is to compute in the foreground and draw in the ISR. If drawing in the interrupt service routine can be made as reliable as in the foreground, then that's a good solution because the drawing code has no register state between frames, whereas the computation code can't easily exit and restart.

I'll see if I can find an existing program of mine and adapt it to use this code.

G

[gtoal]

Looking at my previous effort in the style of your code above, the main difference I see is the use of CWAI ... otherwise it's fairly similar... gtoal.com/vectrex/interrupter/graphics.inc.html

[Malban]

I don't know how "stable" this is.
I hacked it together in 1/4 of and hour.

The base was indeed my old IRQ code from the other thread.
The example provided seems to work fine.

I just commented out the IRQ DISABLE/ENABLE thing in the main loop.

Keeping them enabled might lead to an interrupt recursion -> and thus lead to a stack overflow.
Indeed the CWAI and the RTI take care of the IRQ flag.