| 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, 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.
- 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