Re: [hatari-devel] STF/STE using WinUAE CPU in prefetch mode -> CE mode available

[ Thread Index | Date Index | More Archives ]

Hi Nicolas,

That's a great news.

I wasn't at home these last days, but I can start a campaign of tests now.

So, I've started a first test:

St(f) mode, 1 Mo, Tos french 1.04 cycle exact, real time clock emulation, no patch, no blitter, no boot faster ... 24 bits mode addressing.

I've launched dark side of the spoon.
In the very first overscan (with purple, green and pink bubbles scrolling) the last 16 bits seems broken sometimes (they become green) and the 3 lower lines of the screen are full of pixel glitches.

I'll continue my tests.

I use the N-1 latest source (without Thomas 's VDI mode patch)

PS: I'm impatient for the 030 Cycle exact modes ;)
And you can wount on me for the tests of this part ;)


Le 29/10/2015 00:38, Nicolas Pomarède a écrit :
Le 30/09/2015 12:54, Nicolas Pomarède a écrit :

Next step on the list is to use WinUAE cpu's "cycle exact" mode and
update Hatari to use it in order to get precise bus accesses for each
instructions, but this will take some time (for example, this would
allow to remove hard coded pairing instructions)


as announced, cycle exact mode is now available for 68000 STF/STE (using WinUAE's great CPU)

This mode will be the one that will give the highest accuracy regarding CPU emulation as well as memory access time.

The following features are enabled :

- full cycles emulation for all opcodes/exceptions, including internal cycles, memory access, idle cycle, ...

- correct emulation of the wait state for read/write memory access that need to be aligned on a 4 cycle boundary, including additional 2 cycle wait state when needed. No more rounding to the next multiple of 4 cycles.

- as a consequence of the internal cycle and memory access wait states, so called "instruction pairing" is now made without tables or heuristics, it just appears as a normal consequence of having to add wait state or not and if the CPU is "stalled" by a memory access.

- logic for several Atari's specifc interrupts and IACK sequences was cleaned to be more consistant with real HW

 - wait state when accessing some HW registers were also slightly changed

- some heuristics to get internal read/write cycles in prefetch mode were updated to better match the real CE behaviour, allowing to have more common code between prefetch mode and CE mode

All in all, that's a whole lot of changes, with possibilities to break a lot of things. Dozens of demos/programs known to have some special timings were used to be sure the changes are correct, but one can never be sure all cases were handled.

So, this is the time for everyone interested in Hatari emulation to check their favorite games/demos. Of course, demos with video tricks (overscan, plasma, ...) are the most likely to show problems, but even some very simple demos/games, or game's protection when using STX file can show bugs.

Compile Hatari with "--enable-winuae-cpu" and run it with "--cpu-exact 1" and run as many games/demos as you can.

First, it's very entertaining to revive your memory of those games/demos, and second it will help ensure no regression are present :)

In case some games/demos are broken and not reported in the doc/compatibility file, don't hesitate to report them too, even if not related to CE mode, they should be fixed or maybe added to compatibility list.

If you find some problems, try to run Hatari with "--cpu-exact 0" to see if problem is also there in non-CE mode.

Once there's enough positive feedback, old uae cpu core will be deprecated (but not removed) and won't be used as the default CPU anymore. This will allow us to ship only one binary for STF/STE and Falcon/TT.

Next step : do the same for 68020/30 CPU in CE mode, also taking memory access times into account to get much better accuracy.


Mail converted by MHonArc 2.6.19+