Re: [hatari-devel] New WinUAE core issue with Bad Mood?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 06/12/2014 18:27, Nicolas Pomarède a écrit :
> Le 06/12/2014 13:39, Nicolas Pomarède a écrit :
>
> > For now, I think it's more a bug in new cpu core, I tested with an older
> > version and the instructions are correct.
>
> bug confirmed : it works with 68030 with or without MMU and with lower
> accuracy mode.
> If cycle exact or prefetch/compatible mode is used, there's an error in
> the opcodes after aone of the exception. I will look at this.
>
> BTW, it seems emutos doesn't print anything on the summary screen if the
> MMU as detected or not. Maybe you could add this info next to the
> detected cpu type ?

Hi

I reported some traces to Tony Wilen, who confirmed me this was a bug in 
Winuae after an exception in MMU code happens. So it should be fixed soon.

Apart from that, Tony gave me some infos about the 68ec030, so I further 
looked for 68EC030_Users_Manual_1990.pdf which you can find here :

https://archive.org/stream/bitsavers_motorola68al1990_16337845/68EC030_Users_Manual_1990_djvu.txt

Basically, MMU registers TT0 an TT1 were renamed to AC0 and AC1, so 
expecting a line-f exception in emutos at address e00090 is not enough 
to detect a 68ec030 :

$e00090 : f039 0800 00e0 013e                  pmove     $e0013e,tt0
$e00098 : f039 0c00 00e0 013e                  pmove     $e0013e,tt1

On a 68ec030, you won't get an error because those registers really exist.

This is from Tony :

"Yes, Motorola 68030 documentation lists officially existing EC030 MMU 
registers but as I said previously, Motorola documentation only says 
68030-only MMU registers should not be accessed, behavior is undefined.

For example Amiga enforcer debugging tool has this note in its source:

* Note that there is a processor called 68EC030.  This processor
* has a disabled or defective MMU.  However, it may function well
* enough for Enforcer to think it has a fully functional MMU and
* thus Enforcer will attempt to run.  However, even if it looks like
* the MMU is functioning, it is not fully operational and thus may
* cause strange system activity and even crashes.  Do not assume
* that Enforcer is safe to use on 68EC030 systems. "



In section 9.7 of the 68ec030 doc :

The MC68030 assembler can be used for the MC68EC030 as long as the
following procedures are observed:

1. To access ACO in the MC68EC030, use TTO in the MC68030 assembler.

2. To access AC1 in the MC68EC030, use TT1 in the MC68030 assembler.

3. To access ACUSR in the MC68EC030, use MMUSR in the MC68030
assembler.

4. PTEST uses the assembler syntax of PTESTR <function 
code>,<ea>,
#0 and PTESTW <function code>,<ea>, #0.

5. All other accesses to MMU functions are invalid, can produce undefined
results, and should not be used.



So, it seems rather difficult to really determine if the cpu is a 68030 
or a 68ec030.
If pmove to AC0/AC1 (or TT0/TT1) works, it doesn't mean that a later 
translation table will work :(

But at least it can tell if the cpu is a 68020 or a 68030.

It's not really a problem for Atari, as I don't think 68ec030 were ever 
used. So if pmove to tt0/ac0 works, then it's likely to be a full 68030 
and not a 68020.


Nicolas