Variable LOAD-pixel delay (shifter wakestates)?

GFA, ASM, STOS, ...

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Variable LOAD-pixel delay (shifter wakestates)?

Postby larsbrinkhoff » Wed Mar 23, 2016 6:51 am

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?
Last edited by larsbrinkhoff on Wed Mar 23, 2016 6:06 pm, edited 1 time in total.

User avatar
troed
Atari God
Atari God
Posts: 1178
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby troed » Wed Mar 23, 2016 11:12 am

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: viewtopic.php?f=16&t=24855&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
Hardware Guru
Hardware Guru
Posts: 3022
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby ijor » Wed Mar 30, 2016 3:52 am

larsbrinkhoff wrote: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
Hardware Guru
Hardware Guru
Posts: 3022
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby ijor » Wed Mar 30, 2016 4:16 am

troed wrote: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.

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby larsbrinkhoff » Wed Apr 06, 2016 6:30 am

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?

User avatar
exxos
Hardware Guru
Hardware Guru
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby exxos » Wed Apr 06, 2016 7:40 am

ijor wrote: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
You do not have the required permissions to view the files attached to this post.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

ijor
Hardware Guru
Hardware Guru
Posts: 3022
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby ijor » Wed Apr 06, 2016 10:17 am

exxos wrote: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
Hardware Guru
Hardware Guru
Posts: 3022
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby ijor » Wed Apr 06, 2016 1:21 pm

larsbrinkhoff wrote: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.
You do not have the required permissions to view the files attached to this post.

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby larsbrinkhoff » Tue Apr 12, 2016 12:33 pm

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


Is there a (stable) test case for this?

User avatar
troed
Atari God
Atari God
Posts: 1178
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby troed » Tue Apr 12, 2016 1:21 pm

larsbrinkhoff wrote:
troed wrote: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: viewtopic.php?f=16&t=24855&start=310

/Troed

ijor
Hardware Guru
Hardware Guru
Posts: 3022
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Variable LOAD-pixel delay (shifter wakestates)?

Postby ijor » Wed Aug 17, 2016 2:21 am

ijor wrote:
exxos wrote: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:
viewtopic.php?f=15&t=30241#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.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests