Date   : Tue, 24 Jan 1995 15:44:14 GMT
From   : David Alan Gilbert <gilbertd@...>
Subject: Re: REVS Timing

> > I found it impossible to keep exact time AND get good performance.
> > On your faster PCs and in machine code, the task becomes feasible.
> > It's really only REVS which is fussy which is why gave up and implemented
> > a REVS cheat. It's a lot of effort just for the benefit of one game.
> > Getting the timing absolutely bang-on seems to me a real herculian
> > task. I can just imagine the agony of watching the REVS interrupts
> > scroll very, very slowly up the screen...
> > 
> 
> Well, I think that as long as the via timeouts are checked for after every
> opcode there should not be a problem, even if the actual opcode ticks are
> not quite right.

Doesn't help - my emulator checks after each instruction and still has Revs
trouble.

>  The problem seems to be caused by the variable delay
> between when the IRQ should have been flagged and then it actually occurs.
> Checking after every code should (at least) reduce the problem.  I just
> wonder how Revs on the real bbc manages to deal with different interrupt
> times, depending on when the timer irq actually happens.  Compare, for
> instance you're doing a 7 tick opcode and a 3 tick one.  Say the irq
> happens just after the instruction starts.  The first has a delay of 14
> ticks, and the latter 10.  Any ideas how revs actually deals with this
> slight error, which would increase over time.

Not too mention the indeterminate amount of time caused by cycle extension
when accessing Sheila.

I think it does a timing loop somewhere - I see a small run near the start
of accesses to User VIA timer 2, I'm guessing its doing a timing loop - and then
using that to set something else up - but thats pure guess work - I haven't
yet done
any serious disassembly of it.

Dave