REV 3 - REV 5 - The beginning (ST536)

[exxos]

Oh really? I hadn't noticed that before. Perhaps the Hatari boys reckon 2.06 isn't 32 bit safe? It does annoy me when it switches machine based on the OS when I might *want* to be doing what I'm doing.

Yep pretty annoying. Even more annoying is that my new TOS ROM Boots in Hatari but not on the TF536 :roll: Another ROM in the bin :roll:

[exxos]

The TOS206 sources are bonkers. If I enable the binary exact option, it compiles and seems fine. If I turn on the pak patches, depending on the binary exact option, I end up with half a desktop or it freezing on a white screen with busy bee. I can only seem to get the TTram stuff up by enabling the pak patches. If I try to do anything manually it just go nuts or doesn't compile.

I've gone though all the pak and TOS lines which are used to switch stuff in or out. But nothing seems to help. I don't really see anything which can mess up the video stuff. The pak patches don't really seem to even do all that much. There isn't many files with patches in either. I tried forcing pak patches on/off in various files but it doesn't seem to try to boot up then :roll:

Its odd I get half a desktop and its like the AES screws up somehow as it can't seem to clear background graphics. I thought it was loading some stuff into alt-ram before causing the problem but disabling that didn't help anyway. I can't see there is anything else left to try,

I will have another go see if I can get TOS306 running tomorrow. But I think it expects to be a TT, so not sure how it will behave on basically a ST anyway. I guess I could try and compile a newer AES version into 206 and see if that changes anything.

@Darklord have you seen these odd "half a desktop" issues on your pak before ? https://www.exxosforum.co.uk/forum/viewt ... 580#p83849

[stephen_usher]

PAK3 (TOS 3.06) did boot on my ST+TF536, at least with an older version of @agranlund’s firmware. Just don’t try the higher resolutions. :-)

[exxos]

PAK3 (TOS 3.06) did boot on my ST+TF536, at least with an older version of @agranlund’s firmware. Just don’t try the higher resolutions. :-)

I'm thinking the patches just don't work with 206. I'll try just enabling the 030 as I had better progress that way.

[exxos]

Does anyone see why this wouldn't work with TOS206 ?

TP_50 is the PAK stuff, I have tried with and without.

Oddly if I force TOS306 in the BIN, Hatari boots up with it.

On the TF536, it seems to reset, but gets stuck on a white screen.. no bombs or anything. So no idea why its getting stuck with this code, but only on TOS206 ?!

Code: Select all

/*
 * We must set the FastRAM refresh rate before we use it. The
 * rate is set by writing a "don't care" value to an address in
 * the range 0xffd00000-0xffd000ff; the low-order byte of the
 * address sets the refresh rate (specifically the number of
 * system clock cycles between each refresh request).  TT TOS
 * uses the value 0xe0; so do we.
 * NOTE: whether we actually have FastRAM or not, setting the
 * value always causes a bus error, so we need to handle it.
 */
#if ((TOSVERSION >= 0x200) & (TOSVERSION < 0x400)) | TP_50
 /*       move.l  #refresh_done,(_buserror).w  */    /* bus error vector */
 /*       move.w  #$0000,tt_mcu+224*/
refresh_done:

        /* Can we access FastRAM region? */

        move.l    #tt_ramsize_done,(_buserror).w
        move.w    #$FB55,d3           /* d3.w = difference between adjacent stored values */
        moveq.l   #0,d0
        move.l    #$00020000,d7       /* d7 = address gap between memory test zones */
        movea.l   #$01020000,a0       /* a0 = address of current test zone */
/*#if TP_50*/
		movea.l   a0,a2
		movea.l   d7,a1
		move.l    -(a0),d1
		not.l     d1
		move.l    d1,-(a1)
		sub.l     (a0)+,d1
		clr.l     (a1)+
		tst.l     d1
		beq.s     tt_ramsize_done
/*#endif*/
next_tt:
        movea.l   a0,a1               /* a1 -> memory being tested */
        move.w    d0,d2               /* d2.w = test value */
        moveq.l   #42,d1              /* d1.w = loop count-1 */
store_tt:
        move.w    d2,-(a1)            /* store a value */
        add.w     d3,d2               /* update the value for next time */
        dbf       d1,store_tt
/* now check the values we stored */
        movea.l   a0,a1               /* a1 -> test area */
        moveq.l   #42,d1              /* loop count */
check_tt:
        cmp.w     -(a1),d0
        bne.s     tt_ramsize_done
        clr.w     (a1)
        add.w     d3,d0
        dbf       d1,check_tt
        adda.l    d7,a0
/*#if TP_50*/
        move.l    a0,-4(a0)
        cmpa.l    -4(a2),a0
        bne.s     next_tt
/*#else*/
        bra.s     next_tt
/*#endif*/
tt_ramsize_done:                    /* bus error or bad ram  */
        suba.l    d7,a0
        cmpa.l    #$01000000,a0
        bne.s     ttramok
        suba.l    a0,a0
ttramok:
        move.l    a0,d5
        move.l    d5,(_ramtop).w
        move.l    #$1357BD13,(_ramvalid).w
#if !TP_50
        bset      #0,(scu_gp1).w
#endif
#else
        clr.l     _ramtop                /* no FASTRAM available */
        move.l    #$1357bd13,(_ramvalid).w   /* ramtop is valid (ramvalid == RAMMAGIC) */
#endif

nomemchk:

[exxos]

Still not having much luck :(

I'm wondering if the memory test routine is actually functioning correctly because I cannot see anything really wrong there ( but I know nothing about assembly anyway) . So I am starting to think now there may be when the RAM is enabled it's screws up something else in TOS somewhere. :shrug:

I know when boots that if it finds alt-ram tries to allocate the screen memory in that and screws up. Maybe this is part of that same problem. That is simply cannot enable the alt-ram during boot up.

As to why it actually works with TOS306 or PAK patches, must be patching something somewhere as a workaround to this :shrug: unfortunately I have currently been able to figure out which of the patches or relating to that setup. I'm just starting to think this is just a enormous waste of time.

[Badwolf]

Still not having much luck :(

What are you trying to to? Build TOS to be properly cache aware or just to autodetect the TT-RAM?

I know when boots that if it finds alt-ram tries to allocate the screen memory in that and screws up. Maybe this is part of that same problem. That is simply cannot enable the alt-ram during boot up.

I doubt it's that -- even a 1MB break (0x400000 to 0x500000) is enough to stop that happening. You've a gap between 0x400000 and 0x1000000.

BW

[exxos]

What are you trying to to? Build TOS to be properly cache aware or just to autodetect the TT-RAM?

Both.

The cache part seems to be working. But I can't get autodetect working for TTram without enabling the PAK patches.. but then the video / AES gets trashed.

What seems to trigger memory detect was the code I posted earlier. But this only seems to work with TOS306. on TOS206 it to completely break and just gets stuck on a blank white screen.

I just signed up with the Hatari mailing list and ask them about 24 bit "bug" as it would speed up development as I have to keep erasing/flashing eproms on the TF536 every five minutes.

[Badwolf]

What are you trying to to? Build TOS to be properly cache aware or just to autodetect the TT-RAM?

Both.

The cache part seems to be working. But I can't get autodetect working for TTram without enabling the PAK patches.. but then the video / AES gets trashed.

What seems to trigger memory detect was the code I posted earlier. But this only seems to work with TOS306. on TOS206 it to completely break and just gets stuck on a blank white screen.

You could try changing the code to hard coded values rather than worry about the memory detect?

It's basically only setting ramvalid to a magic number and ramtop, from what I can see. Presumably something else comes along and adds it to the memory pool later? Maybe that's the difference between TOS3 and TOS2?

BW

[stephen_usher]

As TOS 2.06 has no idea about TT-RAM it doesn't have code in it to make sure that the RAM it's allocating for the screen is in ST-RAM. TOS 3.06 would have this logic built into it.

Similarly, TOS 2.06 won't have the logic to prevent it using TT-RAM for DMA.