Variable LOAD-pixel delay (shifter wakestates)?

[larsbrinkhoff]

The textbook answer is that there is an 18-cycle delay from the assertion of LOAD, until the first pixel is displayed. Of course, if some shifter IR registers are loaded before the start of the line, the delay would be lower: one of 6, 10, or 14.

I'm curious about the 2-cycle delay that is added on top of the loads. Has anyone has seen evidence for anything other than 2 cycles?

[troed]

Thoughts (not full-fletched hypotheses just yet):

1) "Spectrum 512 black pixels" - one shift (cycle) happens before xxxxx-palette-lookup-available-something
2) "Paulo bus-congested colored pixels" - one shift (cycle) happens before MMU has released the bus

The second one could possibly be the 2-cycle delay in that case being 1 cycle.

The second case is described and investigated by Paulo in the "Horizontal scrolling" thread. I'll press submit now and then go and quickly try to hunt down the relevant posts ... edit2: Here we go, they start here: http://www.atari-forum.com/viewtopic.ph ... &start=310

edit: It's possible (proposed by .. hmm .. Dio, maybe, it should be in the same thread) that the Shifter is running its 32MHz clock on the shifting registers completely desynchronized to external signals - which explains why some Shifter-effects are transient and affected by "warming". Some states, I think both the ones above, seem to persistent until power cycling though.

/Troed

[ijor]

The textbook answer is that there is an 18-cycle delay from the assertion of LOAD, until the first pixel is displayed ... I'm curious about the 2-cycle delay that is added on top of the loads. Has anyone has seen evidence for anything other than 2 cycles?

The delay is not exactly fixed. It depends on the resolution and the wakeup.

As about why exactly the value(s), just because. It is mostly a consequence of how SHIFTER resets and aligns the RR Reload logic, and then, exactly when the RR registers are loaded. It is not only a pipeline delay since shift to RGB output, if that's what you are thinking.

[ijor]

edit: It's possible (proposed by .. hmm .. Dio, maybe, it should be in the same thread) that the Shifter is running its 32MHz clock on the shifting registers completely desynchronized to external signals

That's not completely true. Shifting clock, of course is not synchronized to any external signal, actually it can't be. But the external control signals (CS, LOAD, and DE) are all (ultimately) synchronized to the 32 MHz clock.

There are two issues. The low rez pixel clock, and only the low rez, is not aligned to anything at all. Not aligned is different than not synchronized. It shouldn't produce unstable behavior (not by itself), but it can produce wakestates, and here it does.

The other issue is clock shifting. The ST has a chain of clocks divisions, 32 MHz into 16 MHz, into 8 MHz, and even then into 2 MHz (plus some more). Each division produces a small delay. So each divided clock is not precisely aligned with the one being divided. And these delays are cumulative. Furthermore, there are other synchronization design rules broken. So, as I was saying in other threads, synchronization issues in SHIFTER are not very surprising.

[larsbrinkhoff]

I'm not a hardware person. This is my mental model, and how I percieve the terminology.

When two clocks (or more generally, signals) are synchronised, there is some fixed constant number c such that if the amplitudes of the signals are described by functions f and g,

f(x) = g(x+c)

If c=0, then the clocks are said to be in in phase. If c≠0, there is an offset, aka shift, aka delay.

Is this correct?

[exxos]

The other issue is clock shifting. The ST has a chain of clocks divisions, 32 MHz into 16 MHz, into 8 MHz, and even then into 2 MHz (plus some more). Each division produces a small delay. So each divided clock is not precisely aligned with the one being divided.

It might be worth double checking on that. When I was testing the divisions, I got some odd results. Like 3ns between 32mhz and 16mhz on shifter, and 0ns between 16mhz and 8mhz on MMU IIRC. I was talking to Rodolphe about this last year as those delays are pretty impossible even with todays tech. Its not impossible though. If Atari had some buffer chain which matched the cycle time exactly (minus the actual propagation delays of the signal) , then each division would/could be half a cycle behind with a "slow" inverter and appear exactly in phase with 0ns delay (or near to). I also observed very slow rise and fall times on the clocks, could be a indication of slow buffers at work. I will see if I can find my notes on it..

EDIT1:

Been looking on my USB stick for images.. this could be 8mhz 4mhz..

4mst.png

[ijor]

It might be worth double checking on that. When I was testing the divisions, I got some odd results. Like 3ns between 32mhz and 16mhz on shifter, and 0ns between 16mhz and 8mhz on MMU IIRC.

I think you are remembering wrong. I have seen many traces and captures that clearly show the delay. No way 0ns between 16MHz and 8MHz (probably you are mixing with the delay between 8 MHz and 4 MHz). The first one, 32 MHz into 16 MHz is somewhat special, because the external 32 MHz is not an oscillator, the oscillating circuit is completed inside SHIFTER.

I was talking to Rodolphe about this last year as those delays are pretty impossible even with todays tech. Its not impossible though. If Atari had some buffer chain which matched the cycle time exactly (minus the actual propagation delays of the signal),then each division would/could be half a cycle behind with a "slow" inverter and appear exactly in phase with 0ns delay (or near to).

The chips don't have any buffer delay chain, and even if they had, it wouldn't be precise. That would require a PLL. But regardless of the theoretical possibility, nothing like that is implemented inside these chips.

Been looking on my USB stick for images.. this could be 8mhz 4mhz..

Yes, of course, 8 MHz and 4 MHz are pretty much very well aligned. And this is because the 4 MHz is not produced by diving the 8 MHz. Both of them are direct division of the same clock, the 16 MHz one. That is possible because they are produced both by MMU. Something similar happens between the 2 MHz and the 500 KHz clocks (both by GLUE).

If you would divide all the clocks at the same time, without a chain, then that would be fine. But here it's not possible because the clocks are produced by different chips. The STe with the MMU/GLUE combo might avoid one chain step, but don't remember seeing specific STe clock scopes.

Edit: Chris, I know I owe you an email replay. Got carried away by updating my reverse engineering work. Sorry about that

[ijor]

I'm not a hardware person. This is my mental model, and how I percieve the terminology.

This is a trace of the actual ST clocks:

Clocks1.png

See the huge delay between the 16 MHz edge (marked by the red vertical dotted line) and the 8 MHz one (blue vertical line). It is about 20 ns. Close to half cycle of the 16 Mhz pulse.
The 8 MHz and 4 MHz clocks are quite aligned, with a very small offset.

[larsbrinkhoff]

1) "Spectrum 512 black pixels" - one shift (cycle) happens before xxxxx-palette-lookup-available-something

Is there a (stable) test case for this?

[troed]

1) "Spectrum 512 black pixels" - one shift (cycle) happens before xxxxx-palette-lookup-available-something

Is there a (stable) test case for this?

I haven't tried it, but Paulo has created one: http://www.atari-forum.com/viewtopic.ph ... &start=310

/Troed

[ijor]

If Atari had some buffer chain which matched the cycle time exactly ...

The chips don't have any buffer delay chain, and even if they had, it wouldn't be precise. That would require a PLL. But regardless of the theoretical possibility, nothing like that is implemented inside these chips.

I must apologize to Chris. He was right and I was wrong.

At least one MMU version has indeed a buffer delay chain. And at least one sample achieves very low clock skew:
http://www.atari-forum.com/viewtopic.ph ... 41#p299721

Note that this exists (as I've seen so far) at the MMU only. Which means that the 32MHZ to 16MHZ division (done by Shifter), and 8MHZ to 2MHZ (by Glue), still have quite some considerable skew.