Re: [hatari-devel] Re: Hatari debugging help with WinUAE CPU core

[ Thread Index | Date Index | More Archives ]


On sunnuntai 19 tammikuu 2014, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > It seems that Hatari skips these messages if its TOS itself causing
> > the bus error.
> > 
> > I'm not sure that's right.  TOS does some HW checks at startup which
> > cause bus errors, but apps calling TOS later on may cause TOS to bus
> > error later on by giving invalid inputs to OS calls, so knowing about
> > them would also be useful.
> Well, the problem is, how do you want to distinguish this? The emulator
> can hardly know what TOS is doing unless you want to create a huge
> table that lists all hardware test addresses for all TOS versions.

TOS does those at boot.  "Only" thing Hatari would need to do is disabling
exeption debugging on boot/reset, and enabled it (if it was enabled)
when booting has finished.  Detecting latter is the tricky part.  Maybe
it could be done by checking e.g. for GEMDOS initialization?

> > That code is pretty hard to follow, so I'm not sure whether you should
> > get normal bus error, or just some MMU specific exception.
> > 
> > With MMU, SSW register may be involved and emulation of that in Hatari
> > isn't currently complete.
> Is MMU really involved here or is this just about "normal" WinUAE mode?

BadMood does some stuff with MMU and Hatari code does things differently
when MMU is enabled:
       /* [NP] Check that the opcode has not already generated a read bus 
error */
       if ((regs.spcflags & SPCFLAG_BUSERROR) == 0) {
                BusErrorAddress = addr;      /* Store for exception frame */
                bBusErrorReadWrite = bRead;
                if (currprefs.mmu_model) {
                /* The exception will be done in newcpu.c */

MMU still defaults to false for Falcon with Hatari though.

> > Btw. Exeption debugging option in oldUAE CPU core invokes debugger
> > only for address, bus and uninitialized exception handler errors.  I
> > don't know why it's not enable for other exceptions.
> If you enable the debugger for _all_ exceptions, you simply do get too
> many of them. Interrupts occur quite often, and it's quite cumbersome
> when you try to step through a program and always get interrupted by
> such an event.

It of course needs to be configurable, like it's in other debuggers.

	- Eero

Mail converted by MHonArc 2.6.19+