[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
An example : Racer (actual dev release runs in 4 VBLs, whereas under hatari=
, it runs in 3 VBLs
doing a loop like this :
..outer_loop: move.w #320/2-1,d0
..inner_loop : move.l (a0)+,(a1)+
takes 6 VBLs under real hardware and only 4 VBLs under Hatari.
And I only speak about the "Real time" emulation, which takes quite correct=
cycles into account.
The MMU emulation (used by Doug) doesn't take into account the instructions=
cycles (nearly every instruction takes 2 cycles, so Hatari runs a lot too =
fast in MMU emulation mode).
The cache instruction mode is not completly accurate, but not that bad eith=
It may increase the speed difference by a little if activated, but I don't =
think this can be the real problem.
This probably join the precedent threads about Falcon accuracy (I don't spe=
ak about exact accuracy, but close accuracy here, of course).
----- Mail original -----
De: "Nicolas Pomar=C3=A8de" <npomarede@xxxxxxxxxxxx>
Cc: "Mariusz Buras" <mariusz.buras@xxxxxxxxx>
Envoy=C3=A9: Lundi 20 Janvier 2014 13:15:45
Objet: Re: [hatari-devel] Videl / VBL interrupt issue in Hatari?
Le 20/01/2014 13:11, Mariusz Buras a =C3=A9crit :
> Well, for instance, if your VBL routine would take almost entire frame
> to execute on real falcon, on Hatari it could be more then one frame to
> do the same task, so they would overlap.
AFAIK, BM doesn't run in 1 VBL on falcon anyway, more like 2 or 3 VBL=20
So this problem should already be taken into account, else it would not=20
work as soon as the 1st seconds of game.
Usually, when program doesn't run in 1 VBL, you will use a short VBL=20
code that mostly only set a VBL counter + a few others things that=20
really need to be real time (sound, music, ...), and then the main=20
program (outside of the VBL) waits for the counter to change before=20
working on the next frame.