ST536 STE EDITION

[dml]

\o/ epic watching exxos teaching GPT how to write 68k bootstraps!

(+ congrats on getting it to work - that stuff is always very tricky and patience-testing)

[exxos]

:D

Converted the TTram test routine to 32bit and upped the test block size from 128K to 256K. But oddly going to 512KB doesn't speed it up anymore. Similar with it only actually tests 86 bytes every 128KB block, I tried half that and speed still didn't go up.. pretty odd!

So TTram test take about 30 seconds now, rather than about 427 hours...

[dml]

Speed aside, there's a bit of an art to testing RAM properly. First mistake is to assume all the ram is where you expect it to be and is all unique.

It's not worth doing bit-level fidelity or retention testing until you know where the RAM actually is, and you can't use bit testing alone to find it because you might be testing mirrors/copies/dupes of the same ram repeated over and over, if the RAM addressing is broken (if an address bit is dead you'll get repeats of the same block of ram in different places).

So the first step is usually to make a map of valid ranges.

An easy way to build the map is to write the address into the data of the location itself, while disabling/absorbing bus errors. You do that across the maximum address range you want to support. To speed it up, you break it into pages of e.g. 4kb and just write the page index into the page header.

You then scan all the pages again and if the index you stored in the page doesn't match the address, you're dealing with a mirror and you mark that range as invalid. Doing this in reverse leaves you with the 'real' ranges at the lower address and the mirrors somewhere higher up.

If you end up with one big contiguous range, your RAM addressing is probably ok. If you get range gaps or some areas went missing - broken addressing, SIMM slot or RAM chips.

Once you have the unique range(s) mapped out then you can get on with the bit level tests because you know each location is a real, unique location in a valid address range.

[exxos]

What TOS does is "just a quick poke" to see whats theres. It doesn't even check the full RAM. It would take forever if it did.

I think its just maxed out the RAM bandwidth or something at this point. No change at all makes it go faster than 30 seconds to test. Also theres likely a bit of overhead since TOS is now running from TTram.. how much.. maybe not that much..

This is the current code if you want to take a look. Reducing the tested bytes count or increasing the block size makes no odds. So not sure whats going on.

Code: Select all

       move.l  #refresh_done,(_buserror).w
    move.w  #$0000,tt_mcu+224

refresh_done:
    move.l  #tt_ramsize_done,(_buserror).w
    move.l  #$A5A5A5A5,d2         /* Fixed test pattern */
    moveq   #0,d0
    move.l  #$00040000,d7         /* 256KB block step */
    movea.l #$01020000,a0

#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
    moveq   #21,d1                /* Test 22 longwords per block */
store_tt:
    move.l  d2,(a1)+
    dbf     d1,store_tt

    movea.l a0,a1
    moveq   #21,d1
check_tt:
    cmp.l   (a1)+,d2
    bne.s   tt_ramsize_done
    clr.l   -4(a1)
    dbf     d1,check_tt

    adda.l  d7,a0                 /* Next 256KB block */

#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:
    suba.l  d7,a0
    cmpa.l  #$01000000,a0
    beq.s   no_ttram
    bra.s   ttramok

no_ttram:
    suba.l  a0,a0
    bra.s   ttram_done

ttramok:
    move.w  #$070,$FFFF8240      /* Blue = TT-RAM found */

ttram_done:
    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
    move.l  #$1357BD13,(_ramvalid).w
    /* move.w #$700,$FFFF8240 */
#endif

[dml]

Yeah that's..... pretty basic for a ram test o_o It's enough to scope our whats there providing there are no deeper problems.

I'm hoping to do something for bootstrapping my DFB1X soon - nearly done with repairing things for now - will revisit the RAM testing thing at the same time.

[exxos]

GPT4 says DBF is slow on the 030 and its a 16bit instruction. Its also on about unrolling loops to use DBF less. Not sure on the speed gain as not sure where the main speed loss is.

Out of time for this week, have to fiddle some more on Monday now :)

[dml]

GPT4 says DBF is slow on the 030 and its a 16bit instruction.

GPT is trolling you a little bit.

Its also on about unrolling loops to use DBF less. Not sure on the speed gain as not sure where the main speed loss is.

Too tired to look now but DBF is unlikely to be the main problem, versus just testing fewer locations. Isn't the CPU running at 50MHz at that point anyway?

Out of time for this week, have to fiddle some more on Monday now :)

:thumbup:

[exxos]

Too tired to look now but DBF is unlikely to be the main problem, versus just testing fewer locations. Isn't the CPU running at 50MHz at that point anyway?

50mhz yep.

Testing fewer locations or less words doesn't increase the speed though... It did going from 128kb to 256kb. But going to 512kb made no odds at all.. Testing fewer words per block made no odds either...

I moved from words to longwords for full 32bit access.. Made no odds either..

I mean testing a few words every 256k block should fly by... Should go 50% faster with 512k blocks.. But nope... There's some odd bottleneck somewhere..

TOS is running from TTram as well. There's not much in screen output either... But saying that.. There's no screen output in that routine.. So maybe there's other code later on somewhere :roll:

[exxos]

Yep I got confused over the routines. The one I'm messing with just detects ramtop.

The actual RAM test does...

Pass 1: Fill with $FFFFFFFF (all 1s) and verify
Pass 2: Bit-walking pattern (ROL.L #1)
Pass 3: Fill with all 0s and verify

I can probably up the block size to 256k in there and it should go twice as fast.. I don't really want to take any tests out. But surely walking 1s would cover it all anyway?

I suppose as there's 2 separate 16bit chips, walking 1s in both chips at the same time should be fine I guess? I mean bit 0 and bit 16 are in different chips etc...

But surely own address test would be a good one to have...

Its past 1am :lol: but I think for a sanity TTram test, own address and dual walking ones should be good enough. It would save a lot of time and still give a good power up test. We have YAARTTT for indepth testing...

[stephen_usher]

If you're replacing the RAM test you may was well replace it with a proper March test:

1) Fill whole memory with 1s
2) XOR whole memory with 1s, starting at the top and work back, verifying that it's all 1s before XORing.
3) XOR whole memory with 1s, starting at the bottom and verify, verifying that it's all 0s before XORing.
4) Verify that everything is 1s

This will catch all bit and addressing errors.