Hi,
file downloaded. From what I see, pflusha is working, then romspeed
create a cookie in RAM, call gemdos's super to go back to user mode. And
it crashes here, from the trace it looks like A7 is 0 after going back
to user mode, which is wrong ; it should have its value from earlier.
Can you try to run the test from the floppy, but add "-d ''" to the
parameters to completely disable loading the fake cartridge code that
emulate gemdos HD ? It doesn't mtter in my case, but maybe it changes
sthg for you.
Your note with A7 caused me to recompile ROMSPEED without the PMMU
instructions, in order to see whether it would still crash. It did not.
Then I noticed something which is embararrassing, in particular because you
spent so much time on the error analysis: There were two copies of
ROMSPEED on my drive, and the one I was using must have been different
from the one I attached to one of my emails and which you were most likely
using. I'm really sorry for that ...
The other copy does not crash, and also a copy built fresh from the
source does not. This means the problem is gone, nothing was actually wrong.
Next thing I did is double-checking whether I made a similar mistake
with MEMWATCH, but I did not. There is only one copy. I tried the floppy
disk image approach with it, but the first program I start from floppy
after MEMWATCH results in Hatari hanging. I now tried the same logfile
approach as the one you suggested before, and I may have found
something, please see below. On my machine Hatari hangs because it is
constantly executing the same code (at the very bottom of this email).
Looks as if there was a bus error due to an illegal write acces and the bus
error handling is repeated over and over.
This code:
cpu exception 2 currpc 100ba58 buspc 100ba58 newpc 1ec8c fault_e3 0 op_e3 0 addr_e3 0 SR 300
cpu video_cyc=322888 1832@158 : 0001EC8C 2f2f 0004 MOVE.L (A7, $0004) == $00005700 [ba58b008],-(A7) [01ffffc6]
mfp start CD handler=7 data=2 ctrl=1 timer_cyc=8 pending_cyc=7104 video_cyc=322892 1836@158 pc=1ec90 instr_cyc=4 first=false resume=true
cpu video_cyc=322892 1836@158 : 0001EC90 0297 0000 0fff AND.L #$00000fff,(A7) [ba58b008]
cpu video_cyc=322896 1840@158 : 0001EC96 2eb7 0151 MOVE.L (A7, D0.W*1+0)+0 == $00000008 [0001ec9c],(A7) [00000008]
cpu video_cyc=322900 1844@158 : 0001EC9A 4e75 RTS
results in an immediate new bus error. I guess this has to do with the
fact that the MEMWATCH moved the exception vector table to a new
location, i.e. it changes the VBR register. I assume that are not many
programs changing the VBR, maybe something is wrong with the emulation?
Of course I wonder why you cannot reproduce this.
The reason why MEMWATCH changes the vector address is in order to always
be the first program that sees a bus error. Any other program will
typically just modify the bus error vector by writing to $04, but $04 is
not the actual vector address anymore when MEMWATCH is active. MEMWATCH
calls the original vector by evaluating the 68030 vector offset on the
stack. This is also something rather unusual but makes it possible to
use the same code fragment in order to call all original exception
vectors, i.e. no vector-specific handling is required here.