|Re: [hatari-devel] 68030 MMU emulation: TEMPLMON, ROMSPEED|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Thanks for the hint. That makes sense!
Unfortunately i don't understand our TRY/CATCH/THROW implementation.
I definitely need help with this.
Am 20.10.2012 um 19:02 schrieb Thomas Huth:
> Am Fri, 19 Oct 2012 17:36:24 +0200
> schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:
>> That does not look very good ... seems there might be something wrong
>> with the TRY/CATCH/THROW stuff.
>> I did not yet port this to Previous. You may try to undo it:
>> Go to cpummu030.c, line 1480:
>> In the function mmu030_put_long_atc there is a line:
>> THROW(2); //M68000_BusError(addr, 0);
>> Comment or remove THROW(2) and re-activate M68000_BusError(addr, 0);
>> There are 5 more functions to do the same (put word, put byte, get
>> long, get word, get byte).
> the more I think about this, the more I think that the MMU code _must_
> really throw the bus errors via THROW instead of M68000_BusError()
> (i.e. not using SPCFLAG_BUSERROR). Imagine the following opcode:
> move.l (a0,d0.w),d0
> Let's assume that a0+d0 points to a memory location of a non-mapped
> page, so the memory access should cause a bus error. When the MMU code
> uses SPCFLAG_BUSERROR to emulate the bus error, d0 gets destroyed
> before the bus error handler is called. Thus when the instruction is
> resumed, a0+d0 points to the wrong memory location!
> So it's crucial to use THROW instead of SPCFLAG_BUSERROR - and when
> THROW is not working yet, we've got to find the right fix first.