Re: [hatari-devel] New version of WinUAE's cpu core

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 23 Nov 2014 17:07:50 -0500
schrieb "Roger Burrows" <rfburrows@xxxxxxxxx>:

> On 23 Nov 2014 at 22:20, Nicolas Pomarède wrote:
> > 
> > About the movep opcode, it was removed in 68060, we can see this in 
> > table68k when the 2nd number in the 2nd column is a '5', which
> > means "not implemented in 68060 or later". So, the following
> > instructions are likely to crash if they were used in TOS :
> > 
> > CAS2.W and CAS2.L
> > MVPMR and MVPRM
> > PTESTW and PTESTR
> > 
> > Apart from movep, I don't think these instructions are much used by
> > TOS, so it should be possible add a printf in the cpu core and see
> > all the values of PC when one of these is used.

FYI, as a quick hack, I've patched the movep instructions that occur
during the boot process to nops:

static const TOS_PATCH TosPatches[] =
{
  ...
  { 0x404, -1, "060fix", TP_ALWAYS, 0xE025E2, 0x01C80000, 12, pNopOpcodes },
  { 0x404, -1, "060fix", TP_ALWAYS, 0xE0263C, 0x01C80026, 4, pNopOpcodes },
  ...
};

Then the desktop is successfully reached again also in 68060 mode. So
it's not that much that has to be fixed in TOS.

> > As for Emutos, I don't know if it was tested against 68060 ? At
> > least, sources are available.
> > 
> I don't know if anyone has tested EmuTOS with a 68060, but the
> startup code is supposed to correctly detect a 68060, and the
> assembler code contains no movep's.  Since the version of EmuTOS that
> would run on a 68060 is actually compiled for a 68000, it is
> theoretically possible that the compiler might generate a movep, but
> I think that is highly unlikely.
> 
> If someone does test it, please let me know!

I gave it a quick try and it seems to work, the 68060 is detected
according to the splash screen, and the desktop is reached fine.
However, there is quite a long delay before the splash screen, ca. 10
seconds, while the splash screen is reached immediately when I select
another CPU level.

 Thomas