[no subject]

- The videl can run at 2 frequencies : 32 and 25 Mhz
- There are some internal bits that allow to double / quadruple the X or Y =
axis for better speed.
- The video can be RGB, VGA, monochrome monitor, ...


I think only a mathematic formumla could take into account all the case (th=
ere are not so much parameters to take into account, but too much different=
 resolution case to test). Of course, it would be great to have some specif=
ic case tests to verify if all is OK, like=20

- 320*100    2 ,4, 16, 256 ,true colors for RGB and VGA
- 320*200    2 ,4, 16, 256 ,true colors for RGB and VGA
- 640*400    2 ,4, 16, 256 ,true colors for RGB and VGA

If I launch hatari in 16 colors, it runs much faster than if I run it in tr=
ue color.
When I run the 1600*600 demo (which displays a picture on a 1600x600 16 col=
ors screen), it takes a long time to display (in many frames). At first gla=
nce, it looks like hatari adapts the VBL value to the resolution already, b=
ut it would be great to validate this and validate the VBL timing for some =
resolutions.

OK then for using the HBL + correction trick, it's a good idea.

Laurent


----- Mail original -----
De: "Nicolas Pomar=C3=A8de" <npomarede@xxxxxxxxxxxx>
=C3=80: hatari-devel@xxxxxxxxxxxxxxxxxxx
Cc: "laurent sallafranque" <laurent.sallafranque@xxxxxxx>, "Douglas Little"=
 <doug694@xxxxxxxxxxxxxx>, "Miro Krop=C3=A1=C4=8Dek" <miro.kropacek@gmail.c=
om>
Envoy=C3=A9: Jeudi 12 D=C3=A9cembre 2013 14:07:10
Objet: Re: [hatari-devel] Falcon raster emulation

Le 12/12/2013 13:46, laurent.sallafranque@xxxxxxx a =C3=A9crit :

> For example, running RACER on Hatari shows a difference of 2 VBLs with th=
e 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.

Hello

Note that maybe racer takes the cycles equivalent of 5 VBL under Hatari=20
too, but it's just the VBL counter that would be false under Hatari and=20
give 3 ?
If the Hatari's videl does a VBL every 250000 cycles instead of 200000=20
cycles (that's not real numbers), you will get the feeling your program=20
uses less VBL under Hatari.

So, we need first to be sure the number of cycles allocated to a VBL=20
under Hatari is correct regarding all possible video resolution/refresh=20
rate (maybe it's already the case, the math is quite simple, but it=20
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 tha=
t would freeze the bus access and allow only CPU internal cache instruction=
s 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 ma=
ybe 190 cycles every 10*X cpu cycles.
> The CPU/DSP ratio seems quite OK, there's probably no need to add the vid=
el cycles each time like in real, in order to keep a decent speed for the e=
mulator.
> On the other way, I don't think adding all the VIDEL cycles at once at th=
e beginning of the VBL would be a good idea.

Instead of adding 19 cycles every X cpu cycles to the videl, another=20
easier approach is to consider cycles are all expressed in cpu units and=20
you apply a correction factor to get the videl equivalent only at the=20
time where you need to start the internal hbl/timer b counter.

for example :

CycInt_AddRelativeInterrupt ( hblcycles*correction_factor ,=20
INT_CPU_CYCLE, INTERRUPT_VIDEO_HBL )

Then you adjust correction_factor until you get the correct alignement=20
for the HBL interrupt (correction_factor could depend on the video=20
mode/resolution, since it can affect the number of allocated cycles to=20
videl).

To adjust correction_factor, you can have use a very simple program that=20
just do a wait loop and try to change color on every HBL's interrupt for=20
example, will all others components turned off (mfp, dma, ...) to=20
minimize artefacts.
Then have different versions of this program (320x200, 640x200, vga,=20
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=20
when we need to set up the hbl interrupt.


Maybe it could benefit to sound later, but I think we must first try to=20
improve only one component (video) and see later if the method can be=20
extended to others. Trying to find a common method to all components at=20
once will just make things harder to code.

Nicolas