TOS RAM test routine ?

[exxos]

@Badwolf Translate

Code: Select all

assign STRAM_DECODE = A[29:24] != 6'h0 | ( A[23:20] != 4'h0 & A[23:20] != 4'h1 & A[23:20] != 4'h2 & A[23:20] != 4'h3 ) | AS30 | ~BGACK30;//
assign CIIN = (~ACCESS | (~STRAM_DECODE & (A[0] == 1'b0) & (SIZ[0] == 1'b0))) ;

Though I would surmise it only does 4MB ST-RAM. I don't think we ever thought about caching ROM because it would be loaded into TTram with MAPROM ..

Will see if I can pass TOSCE over to the cache logic.. its doubtful it will fit though..

EDIT:

wow compiling on the Ryzen CPU is way faster.. Still taking bloody ages tho

EDIT2:

"Process "Fit" failed"

[Badwolf]

@Badwolf Translate

Looks like ROM's outside of that, so that's good.

Interestingly it doesn't match on the registers either, nor on the shadow block of RAM at 0xFFxxxxxx.

Will see if I can pass TOSCE over to the cache logic.. its doubtful it will fit though..

Er, why? That would disable caching on the ROM.

BW

[exxos]

Will see if I can pass TOSCE over to the cache logic.. its doubtful it will fit though..

Er, why? That would disable caching on the ROM.

You lost me.. I thought we wanted to cache ROM to speed it up ? currently the logic doesn't cache ROM. So why is that good ?

[exxos]

Managed to pipe in ROM decoding into the cache logic. Though still no faster with TTram test I will double check I've not screwed something up.

EDIT:

Caches don't seem to make any odds to ROM test in GB6 on or off.

Cache forced on in firmware causes things to go nuts

Oddly cache forced off causes worse things to happen. Madness.

Eitherway, TTram test isn't any faster.

The only possibly way to gain speed is to just not do the RAM tests, or maybe somehow relocate the test routines into TTram and run from there. Buts thats well beyond my skill set. I guess ideally ROM needs to be relocated to TTram on startup so it doesn't need MAPROM later on.

[exxos]

Here are my results (64MB TT-RAM):

• ST536 TOS2.06 - 4 minutes 40 seconds.
• PAK/3 TOS3.06 - 23 seconds.

Just to note that the ST RAM test is similarly slow. with the PAK/3 TOS3.06 ROM taking only ~8 seconds to test 4MB.

I'm out of ideas what PAK is doing to speed up the test so much. Doesn't seem to make any odds PAKTOS on the ST536, if I turn caches on or off it makes no odds in TOS or firmware.

Still not sure how you got almost 5mins though. Mines always 2:25mins, but I get the same with PAK TOS.

I mean you are running the TF536 ? and on a normal ST ?

Does the PAK have DRAM or SRAM on it ?

Looking at ( I think ) the PAK030 cache logic.

Code: Select all

 !ciin      = a23 * a22 * a21 *  a20 *  a19 *  a18 * !a17                'ROM
            + a23 * a22 * a21 *  a20 *  a19 *  a18 * !a16                'ROM
            + a23 * a22 * a21 * !a20 * !a19                              'ROM
            + !fc0 * !a23 * !a22                                         'RAM
            + !fc1 * !a23 * !a22;                                        'RAM

Not sure why FC in there for the RAM address. But I tried just caching ROM and STram and didn't make any odds with TOS. But I guess I could try with PAKTOS just to be sure.

EDIT:

Nope, PAKTOS & STram & ROM access only makes no odds either.

[Darklord]

Probably not helpful in the least, but the 4 Megs of ST RAM in
my Pak 68/3 equipped STacy takes about 8-9 seconds to burn
through during the check. That's a modified TOS v3.06.

Unfortunately, I've still not found the time (yet) to install the
STorm ST board with its 8 Megs of ALT-RAM...

How about Derkom's STacy? Oh wait, with the TF he's using
TOS v2.06, I think? Yeah, never mind.

Oh well...I know you guys will get this sorted out sooner or
later.

It's interesting to read through the thread - keep up the good
work.

[exxos]

Oh well...I know you guys will get this sorted out sooner or
later.

It's interesting to read through the thread - keep up the good
work.

I'm out of ideas. It can't be TOS as PAKTOS runs slow as well. I don't see anything different in PAK firmware than the ST536 either.

The only way it could run faster is if TOS was somehow loaded into TTram on power up. But I don't see how that could be done.

I mean PAK is running 5x faster. Which 8mhz x 5 - 40mhz.

I wonder if I speed up ROM access on the ST536.. saying that.. Doesn't pak have 32bit ROM ?? What speed chips is it using ?

[Badwolf]

Er, why? That would disable caching on the ROM.

You lost me.. I thought we wanted to cache ROM to speed it up ? currently the logic doesn't cache ROM. So why is that good ?

I think you've got it backwards, CIIN is cache input inhibit. It's stopping read data being cached if it matches. Why would you want to add the ROM to that?

To be honest, if you've got a cache-aware OS now, you don't want CIIN asserted at all.

Cache forced on in firmware causes things to go nuts

You can't force the cache on in firmware! (You actually can't force it off either, but you can limit it being filled to a certain extent with CIIN)

BW

[exxos]

I think you've got it backwards, CIIN is cache input inhibit. It's stopping read data being cached if it matches. Why would you want to add the ROM to that?

I think you got it backwards The code works to ENABLE the ranges via the inhibit pin. It a "cache allow list" of ranges. It doesn't inhibit those ranges.

[Badwolf]

I think you got it backwards The code works to ENABLE the ranges via the inhibit pin. It a "cache allow list" of ranges. It doesn't inhibit those ranges.

Sorry, then I have no clue what's going on there.

Why are you inhibiting anything if ST-RAM is now permitted?

Code: Select all

CIIN = 1'b1;

BW