| Re: [hatari-devel] New WinUAE CPU core MMU support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On sunnuntai 28 joulukuu 2014, Eero Tamminen wrote:
> On sunnuntai 28 joulukuu 2014, Douglas Little wrote:
> > The default builds of BadMood can't properly use 32bit addressing
> > because it sets up the PMMU tree to map 0x0e000000 as a clone of the
> > first 16mb of STRam.
> >
> > The PMMU should intercept those writes and map them back to <14MB
> > before they reach the external bus, but if the PMMU is disabled or not
> > correctly emulated you may get some weird problems in Hatari.
>
> While BM works now fine with Hatari MMU emulation, MMU CPU core version
> unfortunately doesn't seem to support Falcon with TT-RAM yet. With MMU
> and 32-bit addressing, TOS v4 recognizes only 512k of RAM.
And TOS4 naturally doesn't boot with 040 or 060 if MMU is enabled.
I guess MMUs are too different so that TOS 4 MMU setup for 030
could work (even without enabling TT-RAM).
However, in case of 060, there's also a Hatari bug.
Hatari becomes frozen with 060 Falcon + MMU, it doesn't
react to anything else than SIGKILL.
Attached are profiles of what Hatari functions are running
with TOS v4 and EmuTOS after Hatari becomes non-interactive.
Btw. I didn't know that EmuTOS is lacking 060 MMU support...
With 040 Falcon + MMU, EmuTOS boots up fine. TOS v4 doesn't
boot up, but Hatari remains interactive, emulation just loops
on this:
--------------------------------------------
....
run_mmu040
CPU reset PC=e00038 (ROM memory)..
M68000 Bus Error writing at address $fffffc.
M68000 Bus Error writing at address $fffff8.
....
M68000 Bus Error writing at address $ffffb8.
M68000 Bus Error writing at address $fffffc.
68040 MMU: enabled=0 page8k=0 PC=00e00030
exit m68k_run
run_mmu040
....
--------------------------------------------
- Eero
> PS. TOS v3 on TT recognizes the memory even with MMU, but screen
> remains blank, so there MMU version has some work left too...
>
> > D
> >
> > On 28 December 2014 at 21:16, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
> > > Hi,
> > >
> > > I'm getting huge/unreasonable amounts of "Illegal *put" messages from
> > > new WinUAE CPU core with 32-bit addressing. They won't invoke any
> > > exceptions, so they cannot be trapped by debugger.
> > >
> > > Grepping sources shows them to come from dummy_*put() functions.
> > >
> > > I'm getting them with BadMood started in this way:
> > > $ hatari -s 14 --addr24 false --machine falcon ...
> > >
> > > (I assume BM never finishing loading / outputting sound is
> > > it just being incompatible with 32-bit addressing, not an
> > > issue with Hatari. It happens regardless of whether any
> > > TT-RAM is specified.)
> > >
> > >
> > > After adding attached patch to Hatari (and using "--debug-except
> > > bus"), I'm seeing messagees coming from stuff like this:
> > > -------------
> > > Illegal lput at 0eb91df0=00000000 PC=15e12
> > >
> > > CPU=$15e12, VBL=982, FrameCycles=148822, HBL=290, LineCycles=342,
> > > DSP=$1046 $00015e12 : 4298 clr.l
> > > (a0)+
> > >
> > > > disasm $00015e00
> > >
> > > $00015e00 : caf0 2400 mulu.w
> > > (a0,d2.w*4),d5 $00015e04 : 0682 0000 2000 addi.l
> > > #$2000,d2 $00015e0a : 508f addq.l
> > > #8,sp $00015e0c : 22c0 move.l
> > > d0,(a1)+ $00015e0e : 2040 movea.l
> > > d0,a0 $00015e10 : 4241 clr.w d1
> > > $00015e12 : 4298 clr.l (a0)+
> > > $00015e14 : 5241 addq.w #1,d1
> > >
> > > > r
> > > >
> > > D0 0EB91DF0 D1 00000000 D2 0EB93DF0 D3 00000010
> > > D4 000FC6E8 D5 8F000000 D6 00000801 D7 FFFFFFFC
> > > A0 0EB91DF4 A1 000FCAF4 A2 0005ED28 A3 000000CF
> > > A4 0000A0BC A5 00000800 A6 0000000B A7 00200684
> > >
> > > USP 0023FD7E ISP 00200684 SFC 00000000 DFC 00000000
> > > CACR 00002101 VBR 00000000 CAAR 00000000 MSP 00000000
> > > T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=3 STP=0
> > > FP0: nan FP1: nan FP2: nan FP3: nan
> > > FP4: nan FP5: nan FP6: nan FP7: nan
> > > FPSR: 4000000 FPCR: 00000000 FPIAR: 00000000 N=0 Z=1 I=0 NAN=0
> > > Prefetch 5241 (ADD) 0000 (OR) Chip latch 00000000
> > > 00015E12 4298 CLR.L (A0)+
> > > Next PC: 00015e14
> > > -------------
> > >
> > > Why addresses like that (0xeb91df0 = 235MB) go to dummy banks
> > > instead of causing bus errors?
> > >
> > >
> > > Btw. When looking more into exception debugging support, I noticed
> > > that new WinUAE CPU core is also missing this stuff from old UAE CPU
> > > core: ----------------------
> > >
> > > /* Check for double bus errors: */
> > > if (regs.spcflags & SPCFLAG_BUSERROR) {
> > >
> > > fprintf(stderr, "Detected double bus error at address
> > > $%x,
> > >
> > > PC=$%lx => CPU halted!\n",
> > >
> > > BusErrorAddress, (long)currpc);
> > >
> > > unset_special(SPCFLAG_BUSERROR);
> > > if (ExceptionDebugMask & EXCEPT_BUS)
> > >
> > > DebugUI(REASON_CPU_EXCEPTION);
> > >
> > > else
> > >
> > > DlgAlert_Notice("Detected double bus error => CPU
> > > halted!
> > >
> > > \nEmulation needs to be reset.\n");
> > >
> > > regs.intmask = 7;
> > > m68k_setstopped(true);
> > > return;
> > >
> > > }
> > > if ((ExceptionDebugMask & EXCEPT_BUS) &&
> > >
> > > BusErrorAddress!=0xff8a00) {
> > >
> > > fprintf(stderr,"Bus Error at address $%x, PC=$%lx\n",
> > >
> > > BusErrorAddress, (long)currpc);
> > >
> > > DebugUI(REASON_CPU_EXCEPTION);
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > /* Set PC and flags */
> > > if ((ExceptionDebugMask & EXCEPT_NOHANDLER) && (regs.vbr + 4*nr)
> > > == 0)
> > >
> > > {
> > >
> > > fprintf(stderr,"Uninitialized exception handler #%i!\n", nr);
> > > DebugUI(REASON_CPU_EXCEPTION);
> > >
> > > }
> > > newpc = get_long (regs.vbr + 4*nr);
> > > if ( newpc & 1) /* check new pc is
> > > even */
> > >
> > > {
> > >
> > > if ( nr==2 || nr==3 ) /* address error
> > > during
> > >
> > > bus/address error -> stop emulation */
> > >
> > > {
> > >
> > > fprintf(stderr,"Address Error during exception 2/3,
> > > aborting
> > >
> > > new PC=$%x\n",newpc);
> > >
> > > if (ExceptionDebugMask & (EXCEPT_BUS|EXCEPT_ADDRESS))
> > >
> > > DebugUI(REASON_CPU_EXCEPTION);
> > >
> > > else
> > >
> > > DlgAlert_Notice("Address Error during exception 2/3
> > > => CPU
> > >
> > > halted!\nEmulation needs to be reset.\n");
> > >
> > > }
> > >
> > > else
> > >
> > > {
> > >
> > > fprintf(stderr,"Address Error during exception, new
> > >
> > > PC=$%x\n",newpc);
> > >
> > > Exception ( 3 , m68k_getpc() , M68000_EXC_SRC_CPU );
> > >
> > > }
> > >
> > > return;
> > >
> > > }
> > >
> > > ----------------------
> > >
> > >
> > > Old UAE core:
> > >
> > > * prevents Hatari from taking all CPU looping unrecoverable
> > >
> > > exceptions and instead notifies user about it (either by dialog,
> > > or by invoking debugger if exception debugging is enabled).
> > >
> > > * supports "no exception handler" debugger case
> > >
> > > - Eero
19.65% 3476 hatari hatari [.] fill_icache040
12.31% 2176 hatari hatari [.] m68k_run_mmu060
8.11% 1435 hatari hatari [.] do_specialties.isra.34
8.08% 1426 hatari hatari [.] ROMmem_lget
6.41% 1134 hatari hatari [.] get_iword_mmu060
5.70% 1008 hatari hatari [.] get_word_icache040
3.62% 630 hatari hatari [.] do_cycles_slow
3.16% 555 hatari hatari [.] op_48c0_33_ff
2.63% 466 hatari hatari [.] op_0800_33_ff
2.57% 454 hatari hatari [.] op_56c0_33_ff
2.53% 448 hatari hatari [.] op_4880_33_ff
2.38% 420 hatari hatari [.] op_307c_33_ff
2.19% 387 hatari hatari [.] op_4e90_33_ff
2.17% 380 hatari hatari [.] op_1010_33_ff
2.05% 355 hatari hatari [.] op_4e75_33_ff
2.02% 358 hatari hatari [.] op_6701_33_ff
1.77% 313 hatari hatari [.] op_4a80_33_ff
1.58% 280 hatari hatari [.] __umoddi3
1.57% 272 hatari hatari [.] m68k_do_rts_mmu060
1.24% 219 hatari hatari [.] mmu_get_iword.constprop.8
0.91% 161 hatari hatari [.] ACIA_IKBD_Read_SR
0.90% 157 hatari hatari [.] put_long_cache_040
0.75% 133 hatari hatari [.] get_byte_cache_040
0.75% 132 hatari hatari [.] get_long_cache_040
0.65% 114 hatari hatari [.] M68000_WaitEClock
0.57% 100 hatari hatari [.] mmu_put_long.constprop.6
0.51% 90 hatari hatari [.] IoMem_bget
0.49% 87 hatari hatari [.] mmu_get_byte.constprop.7
0.49% 86 hatari hatari [.] M68000_WaitState
0.46% 82 hatari hatari [.] ACIA_AddWaitCycles
0.31% 55 hatari hatari [.] ROMmem_xlate
0.19% 33 hatari hatari [.] SysMem_lget
0.15% 26 hatari hatari [.] SysMem_lput
0.07% 12 hatari hatari [.] uae_mmu060_put_long
0.04% 7 hatari hatari [.] ACIA_Get_Line_CTS_Dummy
19.24% 56757 hatari hatari [.] fill_icache040
13.40% 39530 hatari hatari [.] op_0838_33_ff
13.21% 38966 hatari hatari [.] m68k_run_mmu060
10.30% 30375 hatari hatari [.] get_word_icache040
9.95% 29356 hatari hatari [.] op_6701_33_ff
8.55% 25229 hatari hatari [.] do_specialties.isra.34
7.06% 20827 hatari hatari [.] get_iword_mmu060
5.15% 15205 hatari hatari [.] mmu_get_iword.constprop.8
3.07% 9068 hatari hatari [.] get_byte_cache_040
2.62% 7741 hatari hatari [.] IoMem_bget
1.89% 5556 hatari hatari [.] do_cycles_slow
1.88% 5540 hatari hatari [.] mmu_get_byte.constprop.7
1.10% 3257 hatari hatari [.] MFP_PendingA_ReadByte
1.07% 3163 hatari hatari [.] M68000_WaitState