Re: [hatari-devel] Special WinUAE FPU settings

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


Am Wed, 13 Apr 2016 19:17:23 +0300
schrieb Toni Wilen <twilen@xxxxxxxxxx>:

> >> (What did this have to do with 68030 MMU PMOVE?)  
> > 
> > Eero originally noticed that Hatari printed something like this out
> > when 68060 CPU has been selected:
> > 
> >  68030 MMU enabled. Page size = 32768 PC=00e014f6
> > 
> > That's of course confusing. It was due to that int_no_unimplemented
> > option. If it is set to false, the PMOVE instruction of the 68030
> > MMU is also still allowed in 68060 mode, and TOS is using that
> > instruction during boot.  
> 
> It is a bug in "unimplemented opcode?" part in build_cpufunctbl(). It
> accidentally enabled all unimplemented opcodes in 68060 mode, not just
> 68060-only unimplemented opcodes.
> 
> Something like this should work:
> 
> /* unimplemented opcode? */
> if (table->unimpclev > 0 && lvl >= table->unimpclev) {
> 	if (currprefs.cpu_model == 68060) {
> 		// unimpclev == 5: not implemented in 68060.
> 		if (currprefs.int_no_unimplemented &&
> table->unimpclev == 5) { cpufunctbl[opcode] = op_unimpl_1;
> 			continue;
> 		}
> 		if (!currprefs.int_no_unimplemented ||
> table->unimpclev != 5) { cpufunctbl[opcode] = op_illg_1;
> 			continue;
> 		}
> 	} else {
> 		cpufunctbl[opcode] = op_illg_1;
> 		continue;
> 	}
> }

That seems to work - the 68030 PMOVE instruction from TOS now generate
an exception if int_no_unimplemented is set to false :-)

 Thanks,
  Thomas



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