Re: [hatari-devel] Re: Hatari debugging help with WinUAE CPU core |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
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 ENABLE_WINUAE_CPU
if (currprefs.mmu_model) {
THROW(2);
return;
}
#endif
/* The exception will be done in newcpu.c */
M68000_SetSpecial(SPCFLAG_BUSERROR);
}
--------------------
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