REV 3 - REV 5 - The beginning (ST536)

[exxos]

I've not tried emutos yet. Not sure its software related anyway.. But maybe emutos would show more debug info if something is actually crashing I guess...

I think STERM stays high after the hang.. I've not checked many other lines as it's not easy to probe the CPU pins with them being under the CPU

Disabling caches doesn't seem to make any odds either.

I've tried all sorts of syncs and delays on DTACK , makes no odds either.

[Badwolf]

I've not tried emutos yet. Not sure its software related anyway.. But maybe emutos would show more debug info if something is actually crashing I guess...

Aye and it's pretty simple to spin a custom version that takes all the helper apps out of the equation.

I think STERM stays high after the hang.. I've not checked many other lines as its not easy to probe the CPU pins with them being under the CPU

I've been known to cut male Dupont cables in half and solder the wiry end to the bottom of the pin of interest. Instant test points.

I've tried all sorts of syncs and delays on DTACK , makes no odds either.

AltRAM uses STERM. Doesn't assert DTACK at all. No point delaying it.

And like Stephen said, don't delay *anything* in the AltRAM cycle. STERM has to happen two cycles after CAS. It *has to*. Anything else is going to get you in a tail-spin PDQ.

BW

[exxos]

I've not touched the SDRAM code at all. When delaying DTACK I simply mean adding wait states because when the MMU issues DTACK, the data isn't actually ready yet, so I have to add delays else the CPU reads bad data.

The only thing it could be is if the SDRAM code doesn't add its own logic to delay STERM if it's doing a refresh cycle or something.. I mean if the CPU requests RAM while it's doing a refresh, does it screw up..I assume it's a bit more intelligent than that...

[Badwolf]

I've not touched the SDRAM code at all. When delaying DTACK I simply mean adding wait states because when the MMU issues DTACK, the data isn't actually ready yet, so I have to add delays else the CPU reads bad data.

OK, and you're confident that doesn't affect the AS to STERM timings inadvertently?

The only thing it could be is if the SDRAM code doesn't add its own logic to delay STERM if its doing a refresh cycle or something.. I mean if the CPU requests RAM while its doing a refresh, does it screw up..I assume its a bit more intelligent than that...

No, it won't be that. Stephen's said it's the same as the 330 code and I know how that works. Plus RAM access waiting for a refresh, or vice versa is really common. You wouldn't get to the desktop if that were a real problem.

I suppose it's the old but boring Occam's razor: is it reproducible on stock firmware?


BW

[exxos]

OK, and you're confident that doesn't affect the AS to STERM timings inadvertently?

I only mess with ST side timings.. I've got clauses everywhere so no way the CPU can get dtack etc when doing TTram stuff.

I suppose it's the old but boring Occam's razor: is it reproducible on stock firmware?

I will try it again when I get back home, but in terms of TTram and 50mhz, it be running like stock firmware anyway.

As stock firmware switches to 8mhz a lot it will run cooler , it just points to the CPU overheating again.

[Badwolf]

As stock firmware switches to 8mhz a lot it will run cooler , it just points to the CPU overheating again.

Ah true. Maybe a better test would be to bodge on a slower master clock, then?

I'm pretty sure the original firmware clock switching wouldn't work with a slower master, but yours might. If it boots at all you could then rule out CPU speed issues. One of your pot-adjustable RCOs would be ideal.

BW.

[exxos]

Ah true. Maybe a better test would be to bodge on a slower master clock, then?

I'm pretty sure the original firmware clock switching wouldn't work with a slower master, but yours might. If it boots at all you could then rule out CPU speed issues. One of your pot-adjustable RCOs would be ideal.

Yeah 80mhz would probably work just fine. Just annoying as it seems to work fine on 16bit stuff.. But maybe it's just due to the CPU waiting around a lot so it runs just cool enough to work.. But TTram completing cycles at 8x the speed shifts more data about which pushes it over the edge ...

Maybe I could add a second clock for the ram one that's a bit slower or something...only I'm out of pins on the PLD

[Badwolf]

Maybe I could add a second clock for the ram one that's a bit slower or something...only I'm out of pins on the PLD

That sounds iffy. Synchronicity is everything with the SDRAM.

If you want to try *slower* AltRAM access (ie. more waitstates, hoping it'll run cooler) then the safest way would be to add a delay to AS going into the SDRAM module. Once it sees AS (and 'ACCESS'), the SDRAM logic must be allowed to terminate on schedule.

BW.

[PhilC]

I'm sure I read that an 80mhz oscillator will work fine as is with the original firmware, so good chance it'll work with yours.

Then try those 68ec030 40mhz cpus perhaps?

[exxos]

That sounds iffy. Synchronicity is everything with the SDRAM.

If you want to try *slower* AltRAM access (ie. more waitstates, hoping it'll run cooler) then the safest way would be to add a delay to AS going into the SDRAM module. Once it sees AS (and 'ACCESS'), the SDRAM logic must be allowed to terminate on schedule.

True. As you say, my RSO would probably just be better. Let users experiment with what the max overclock can be.