Re: [hatari-devel] 68030 MMU emulation: TEMPLMON, ROMSPEED

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

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).
> 
> Andreas,
> 
> 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.
> 
> Thomas
> 
>