Date   : Mon, 26 Sep 1994 13:30:18 WET DST
From   : Bonfield James <jkb@...>
Subject: Re: Pinching PC interrupts

Chris Lam wrote:
>are you trying to use PC interrupts to generate your beeb interrupts? someone
>else tried this (james bonfield i think) and i don't think it worked.
>and even if it did show signs of working, controlling the timing of the 
>interrupt would be a real bugger because the PC int will be in realtime and
>your beeb emulator obviously isn't.

I used the UNIX itimer system, which is the equivalent of interrupts. It does
indeed work, but is indeed awkward. I've now decided it's probably not worth
the extra hassle. There's a whole host of extra problems to worry about, such
as getting interrupts within your own interrupts handling routine. This proved
somewhat awkward for me to solve due to apparent buggyness in some systems
signal handling code.

>the way i've done it is to update your VIA timers after each opcode, and
>if there's a time out, pass control to the IRQ handler at (&FFFE/F). a bit
>slow to check after every opcode so i'm now checking after every 15 or so.

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. Then once we've got here we have the more complex
task of figuring out precisely what has timed out, and what needs updating.
However this task isn't being performed each instruction and hence doesn't
need to be blindingly fast.

Obviously you need to be wary of code that accessing things such as the
timers. Here our 'memory hook' would see how long has past since the last
update (by looking at the time left untill the next) and would adjust as
necessary prior to the actual memory access.

I'm sure it's not quite this straightforward. I'll find out soon I guess.
However the general principle should work fine.

       James B.