exxos's Atari, Amiga & retro forum

PhilC wrote: 21 May 2025 09:53 One down, one to go then @exxos

What was the problem with yours again. ? I suspect it's going to the the same problem again...

It's madness really because I've built 2 of the things , and both work fine in 2 different motherboards. But the one Steve built, doesn't work in my motherboard. It must just be a fluke of tollerences if it works or not. But that's down the the original 536 design. I still suspect me adding in ROM decoding simply pushed it all over the edge..

@exxos mine works great but with the Current 3 firmware, wouldn't work with Current 5.

dml wrote: 20 May 2025 20:25 The 030 takes multiple clocks to complete each instruction - each assembly op breaks down into simpler micro-ops on the chip - and each clock tick moves that pipeline forward - it can continue doing that even if it is waiting for a write to happen (writes are deferred) or while a write is happening.

That's interesting and something I hadn't really considered.

Speaking for DSTB1 as the closest analog (although that's not an 030 it talks to an ST bus) there are two advantages to slowing down.

While the processor is designed to work asynchronously the motherboard isn't. The most efficient way to turn around bus cycles is to assert DTACK not when the data is ready (or on a write, when the latch has happened), but on a promise.

That is to say on an 68k read DTACK is sampled going into S5 and the data latched going into S7. The ST asserts at least one (8MHz) cycle early so the 68k hits its gate. It's the 'synchronous' version of the cycle described in section 5.8 of the datasheet.

If we're running at 50MHz we need to keep track of what state the ST thinks its in and what state we're actually in and therefore delay DTACK assertion until both tie up. In theory it's doable, but it's tricky and complicated by additional wait states from RAM refreshes and the fact that some accesses (eg ROM) generate DTACK immediately (ie. going into S3). Propagation or clock-domain crossing resampling delays mean you tend to end up having to err on the side of caution (eg. you think the ST thinks it's in one state, but really you were a bit slow and it's actually two states later so you hold off DTACK for an extra 125ns unecessarily) and so ST-RAM speed access takes a hit.

I had a second obvious reason when I started writing this, but I've lost it now! I'm getting old, you know!

BW

BW thanks for the explanation :)

Badwolf wrote: 21 May 2025 10:34 If we're running at 50MHz we need to keep track of what state the ST thinks its in and what state we're actually in and therefore delay DTACK assertion until both tie up. In theory it's doable, but it's tricky and complicated by additional wait states from RAM refreshes and the fact that some accesses (eg ROM) generate DTACK immediately (ie. going into S3). Propagation or clock-domain crossing resampling delays mean you tend to end up having to err on the side of caution (eg. you think the ST thinks it's in one state, but really you were a bit slow and it's actually two states later so you hold off DTACK for an extra 125ns unecessarily) and so ST-RAM speed access takes a hit.

So, you can't take the traditional approach of just blindly shoving the /DTACK signal through a couple of inverter gates to delay it a few nS then? ;-)

As for the clock speed of the CPU, I've always thought that it would be more tricky (and potentially slower) to use a non-exact multiple of the system clock for the CPU as you'll be constantly facing phase changes between the two clocks. Surely better to stick with a fixed multiple clock frequency, preferably an order of two, tied to be in phase with the system clock?

stephen_usher wrote: 21 May 2025 12:33 As for the clock speed of the CPU, I've always thought that it would be more tricky (and potentially slower) to use a non-exact multiple of the system clock for the CPU as you'll be constantly facing phase changes between the two clocks. Surely better to stick with a fixed multiple clock frequency, preferably an order of two, tied to be in phase with the system clock?

That's true - it would be better to stay synchronous at a multiple of the bus clock, fewer 'misses' - but as you get into decent multiples it starts to matter less and less. So 8/17MHz async is probably going to be measurably worse than 8/16MHz synchronous :) but 8MHz/50MHz async is probably not worse than 8/48MHz synchronous... unless it's the bus side which is missing/retrying - then it gets more complicated.

Still the fact remains - if switching down, the internal ALU microcode pipe will be ticking along at 8MHz instead of 50, while a write is ongoing, which means some loss for cached loops trying to write pixels etc. How much loss though in practice - I don't know.

@Steve been running all day !

@exxos awesome!!! So are the changes you made to the firmware for mine to work beneficial for all? Was mine just a bit on the edge.

Steve wrote: 21 May 2025 19:03 @exxos awesome!!! So are the changes you made to the firmware for mine to work beneficial for all? Was mine just a bit on the edge.

The 22pF cap seems to need to be 33pF , but I fitted 47pF. I didn't seem much between the 33 and 47 anyway.

Yours only worked with my current bodged firmware where I am debugging the fast-rom oddness.. I will upload that as CURRENT7 firmware as a fallback.

I think by the time the address bus has gone through the PLD to the SDRAM, its already 10ns to slow. So the SDRAM thinks it can start a cycle but its address isn't stable yet. Me adding in the fast-rom logic delayed it even more and trashed it totally. So now I have a extra delay in SDRAM access now.

It must just be a fluke if the address bus settled in time or not.. on my build yes.. for some reason on yours.. no...

Still puzzling over the fast-rom issue. I'm trying to build a state machine but they never seem to work for me :lol: :roll:

But yes, this discovery will help future builds as I am now more aware of what the problem likely is..

@exxos feel free to keep mine for as long as you need.