| Re: [hatari-devel] STF/STE using WinUAE CPU in prefetch mode -> CE mode available |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel 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 ;)
Regards
Laurent
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)
Hi
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.
Nicolas