exxos's Atari, Amiga & retro forum

I've been thinking it might just be monumentally easier just to run the CPU at 50MHz all the time. I was going to do that originally but changed my mind.

A quick hack up (no TTram sorted yet) gave these results.

exxos wrote: 11 Jan 2026 16:21 I think I finally found the root cause. All the hacks I've done don't seem to matter anymore. ...
I've had to order a rather expensive scope as I believe my old one has been lying to me the whole time..

Very interesting, and intriguing. Don't keep us in the dark. :) What was the root cause and which kind of scope you are getting?

ijor wrote: 12 Jan 2026 04:46which kind of scope you are getting?

I'm getting a DHO924S. I need 4 channels and it's 250mhz. I think my 100mhz scope is missing some runt pulses.

TTram back working ..

But the odd side-effect is that the scores, in particular STram has dropped to 98% :shrug:


Just a comparison this is what it was before with clock switching..


So slightly puzzled where the delay is coming from..

exxos wrote: 11 Jan 2026 20:54 I've been thinking it might just be monumentally easier just to run the CPU at 50MHz all the time.

Even easier to have the memory run at 50MHz! (DFB1 ;) )

BW

Badwolf wrote: 13 Jan 2026 09:41 Even easier to have the memory run at 50MHz! (DFB1 ;) )

Yeah I been thinking that as well. But the SDRAM isn't actually a problem at all.

Been trying to claw back the lost speed but I don't think it is possible.. The problem is there has to be synchronisation logic to the ST bus which causes overhead where running the CPU at stock 8mhz doesn't have..

So this was basically the end result...


At some point TTram appeared to run faster.. Is not down to any timing difference.. Only thing I could assume is that "bus turnaround time" is faster which is tainting the results, or BURST is running more efficiently.. Probably more of the test is running faster rather than the actual ram itself or something like that. Either way, cannot be bothered to investigate it.


I did run frontbench and it basically is "missing" about 400 frames.. So ST RAM being slower as they can rather a big hit :(

Some going to abandon running the CPU a constant 50 MHz, It just overcomplicates everything and ultimately ends up running slower anyway.

Still waiting for my new scope to come :cry:

Would running the CPU at a constant multiple of the system clock, say 48MHz, allow the ST-RAM memory interface to run more quickly as the CPU and main system will always be in the same phase?

stephen_usher wrote: 13 Jan 2026 15:31 Would running the CPU at a constant multiple of the system clock, say 48MHz, allow the ST-RAM memory interface to run more quickly as the CPU and main system will always be in the same phase?

In theory yes..

Similar thing with my STE booster in fact.. 32MHz works well because it is in total sync with the motherboard.. I think I had to clock it something like 40MHz to compare to the 32mhz synced clock because of "overhead". The side-effect is TTram run will probably run a bit slower.

But one of the main problems is the very slow rise time on the ST clock... it would need a multiplying PLL to upscale the clock. But I think the ST clock bad rise and fall times are contributing to "clock skew" . Even with a buffer there would still be jitter.. which is in part where half of the problems are coming from I think...

Don't want to say too much about my current analysis because I'll probably have to write about 20 pages on it all.. I need my new scope to come so I can make better measurements first.. The conundrum is the 8 MHz system clock cannot be used as a reliable clock reference... Which poses a bit of a problem doesn't it.....

Can the accelerator be used to generate the ST clock in some way, disabling the on-board clock generation?

I can't remember where the ST clock is generated... Is it the Glue?