Re: [hatari-devel] Falcon emulation accuracy

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On sunnuntai 27 heinäkuu 2014, Douglas Little wrote:
....
> Experience with various tests, optimizations and using the sampling and
> Hatari profilers has built up a picture of some of the differences. It's
> not a perfect picture but it's getting clearer.
> 
> - Hatari is consistently faster at accessing RAM, particularly in the
> higher-bandwidth video modes, relative to real HW.

I don't think there's any emulation of VIDEL's screen refresh effect
on available memory bandwidth.


> - Indexing data (e.g. translating indexed colours through a table) is
> often faster on HW due to presence of datacache.

Missing data cache emulation.  I wonder whether newer WinUAE would
have that. (Or isn't existing WinUAE CPU core code for that wired
into Hatari?)


> - Fully-cached code seems a bit faster on real HW, in some cases at least
> (A:mux is fully i-cached but does not use datacache).

So I-cache emulation isn't accurate either?


> - Uncached/codegenerated routines (and i-cache misses) are slower on real
> HW, especially in high bandwidth video modes. This is probably contention
> between instruction and data fetching combined with Hatari's bus access
> being quicker.

Not just video side memory accesses delaying instruction fetches?


> - DSP/host port timing is unclear but it seems like the Hatari port is
> slower, perhaps as a compatibility helper to make up for the faster CPU
> execution for uncached code. (R:TexStream is solid contiguous writes to
> the DSP). The DSP timing is accurate, but timing of exchanges over the
> host are not (R:VisPlanes also does a lot of host port read access, and
> seems much quicker on HW).

Laurent?


> - FPU timing doesn't seem emulated at all (but I could be wrong about
> that) so Hatari is quicker.

That's also (very) visible in Atari benchmarks.  Laurent?


> (also: not all FPU opcodes appeared to disassemble in the debugger? Some
> do, other's don't! Maybe this is an 060 vs 882 set difference thing? I
> didn't make a note of the ops but the disasm was a mixture of real
> instructions and garbage encoded as $fxxx)



	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/