Re: [hatari-devel] Falcon raster emulation

[laurent.sallafranque@xxxxxxx]

Hi,

I totally agree too with what was said before.

Just for your info, some parts of the Videl code are actually taken into account into video.c (the ST video emulation).
It's the case of the HBL for example.

I can easily upload my already full Videl video source to Hatari, but before, I think we should take into account the globaly too fast CPU.
My previous try showed too much instability because of it. (the video change was "jumping" really too early.


The main idea would be much closer to the real hardware (I have not said accurate ;)

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.

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)

The idea would be to let the Videl "access" to the RAM in burst mode and consume it's 19 cycles every XXX cycles of CPU.
I think in true color or in 256 color, this would slow down the CPU to a closer speed (the DSP would still have the same amount of slice time, but the CPU would do less instructions. There's no CPU cycle timings involved here, only the VIDEL taking the BUS for video refresh.

Then, if Racer runs at approximatly 5 VBLs (like on the real hardware), I would consider the clock as much better and the Videl emu could be implemented.

Maybe the crossbar sound cycles should be added too, but I'm sure it takes less "BUS cycles" than the Videl does.


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.

This could probably be tuned later (as it was done for spectrum512 for the ST part for example).

All of this would also benefit to the crossbar and the sound quality.


Regards
Laurent
 



----- Mail original -----
De: "Nicolas Pomarède" <npomarede@xxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Cc: "Douglas Little" <doug694@xxxxxxxxxxxxxx>, "Miro Kropáček" <miro.kropacek@xxxxxxxxx>
Envoyé: Jeudi 12 Décembre 2013 11:26:24
Objet: Re: [hatari-devel] Falcon raster emulation

Le 12/12/2013 11:15, Douglas Little a écrit :
>     We don't want to reach cycle precision as on STF where it's required
>     to do fullscreen, having a interrupt on every raster should be
>     enough to improve a lot of things
>
>
> I agree - the Falcon shouldn't be treated as a constant-time machine as
> with the ST, since trying to program it that way would produce
> unreliable results in the real world.
>
> However I also think the CPU cycle speed is secondary to the system
> clock structure - MFP, Videl and to an extent other bits.
>
> The DSP is currently emulated with 'catchup' behaviour, subservient to
> the CPU. I imagine it's not so easy to do this with the CPU itself -
> especially if both Falcon and ST emulators are in the same design. But
> something like that is probably a better structure for Falcon emulation.
> It also more closely approximates what would happen if the CPU is
> changed or accelerated.
>

The model common to all emlated machine is that the CPU clock is the 
master clock, then other components' clock are derived from this clock 
by applying a ratio.

For example, this would mean that when a CPU instruction take 8 cycles 
to run, then you must run the DSP for 16 cycles (16 to 32 MHz ratio)

On the opposite, if the CPU runs for 1000 cycles, you must give the MFP 
6.53 cycles (16 to 2.45 MHz ratio)

In the end, this should not give any noticeable difference to have the 
cpu clock as the master clock, because in nearly all cases it the cpu 
that drives the computer.

So, even on real machine,  if one cpu instruction last 20 cycles, you 
have no way to know how the corresponding 40 cycles were spent in the 
DSP. What really matters it that at the instruction level all components 
complete their job in the required time.

If the CPU is changed or accelerated, you need to adjust the ratio, but 
note that it would be the same if we had a global 32 MHz master clock.
16 MHz CPU would give a 1/2 ratio, 8 MHZ a 1/4 ratio and so on.
Eventually, you just manage ratio and associate a ratio to each 
component (integer ones in most cases, but sometimes not)


Nicolas