ST536 STE EDITION

[exxos]

Just a quick update on the new STE I'm testing on.

Works identically to my first STE using firmware current13. Under EmuTOS everything runs perfectly. Under modified TOS 2.06 most working just great. DOTT crashes in TOS 2.06, but not EmuTOS.

I was kind of hoping for a different result, but on the positive side...the results are repeatable.

Yeah I've posted about DOTT it doesn't like my modified TOS206... No idea why.

[exxos]

I started fiddling with my patched 206. It seems something in the PAK patches is causing the problem. If I force a 68030 build, DOTT works in Hatari. With the PAK patches enabled, it does the "normal" thing of just resets when loading DOTT.

Though with a 030 CPU, the TOS *should* patch the cache stuff itself.. but its hard to tell much at this point.. TOS is a lot of code to follow though..

My only thought currently is to just find where all the cache stuff is and force enable without using the PAK switches to do it. As it must be breaking something else somewhere.. Mostly TOS206 is fine other than the cache issue.. So that's my thought for a new TOS build..

EDIT

Actually some good fortune

Capture.PNG (29.56 KiB) Viewed 57 times

030 CPU enables the caches anyway! So I suppose I could release this build "as is" as it should work as a patched TOS206 anyway now..

I will keep looking through the code to make sure nothing obvious got missed but hopefully it will that simple....

2.PNG (191.99 KiB) Viewed 55 times

I guess my thought process was, PAK is a 030, enabling PAK stuff makes sense.

Or maybe I should have simply thought more dumb, that is not a PAK, so don't enable it

Anyway, I suppose I need to build a new ROM image now, perfect excuse to grab the latest EMUTOS as well.

Then I can see what broke after fixing it...

[dml]

Does the PAK have more than one kind of cache? e.g. a L2 cache on the board? Flushing something like that would probably crash a non-PAK system.

[exxos]

Does the PAK have more than one kind of cache? e.g. a L2 cache on the board? Flushing something like that would probably crash a non-PAK system.

Good thought, I don't believe it has a L2.. For all intents and purposes I don't think it's any different than the STE536 really.. At the end of the day is just a 030 CPU.

They must be something rather subtle because the problem only seems to happen with DOTT... It's not TTram related as DOTT crashes without TTram anyway.

I did wonder if there is something relating to 32-bit address fixes or something else DOTT seems to "wonder off" into trying to access the cartridge port by what I can tell. But then surely TTram wouldn't work at all, or have been other signs by now..

[exxos]

My first find were not sure what's going on...

1.PNG (6.01 KiB) Viewed 43 times

TP_50 = 1 for PAK stuff enabled.


Also

Code: Select all

#if TP_50
/*
 * SE: (26.10.93)
 * Das gleiche Prozessorunabh„ngig:
 * MMU-Deinitialisierung vor Kaltstart.
 */
        lea       coldboo0(pc),a0
        move.l    a0,ABSW(_illinst)
        move.l    a0,ABSW(_lineftrap)
        lea       zero2,a0
        TO_TC_A0
        TO_TTR0_A0
        TO_TTR1_A0
coldboo0:
#else
        TO_TC(zero2)   /* disable PMMU and address translation */
        TO_TTR0(zero2)
        TO_TTR1(zero2)
#endif
/* copy erase routine to low memory */
        move.w    #(coldbend-coldboor+3)/4-1,d0
        lea.l     coldboor(pc),a0
        movea.w   #$00c,a1
coldboo1:
        move.l    (a0)+,(a1)+
        dbf       d0,coldboo1
        jmp       ABSW($0000000C)
/* clear ST memory until buserror */
coldboor:
        lea.l     coldboo4(pc),a0
        move.l    a0,ABSW(_buserror)
        lea.l     coldboo6(pc),a0
        moveq.l   #0,d0
coldboo3:
        move.l    d0,(a0)+
        move.l    d0,(a0)+
        move.l    d0,(a0)+
        move.l    d0,(a0)+
        bra.s     coldboo3
/* clear FASTRAM until buserror */
coldboo4:
        move.l    ABSW($00000004),ABSW(_buserror)
        lea.l     FASTRAMBASE,a0
coldboo5:
        move.l    d0,(a0)+
        move.l    d0,(a0)+
        move.l    d0,(a0)+
        move.l    d0,(a0)+
        bra.s     coldboo5
coldboo6:
        nop
coldbend:  ds.b 0

        data
zero2:  dc.l 0
		text
#endif /* TOSVERSION > 0x200 */
#endif /* TOSVERSION > 0x300 */
#endif /* STBOOK */

"/* disable PMMU and address translation */" I presume would get run as TP_50 is now 0 .

[dml]

In case it helps, you can clear the 030 caches yourself.

Code: Select all

movec	cacr,d0		; read cache control reg.
or.w	#$808,d0	; set CD (clear data) + CI (clear instruction) cache bits
movec	d0,cacr		; write cache control reg.

cacr control register reference can be found here: page 6-21
https://www.nxp.com/docs/en/reference-m ... 8030UM.pdf

[exxos]

In case it helps, you can clear the 030 caches yourself.

Code: Select all

movec	cacr,d0		; read cache control reg.
or.w	#$808,d0	; set CD (clear data) + CI (clear instruction) cache bits
movec	d0,cacr		; write cache control reg.

cacr control register reference can be found here: page 6-21
https://www.nxp.com/docs/en/reference-m ... 8030UM.pdf

Thanks, yeah there is a flushcaches routine somewhere in TOS..

Code: Select all

flushCaches:
        move.w    sr,-(a7)
        ori.w     #$0700,sr
        CACR_D0
        or.l      #$00000808,d0           /* CI (Clear Instruction Cache), DI (Clear Data Cache) */
        D0_CACR
        move.w    (a7)+,sr
        rts

[exxos]

More PMMU related stuff..

3.PNG (23.76 KiB) Viewed 39 times

4.PNG (52.89 KiB) Viewed 38 times

[dml]

That TP_50 stuff is doing something with fastram detect/init/clearing/setup on a reset, or something like that. With or without TP_50 its still disabling MMU page table translation just declaring it in a different way.

[crossing posts!]

The later pasted code shows it's skipping MMU setup on a reset so it probably installed its own MMU pagetables - for FastRAM or for ROM shadowing in FastRAM and doesn't want it zapped on a reset.

[exxos]

The later pasted code shows it's skipping MMU setup on a reset so it probably installed its own MMU pagetables - for FastRAM or for ROM shadowing in FastRAM and doesn't want it zapped on a reset.

Yeah could well be. I guess thats another thing if to clear the stuff on reset or not.

I'm still looking, but most of the PAK stuff so far is MMU related it seems. There must be something PAK does which I don't know about which the patches don't like on the 536


Also this

5.PNG (22.48 KiB) Viewed 33 times

A few other bits here and there in TOS but nothing "important". So the biggest changes look to be MMU type stuff.