Re: [hatari-devel] Next release

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


>> I have work in progress branch with all the recent winuae cpu's
>> changes that I'm testing. Hopefully it should be good to merge soon
>> and it really improve low level cpu emulation for address/bus errors +
>> opcodes that were tested by Toni with his cputester on real HW.
> 
> If that includes also 030 exception handling
> improvements, I'm interested in testing whether
> they fix Hatari Linux & BSD compatibility.
> 
> If yes, I'd like to document (before release) how
> to get also BSD running in Hatari.  Currently BSD
> seems to have even more problems in Hatari than
> Linux...

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




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