|Re: [hatari-devel] Adding Aranym features for Hatari?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On lauantai 20 lokakuu 2012, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > On tiistai 16 lokakuu 2012, Eero Tamminen wrote:
> > I did today an initial code for basic NatFeats support:
> > http://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/50958d336a1a
> Your change breaks compiling the WinUAE cpu core :-( Could you please
> fix that?
I'm not sure about this stuff on exit from the opcode handlers:
regs.ir = regs.irc;
Only WinUAE core has that.
I added it also to natfeat opcode handlers, but is it e.g. needed
only in case one is doing a trap handler like GEMDOS or VDI?
> > I've modeled it on how it works in Aranym. I'm not sure whether
> > the status register stuff is needed, but as it was used in Aranym,
> > I added it here also.
Any comments on that?
Aranym code actually stores and restores all normal registers too,
but I guess that was for some potential extra stuff that its
natfeat features could do...
> > It doesn't yet raise bus error / priviledge exception in case
> > the arguments or supervisor mode isn't correct. How I can invoke
> > those in Hatari?
> For Bus Error, you can use M68000_BusError(), for priviledge exception
> you could try something like Exception(8,0,M68000_EXC_SRC_CPU).
> Anyway, you've got to make sure to skip the m68k_incpc() and other
> remaining code when you did that, so that the CPU can correctly
> continue with the exception handler.
Thanks. What about the status register stuff, should re-setting
that be skipped too?
What about this VDI check():
if (VDI_OldPC && pc >= 0xfa0000 && pc < 0xfc0000)
/* Set PC back to where originated from to continue
instruction decoding */
VDI_OldPC = 0;
/* illegal instruction */
regs.ir = regs.irc;
I think this check was needed when GEMDOS emu enables cartridge stuff,
which causes also VDI opcode to be set up, but some demo/game
was using that illegal opcode for its protection.
Should the extra stuff be skipped also after op_illg()?