|Re: [hatari-devel] extra bits in PC register (was: "profile stack" command added)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On lauantai 01 kesäkuu 2013, Nicolas Pomarède wrote:
> On 01/06/2013 17:56, Eero Tamminen wrote:
> > Unrelated question. Why in cart_asm.s:
> > -------------------
> > ; This is the cartridge header:
> > dc.l $ABCDEF42 ; C-FLAG (magic value)
> > dc.l $00000000 ; C-NEXT
> > dc.l sys_init+$08000000 ; C-INIT - flag has bit 3 set =
> > before
> > disk boot, but after GEMDOS init
> > $08000000 is added to sys_init address? What's the flag bit 3?
> > When TOS goes through cartridge code and jumps to that address
> > (which does linea_init variable setup for Hatari), PC gets an "illegal"
> > address value. Emulation itself masks the extra bits off from the
> > address, but profiling code throws a fit about it when I profile
> > TOS startup...
I commited a workaround that masks the extra bits away when profiler
reads the PC value.
> I don't know why it does that in this precise case, but as pc is 32 bits
> and 68000 addresses 24 bits only in st, you can indeed "store" data in
> the upper 8 bits.
> If you look at the exception vectors in lower ram set by TOS, you will
> see that exception 2 has "02" in upper byte, exception 3 has "03", ..
> So if your program crashes, as pc will be pushed in the stack at one
> point, it can help to debug to see what caused the jump to the current
> state of the 68000 (for example, after a bus error, pc will be 02xxxxxx
> ; so you know you're in the context of a bus error (this is valid only
> when the tos set such handlers))
What happens on 030 and machines which have fast RAM i.e. more than
16MB of RAM?