Date   : Mon, 26 Sep 1994 14:19:31 +0000
From   : lamcw <lamcw@...>
Subject: Re: Pinching PC interrupts

Bonfield James wrote:

;This is more or less how I'm going to reimplement mine. However you note that
;checking every 15 instructions is faster than checking after every one.
;However to check every 15 still requires a check of how many we've got left.
;My opinion is that we should work out the amount of time left until the next
;interrupt (from a variety of sources). This is worked out when that interrupt
;source is accessed. Eg resetting the T1 timer.

;Then we decrement this time each opcode execution by the appropriate time,
;checking to see if we've clocked past zero. This is no more complex then
;counting to 15 instructions.


won't you need to decrement and check for EACH possible interrupt? my structure
is


  loop:

      for (i=1;i<=15;i++) { execute opcode }

      { update timers, do IRQ if needed }

  goto loop;


i've found that doubling 15 to 30 doesn't offer much more performance and
it's wise to keep the sampling resolution as fine as possible (in order to
be as accurate as possible)



;Obviously you need to be wary of code that accessing things such as the
;timers.

yes, quite possible for interrupts to be 'reset' to their initial time before
they're timed out. one-shot interrupts must only time out once ( and cause an
int) but strictly they will continue decrementing.


interestingly enough, i've not encountered one game that uses the system T2
as a one-shot int... such is the respect for the speech system.


chris lam.