ST536 STE EDITION

[Steve]

So much going on in this thread... I must admit, I lost track a while back. I know this latest round of mods were spawned from the issues with BW's STe... does this mean all these changes will apply across the board, to everyones STe536?

[exxos]

So much going on in this thread... I must admit, I lost track a while back. I know this latest round of mods were spawned from the issues with BW's STe... does this mean all these changes will apply across the board, to everyones STe536?

BW's STE was fixed a few weeks ago.. All the current mods came from issues I found from the ST536 boards.. I made the changes to BW's STE and it still seems fine. The more I look, the more problems I find. So I am working through them all one by one..

The mods for the ST and STE536 with the 288xl PLD should be done. Though there may well be further (or even different) mods after my next round of tests...

The main problems were bad clock drive to the SDRAM and PLD. BUT there are some weird things where bad TTram corrupts the ST bus which I haven't traced yet. But it's stemming from a borderline clock between the SDRAM and CPU.. Hence the buffer board I did which will allow me to find the optimum timings.

The boards I am building now I am intending to be put in the store as fully built boards.. Still classing it as a BETA at this point.. But currently I don't know of any issues.. So nothing left for me to fix now until more boards get out in the wild..

[exxos]

Been doing tests on the ST and STE536.. but finding similar problems on both boards now. Very bad ringing on some signals :roll: Adding some series resistance is tricky , but doable. Now it was enough to break SDRAM again :roll:

IMG_4271.JPG

IMG_4278.JPG

I think this is why I have been mistakenly blaming the clock the whole time (yellow)

The timings on the SDRAM are insanely tight at 100mhz. So reduce the ringing, end up with some skew which has to be fixed another way..

Now I have my small buffer boards. This *should* resync the SDRAM back into working again.. hopefully I can try this out today..

On the ST536, fast and slow slew make no odds with the buffer board.. so fast/slow was enough to break it before.. nevermind tolerances on everything ! so the buffer helps mitigate those issues...

[exxos]

Was testing out @Badwolf's STE again. While it would run hours, now it's totally unstable again :roll: I had a suspicion it was ROM related and it was.

I asked GPT5 about it all and it said basically my code can have race conditions and metastability etc then it had a 20 page rant on everything wrong with my 3 lines of code :lol: :roll:

I was latching signals in the fast clock domain where if that signal changes on a 100mhz clock edge.. The outcome becomes unpredictable. I was latching it to prevent just that :lol: but wrong clock domain apparently :roll:

Also it moaned about my shadow latch flag.. I thought its a one shot deal which just goes high and stays high after ROM copies to ram.. But apparently even that's wrong.

So I need to go fix all those issues now. It might explain why I have odd ROM issues after a reset. When the shadow ROM is running, after a warm reset, it says bad rom chip in E. Which makes no sense because if the ROM shadow was bad, the OS shouldn't be running.. But possible random bit errors might not show up depending what gets corrupted.

Its possible my ROM logic could trigger at random and maybe that's why I'm having such issues with TTram. I did all sorts of hacks to the SDRAM code to get it running lastnight. Then after doing some simple changes to the ROM logic, it worked fine without all the hacks.

Its also likely the bodge on the SDRAM clock with current fixes may not be needed now.. Also as i found before, the STE is really sulky on clock sync but that's a easy thing to fix.

I'm away for 2 days now.. So I'll work on fixes maybe Friday..

[exxos]

Been working on stability changes.

Its odd, because originally (ST536 screenshot) Where TTram is 847%, ROM is 805%

ORIG.JPG

To later code changes, where TTram is now 832% ... and ROM 710%.. so both slower..

IMG_4297.JPG

BUT, if you look at the actual test scores, there are actually now faster ! Display tests went up from 289% to 301% ! Even though the ROM and TTram scores are now slower ! :lol:

No idea why that's happening !
:dizzy:

Thing is, the drop in TTram speed is there because the cycle start is unstable. I think its borderline to start with by the original module. Then when I add even a tiny bit of logic , its enough to drop the TTram score. Basically I am delaying the TTram cycle start by 10ns now. It gives thing more time to settle on the bus including the ROM shadow logic.

So its a given the module is now delayed 10ns, and now TTram is "slower". But somehow its ended up with other tests running faster.. so im not sure if this is a "bad thing" or not really now :lol: But the delay *has* to be there else its unstable as hell.

GPT5 thinks

"The 10 ns /AS delay slows pure TT-RAM accesses because it effectively adds half a CPU cycle to every memory request, but it can make some programs run faster overall by masking a timing coherency issue that otherwise causes hidden stalls and inefficiencies when ROM shadowing and mixed memory accesses are involved."

Why a 10 ns /AS delay drops TT-RAM score (847% → 832%)

You are delaying the request acceptance, not the SDRAM itself.
The SDRAM FSM can only start a cycle after /AS is seen low. Adding ~10 ns pushes the earliest possible ACTIVATE later, effectively inserting a fraction of a wait state on every TT-RAM access.

At 50 MHz CPU, 10 ns is non-trivial.
One CPU cycle is 20 ns. A 10 ns delay is ½ a CPU cycle of lost overlap. Benchmarks that hammer TT-RAM show this immediately.

Burst/page efficiency drops slightly.
Your controller benefits from page hits and burst timing alignment. Delaying the request shifts when ACTIVATE/READ land relative to the CPU’s demand stream, reducing effective burst utilization even though SDRAM timing itself is unchanged.

Why some tests got faster despite slower TT-RAM/ROM

This is the counter-intuitive but real part:

The delay fixed a coherency hazard.
Without the delay, some accesses were marginal (address/decode settling). That causes:

occasional extra retries

suboptimal precharge timing

wasted internal cycles that benchmarks don’t always count as “wait states”

With the delay, the system is more deterministic.
Fewer misaligned accesses → fewer hidden penalties → better average throughput in workloads that:

mix ST-RAM and TT-RAM

hit caches heavily

are CPU-bound rather than pure memory-bandwidth tests

Benchmarks measure different things.

TT-RAM bandwidth tests go down (expected).

Real-world or mixed tests can go up because stalls/jitter are reduced.

So raw bandwidth goes down a bit, overall efficiency goes up in some cases. So kinda a win I guess ? :shrug:

[exxos]

@coonsgm @PhilC et'al..

New STE mod instructions and firmware..

https://www.exxosforum.co.uk/atari/last ... tm#2025MOD

If anyone did the wire mod before then it now needs to be removed.. And the new firmware flashing..

This firmware solves several stability issues I found over the past few weeks..

I've only run GB6 so far.. But it was unstable as hell before doing the mods and new firmware on @Badwolf's STE.

I had to massively change the clock sync as well to get BW's STE stable.. So it may need to be changed again, as it could have been a red herring caused by all the things which were fixed since then... I put both firmwares up just in case.. both should be tested anyway so I can build a picture of what works best overall..


The expected benchmark... (my modded TOS206) (do not use MAPROM)

IMG_4297.JPG

IMG_4302.JPG

Overall the scores are a bit higher than originally.

[coonsgm]

Could you take a few photos of both sides of the board and post? I want to make sure I interpret them correctly before making the changes.

If I were to start with my 2nd ST536 with the 144 still installed, would I still need to add the extra birdseed parts to the bottom of the board for this mod? I obviously, know I'll need to swap out the 144 for a 288.

[exxos]

Could you take a few photos of both sides of the board and post? I want to make sure I interpret them correctly before making the changes.

Sure.. but my board is probably different because of other experiments...

The little borders o'clock mod seemed to improve things previously.. But I don't believe all boards have this .. and might not be actually needed now..

IMG_4305.JPG

The little board on top is a experimenter not part of any official mod...

There are three resistors which are inserted in some control lines... But I don't really expect anyone to manage this.. So I did not publish that mod..

IMG_4304.JPG

If I were to start with my 2nd ST536 with the 144 still installed, would I still need to add the extra birdseed parts to the bottom of the board for this mod? I obviously, know I'll need to swap out the 144 for a 288.

It may work without the additional caps, but I can't say for sure on every board.. The 3.3V rail is spiking a lot... I suggest try without the caps and see how people go first..

I did not do all the caps on the board because my hands are hurting a lot again lately..

[coonsgm]

Aha,

Sorry for some reason I mixed up STE and ST editions. I was thinking my ST536

[exxos]

Sorry for some reason I mixed up STE and ST editions. I was thinking my ST536

Imagine how confused I am with it all :lol: :crazy:

I'm just letting the STE536 run some YAARTTT loops on @Badwolf STE first.. I will switch over to the ST536 after and see whats broke with that next :P