Re: [hatari-devel] Falcon raster emulation

[ Thread Index | Date Index | More 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 videl).

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 minimize artefacts. 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.


Mail converted by MHonArc 2.6.19+