Am Sun, 3 Jul 2022 23:05:07 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
Le 03/07/2022 à 15:08, Thomas Huth a écrit :
Am Sun, 26 Jun 2022 12:35:02 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
On 26.6.2022 9.27, Thomas Huth wrote:
...
Yes, I can reproduce it with EmuTOS v1.1.1 - and only if CPU cycle exact
mode is enabled, too. Seem like 030 + MMU + CE is pretty much defunc in
Hatari right now. In m68k_run_mmu030() I can see:
if (!currprefs.cpu_cycle_exact) {
count_instr (regs.opcode);
do_cycles (cpu_cycles);
cpu_cycles = (*cpufunctbl[regs.opcode])(regs.opcode);
} else {
#ifdef WINUAE_FOR_HATARI
currcycle = 0;
#endif
(*cpufunctbl[regs.opcode])(regs.opcode);
wait_memory_cycles();
}
However, if cpu_cycle_exact is enabled, currcycle is often still 0 after
the emulated instruction has been run via cpufunctbl.
Looks like cpufunctbl is either pointing to the wrong table, or the table
has been somehow generated badly? ... no clue yet ... Nicolas, do you maybe
have an idea?
Hi
I need to look in more detail, but I guess it's possible that with cycle
exact some instructions are 0 cycles because of emulated behaviour where
tail/head cycles for some instruction are "overlapping"
running this with emutos 1.1.1 :
/hatari --tos tos.img --machine tt -s 14 --fast-boot on --mmu on
--log-level debug --cpu-exact on
I see that after a while it loops on these instructions :
cpu video_cyc=531003 651@261 423252551 : 00e0d612 2039 0000 04ba
move.l $000004ba [*00000a4a],d0
cpu video_cyc=531003 651@261 423252551 : 00e0d618 b081
cmp.l d1,d0
cpu video_cyc=531003 651@261 423252551 : 00e0d61a 6c0e
bge.b #$0e == $00e0d62a (F)
cpu video_cyc=531003 651@261 423252551 : 00e0d61c 1038 fa01
move.b $fa01,d0
mfp read gpip fffa01=0xb1 video_cyc=531003 651@261 pc=e0d61c instr_cycle 0
IO read.b $00fffa01 = $b1 pc=e0d61c
cpu video_cyc=531010 658@261 423252558 : 00e0d620 0800 0005
btst.l #$0005,d0
cpu video_cyc=531010 658@261 423252558 : 00e0d624 66ec
bne.b #$ec == $00e0d612 (T)
Is that what you see ?
In "normal" operation yes, it's only updating the cycle count after a
couple of instruction. It could be that this is related to the cache
emulation, fair.
But when the hang happens, it seems like the emulated code is looping
through the whole cleared memory, only executing op_0000_35_ff() in
cpuemu_35.c. And this never seems to add any cycles anymore, thus Hatari
completely hangs in the m68k_run_mmu030() loop, without ever generating an
interrupt and thus not reacting to user input anymore...