|Re: [hatari-devel] Falcon raster emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 12/12/2013 13:46, laurent.sallafranque@xxxxxxx a écrit :
For example, running RACER on Hatari shows a difference of 2 VBLs with the real hardware (3 VBLs into hatari, 5 on the Falcon).
I'm pretty sure this is mainly due to the Videl bus access not taken into account into Hatari.
Note that maybe racer takes the cycles equivalent of 5 VBL under Hatari
too, but it's just the VBL counter that would be false under Hatari and
give 3 ?
If the Hatari's videl does a VBL every 250000 cycles instead of 200000
cycles (that's not real numbers), you will get the feeling your program
uses less VBL under Hatari.
So, we need first to be sure the number of cycles allocated to a VBL
under Hatari is correct regarding all possible video resolution/refresh
rate (maybe it's already the case, the math is quite simple, but it
would be annoying to look elsewhere if this part is not already good)
Nicolas, how can we easily add some cycles every X cycles into hatari that would freeze the bus access and allow only CPU internal cache instructions to work)
this is not easily possible, see below
A remark: maybe we don't need to add 19 cycles every X cpu cycles, but maybe 190 cycles every 10*X cpu cycles.
The CPU/DSP ratio seems quite OK, there's probably no need to add the videl cycles each time like in real, in order to keep a decent speed for the emulator.
On the other way, I don't think adding all the VIDEL cycles at once at the beginning of the VBL would be a good idea.
Instead of adding 19 cycles every X cpu cycles to the videl, another
easier approach is to consider cycles are all expressed in cpu units and
you apply a correction factor to get the videl equivalent only at the
time where you need to start the internal hbl/timer b counter.
for example :
CycInt_AddRelativeInterrupt ( hblcycles*correction_factor ,
INT_CPU_CYCLE, INTERRUPT_VIDEO_HBL )
Then you adjust correction_factor until you get the correct alignement
for the HBL interrupt (correction_factor could depend on the video
mode/resolution, since it can affect the number of allocated cycles to
To adjust correction_factor, you can have use a very simple program that
just do a wait loop and try to change color on every HBL's interrupt for
example, will all others components turned off (mfp, dma, ...) to
Then have different versions of this program (320x200, 640x200, vga,
whatever) and try to adjust correction_factor for each of these cases.
(I'm sure doug could write us such simple test programs :) )
This should give a general formula that can be applied to any resolution
when we need to set up the hbl interrupt.
Maybe it could benefit to sound later, but I think we must first try to
improve only one component (video) and see later if the method can be
extended to others. Trying to find a common method to all components at
once will just make things harder to code.