[hatari-devel] Big update to cpu emulation pushed to main repo

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


Hi

since Toni (WinUAE) started this summer his huge task of an automatic cpu tester that would check all opcodes + undocumented bits + stack content after bus/address error + including all cpu + lot of other things, I maintained a new branch with all those ongoing changes.

See below for desciption by Toni :


68030 MMU + Amiga unix variants have worked fine (I tried few different
Linux variants and also NetBSD and OpenBSD) in UAE for years already.

Only 68030 MMU related changes are:

- 68030 MMU emulation simplified and optimized.
- 68030 MMU seems to do -(an)/(an)+ adjustment before bus error is
detected and original register content is not restored when bus error
exception starts. This is now emulated. No programs should care.

(simplified and optimized: state variable handling needed to support bus
error continuation is now much simpler)

Here is other, mainly 68000/68010 related updates. 68000 should be
practically 100% accurate, including lots of weird undocumented
side-effects. 68010 is almost 100% accurate (still some updates to do).
Most of these are validated using my tester which now can also test
cycle counts (currently Amiga only).

- 68000 address error and bus error emulation updates, all
side-effects/undocumented behaviors are now emulated. Prefetch generated
bus errors are now 100% functionally accurate (Including possibly
partially modified flags, partially modified registers etc..) and cycle
accurate. Special case example: TRAPV, if prefetch causes bus error and
V is set: bus error stacked SR field always has S-bit set and T is
always cleared. If V was not set: stacked SR field contents are as
expected. Another more common result: if long word is being read or
written to and access causes bus or address error: CCR Z and N flags are
set using only low 16-bit of long word. CPU tester prefetch bus error
testing mode added.
- 68010 loop mode emulation (prefetch and ce only) NOTE: when stepping
loop mode in UAE debugger, looped instruction appears to be skipped
because in loop mode it is merged with DBcc execution.
- 68010 loop mode is cycle-accurate. Cycle totals are correct but idle
cycle ordering may not be fully correct. (TODO: do some logic analyzer
checks)
- 68010 accurate address errors and exception stack frame emulation
(only documented part of stack frame, it has lots of undefined fields,
like 68020/030 bus/address error to allow instruction continuation after
the fault/fault retry with RTE. This is not emulated). Prefetch/ce only.
- 68010 read bus errors accurately emulated. (Except RTE support like above)
- 68010 cycle count adjustments. Most 68010 cycle counts are correct
now. (TODO: recheck later)
- MOVES was 68020+ instruction. It was introduced in 68010.
- BKPT was 68020+ instruction. It was introduced in 68010. It is illegal
instruction (at least without debugging hardware), only difference is
that it executes break point access cycle which delays illegal
instruction by 4 cycles compared to normal illegal instruction.
- gencpu now automatically and properly indents generated cpuemu_xxx.cpp
files.
- 68000-010 CPU internal IPL change detection timing is now more
accurate (but not 100% correct) and more optimal.
- 68000-010 CPU internal IPL change detection timing is now also
emulated in prefetch mode without cycle-exact. (IK+, Warhead, etc sound
now works without cycle-exact)
- 68010 RTE format error exception does not clear trace flag. 68020+ RTE
format error exception clears it.
- 68000/010 odd exception vector generated address error stack frame is
now correct. Tester support added. Odd bus error or address error vector
will halt the CPU.
- 68000 exception (including interrupts) cycle usage also validated
- 68000 BTST Dn,#x was 2 cycles too fast.
- 68000 DIVU/DIVS divide by zero exception processing starts after 4 cycles.
- 68000 JMP and JSR address error check was before EA calculation, 2-6
cycles too early.
- 68000 ADDX.L -(an),-(an) and SUBX.L -(an),-(an) had wrong cycle order:
it is reada+2,reada+0,readb+2,readb+0,writec+2,prefetch,writec+0 (was
prefetch,writec+2,writec+0)
- Lots of approximate (with or without prefetch) 68000 mode instruction
total cycle count fixes. Cycle counts are now 100% correct.
- 68010 is now cycle accurate.
- 68010 MOVES.W an,-(an)/(an)+ and both source and destination an is
same register: modified register content is stored if size is word.
MOVES.L stores original register content.
- 68000 MOVE causing write address error: address error was checked too
early, after read, even if it was followed by prefetch before write.

Older CPU core updates are here ("Fixed CPU tester detected differences ..")

http://eab.abime.net/showthread.php?t=98746

For Hatari, one major change is the new bus error handling. Previously, this was not directly handled in WinUAE's cpu core because the Amiga doesn't have bus error connected to the cpu.

After Toni acquired some specific HW for his Amiga, he was able to succesfully emulate bus error too, including all the places where it can happen (during prefecth, while fetching new PC, after each possible read/write of an instruction, including partial read/write of long values where only 1 word would cause bus error, not the other).

This is really an incredible work, so thanks to Toni ;-)

I replaced Hatari's bus error handling by this new / more generic bus error code. Hatari's one was much simpler and didn't cover all the possible case, it was just enough for programs to work (but it would be possible to write specific 68000 code to fool Hatari and get wrong results).

This new code is slightly slower, but after doing some benchmarking of the emulation code, the overhead is just 6-7% for the cpu part, which should not be that noticeable when you add video/sound emulation on top of that.

I ran some tests in ST/TT/Falcon mode and everything seem OK so far, but more tests are needed, especially with TT/Falcon mode using MMU for example

For Eero, this should improve compatibilty with linux/bsd (IIRC there was a thread about this and some stack content that might not be correct ? Can't find this thread at the moment)

Nicolas












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