ST Chipset decap

[troed]

Awesome! Agree that I've never seen in it medium, but the emulation is just right for low and high

[Steven Seagal]

EDIT
Since this post is still there, let's show the traces for the Amiga demo (see below for explanation of PX):

Code: Select all

004 - 062:DE1002 070:PX0001 382:DE0302 385:PX0000 512:#00A0
005 - 062:DE1002 070:PX0001 382:DE0302 385:PX0000 419:I0068 512:#00A0
006 - 062:DE1002 070:PX0001 382:DE0302 385:PX0000 512:#00A0
007 - 062:DE1002 070:PX0001 379:S0000 391:S0002 470:DE0102 512:#00CC
008 - 062:DE1202 081:RL0002 379:S0000 391:S0002 470:DE0102 512:#00CC
009 - 062:DE1202 081:RL0002 379:S0000 391:S0002 470:DE0102 512:#00CC
010 - 062:DE1202 081:RL0002 379:S0000 391:S0002 470:DE0102 512:#00CC

Because of the 'right off' trick at line 7, the Shifter ends the line with 2 extra words (line +44 = 5*8 +4).
The pixel counter doesn't stop. On the next line the two extra words are lost.

[ijor]

More than a year later, here are emulation screenshots illustrating the consequence of the Shifter bug in three resolutions, obtained by an exaggerated delay before the pixel clock activates.

Very nice

[Steven Seagal]

This screenshot shows what happens if there is no stabilizer, in this case a R1/R0 switch at the end of the overscan line, neutralized by changing the code of the demo (write 0 instead of 1):

no_stab-min.png

The traces below show what happens at low level.
"PX" marks when the pixel counter starts and stops (line 90).
Due to overscan tricks, it doesn't stop anymore on line 91.
"RL" means that the Shifter had more than 4 LOADS when it reloaded. It happens on the start ("linecycle" 33) of lines 92 and 93, which are shifted.

Code: Select all

090 - 062:DE1002 070:PX0001 382:DE0302 385:PX0000 512:#00A0
091 - 062:DE1002 070:PX0001 379:S0000 395:S0002 443:R000A 459:R000A 470:DE0102 512:#00CC
092 - -01:R2000 010:DE1222 015:R000E 033:RL0003 379:S0000 395:S0002 443:R000A 459:R000A 470:DE0102 512:#00E6
093 - -01:R2000 010:DE1222 015:R000E 033:RL0003 379:S0000 395:S0002 443:R000A 459:R000A 470:DE0102 512:#00E6

When there is a stabilizer (unchanged demo), the pixel counter runs faster at times (R1), so that at the end of the line, there's a final reload, cleaning up the extra LOADs, and the pixel counter stops.

Code: Select all

090 - 062:DE1002 070:PX0001 382:DE0302 385:PX0000 512:#00A0
091 - 062:DE1002 070:PX0001 379:S0000 395:S0002 443:R100B 454:RL0001 459:R000A 470:DE0402 481:RL0001 481:PX0000 512:#00CC
092 - -01:R2004 010:DE1022 015:R0004 018:PX0001 379:S0000 395:S0002 443:R100F 452:RL0001 459:R000E 470:DE0502 477:RL0002 477:PX0000 512:#00E6
093 - -01:R2004 010:DE1022 015:R0004 018:PX0001 379:S0000 395:S0002 443:R100F 452:RL0001 459:R000E 470:DE0502 477:RL0002 477:PX0000 512:#00E6

If you check line 92 for example, without stabilizer there is a reload with 3 extra LOADs before display, with a stabilizer there is a reload with 1 extra LOAD then another with 2 extra LOADs after display. Same total.
The timing of those reloads makes the difference (apparently, because I'm still wondering what's the difference between this and the Amiga demo above...).

EDIT:
The difference is that in the Amiga Demo, there are 2 extra words at the start of the line, and 2 words get lost due to extra LOADS.
In this demo without stabilizer, there are 2 extra words as well, but 3 get lost, hence the shift.
The value of the LOAD counter is indicated as the second digit after DE, knowing that there's a last load after DE is negated.
(DE0102 means DE off, LOAD counter=1, shift mode 0, sync 2).

[troed]

While I've only done some brief tests, the fact that setting both bits in RES is read as HI by GLUE and stops the clock mux in the Shifter has allowed me to get my "stabilizer-less" fullscreen scanline as used in {Closure} to display correctly with both my code paths in WS2.

Recap: I got the line working in WS1,WS3 and WS4 - always. In WS2 I had two code paths, one that worked in one Shifter wakeup (I guess) and one that worked in the other. On my machines this was migratory, I called them "cold" and "warm". The non-working path produced "every other 16 pixels background" problem, and when I released the demo I simply included the one that worked in "cold" (on my test machine).

I now have a variant where I use the RES=3 trick, and both code paths are now producing a perfect image. The machine is very warm though, will re-test once it's cold as well.

I've studied Ijor's explanation in great detail, and this is "logical". Probing the timing with RES=3 _should_ desynch the LOAD and RELOAD timing enough to create (or fix) the "banded" error. And my tests just now seem to confirm this.

Next up I will start looking into the low/medium alternating lines and see if I can visually detect the different Shifter wakeups, and whether they agree with what I think (and whether they can actually migrate or are stable once booted).

/Troed

PS: The mental model I'm currently working with, that IMHO explains the above with regards to the Closure scanline, also indicates it might be worthwhile re-visting Paulo's non-fullscreen 4 pixel sync scroller, which failed one offset always in WS1 and sometimes in WS3, due to LOAD/RELOAD timing and Shifter wakeup.

[Steven Seagal]

Recap: I got the line working in WS1,WS3 and WS4 - always. In WS2 I had two code paths, one that worked in one Shifter wakeup (I guess) and one that worked in the other. On my machines this was migratory, I called them "cold" and "warm". The non-working path produced "every other 16 pixels background" problem, and when I released the demo I simply included the one that worked in "cold" (on my test machine).

When you got those border bands, were the planes shifted as well?

[troed]

Recap: I got the line working in WS1,WS3 and WS4 - always. In WS2 I had two code paths, one that worked in one Shifter wakeup (I guess) and one that worked in the other. On my machines this was migratory, I called them "cold" and "warm". The non-working path produced "every other 16 pixels background" problem, and when I released the demo I simply included the one that worked in "cold" (on my test machine).

When you got those border bands, were the planes shifted as well?

Nope. Just every other 16 pixels blank.

(Since I have two code paths I can force this to happen at will on my WS2-loving Mega ST)

Btw, I forgot to mention, I only do the RES=3 trick on the first scanline. It nudges the pixel clock "right" for the rest of the screen.

/Troed

[Steven Seagal]

Below is a seudo simulation waveform of the 4-bit hard scroll.
NOTE: the timing is not exact. This is just for the purpose of illustrating the idea of the K offset.

Seudo-4bit.png

The two vertical guides mark the moment that the resolution changed. First from mono to medium, then to low. Between both changes there are exactly 8 cycles.

However, by the time that the resolution changed to medium, the pixel counter didn't start counting. Counting starts only after the first LOAD pulse (light blue), that activates the cntrEn signal (red). The reload will be aligned according to the shifted value of this counter. This is what actually scrolls the display, the reload timing.

So shifter doesn't count 8 cycles at medium rez, but less. Then the reload position would be displaced less than 8 cycles. This gives the offset that is not multiple of 4.

Here are traces of a low level emulation of the 4bit scroll and a table.

Code: Select all

ST-connexion 4 bit scroller

090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 022:R0001 037:RL200A 378:S0000 386:S0002 446:R200A 458:R0009 470:DE0402 481:RL100A 481:PX0000 512:#00E6

090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 026:R0009 033:RL100A 378:S0000 386:S0002 446:R200E 458:R000D 470:DE0502 477:RL200A 477:PX0000 512:#00E6

090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 030:RL000D 030:R0001 378:S0000 386:S0002 446:R2002 458:R0001 470:DE0602 473:RL300A 473:PX0000 512:#00E6

090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 030:RL000D 034:R0009 057:RL300A 378:S0000 386:S0002 446:R2006 458:R0005 470:DE0302 485:PX0000 512:#00E6



A    B           C        D       E     F              G                H          
R1   R0   cycles R0-R1   13-C    RL    E-'32'   accelerated pixels   total shift

14   22          8        5      37      5             0                5
14   26         12        1      33      1             0                1
14   30         16       -3      30     -2             0               -2
14   34         20       -7      30     -2             4               -6 

It is tentative at this point because I don't obtain all expected values (comparing columns D and H).
In D are the theoretical values used in emulators up to now.
The traces give the "events" for the same scanline 90 in 4 successive frames.
The switch to R0 happens at 22, 26, 30 and 34.
The first "RL" (reload) of the line indicates when the Shifter starts shifting out pixels.
The pixel counter explains some shift between the lines: 37-33 = 4, fine
But 33-30=3
For the last line, "RL" happens at the same cycle, but the Shifter is still in MED RES for 4 cycles.
This means that it shifts out 8 pixels instead of 4, hence a shift of 4 compared with the line before (?).
I accept contradiction on this , maybe some timings are wrong, but were the pixel shifts actually counted?

[troed]

maybe some timings are wrong, but were the pixel shifts actually counted?

What are you asking? If the scroll worked as described? Yes, it did (does)

Do note however that it worked in WS2, WS4, WS3 "50%" and not in WS1 (one offset could not be reached). The reason is (surely) the DE-to-LOAD delay which means it wasn't possible to leave a word in the Shifter at the end of a line in WS1 (and in one Shifter wakeup, WS3).

[Steven Seagal]

maybe some timings are wrong, but were the pixel shifts actually counted?

What are you asking? If the scroll worked as described? Yes, it did (does)

No, if the shifts are certified 4pixels.

Do note however that it worked in WS2, WS4, WS3 "50%" and not in WS1 (one offset could not be reached). The reason is (surely) the DE-to-LOAD delay which means it wasn't possible to leave a word in the Shifter at the end of a line in WS1 (and in one Shifter wakeup, WS3).

Which isn't the case in my emulation, I didn't know that.

[troed]

No, if the shifts are certified 4pixels.

I'm still not sure I understand your question. The scroll indeed scrolls at 4 pixel increments (one word).

/Troed

[Steven Seagal]

Well, if you look at the little table I posted you can see my problem. Is the shift visible on the screen 4bit (4 pixels) each step or is there one step of 3 pixels? I figure it's not so easy to see?

[troed]

Well, if you look at the little table I posted you can see my problem. Is the shift visible on the screen 4bit (4 pixels) each step or is there one step of 3 pixels? I figure it's not so easy to see?

No, they're four pixels (else the scroll would not work). The steps are made by leaving 0-3 words in the Shifter, which will cause it to output graphics 0-3 words "earlier" (since the four words fill up faster on the new line). You cannot count cycles as pixels here, the words are discrete.

[ijor]

While I've only done some brief tests, the fact that setting both bits in RES is read as HI by GLUE and stops the clock mux in the Shifter has allowed me to get my "stabilizer-less" fullscreen scanline as used in {Closure} to display correctly with both my code paths in WS2.

Recap: I got the line working in WS1,WS3 and WS4 - always. In WS2 I had two code paths, one that worked in one Shifter wakeup (I guess) and one that worked in the other. On my machines this was migratory, I called them "cold" and "warm". The non-working path produced "every other 16 pixels background" problem, and when I released the demo I simply included the one that worked in "cold" (on my test machine).
...

I'm out of home now and can't address the technical side with much details. But it is great news, and it is also great news that you are back active on the retro business

[Steven Seagal]

No, they're four pixels (else the scroll would not work). The steps are made by leaving 0-3 words in the Shifter, which will cause it to output graphics 0-3 words "earlier" (since the four words fill up faster on the new line). You cannot count cycles as pixels here, the words are discrete.

I'm not asking the theory but if we're sure that each step is 4 pixels, because on an experimental Steem build the scroll apparently works but delivers the traces I posted, showing shifts of 5, 1, -2, and -6 instead of the expected 5, 1, -3, -7.
In other words, were the shifts precisely measured on a STF?

[troed]

I'm sorry but I fail in coming up with additional ways to state the same thing over and over.

[Steven Seagal]

I also keep asking the same question over and over. Let's leave it at that, I think there's a misunderstanding about the question.

[ijor]

Here are traces of a low level emulation of the 4bit scroll and a table.
...
ST-connexion 4 bit scroller
...
I'm not asking the theory but if we're sure that each step is 4 pixels, because on an experimental Steem build the scroll apparently works but delivers the traces I posted, showing shifts of 5, 1, -2, and -6 instead of the expected 5, 1, -3, -7.
...
I think there's a misunderstanding about the question.

Seems a big misunderstanding indeed. This is NOT Alien's 4-bit sync scroll. It is something completely different. It is a 4 pixel scroll taking advantage of Shifter destabilization.

[Steven Seagal]

Thx for interpreting the traces, ijor.
First mission of the year, count pixels!
I did on the following frames, the scroll is in fact precisely 4 pixels between each frame, there's no 3 pixel scroll between some frames like I thought:

stcnx1.png

stcnx2.png

stcnx3.png

stcnx4.png

stcnx5.png

The corresponding traces are similar to what I posted yesterday though:

Code: Select all

1
090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 026:R0009 033:RL100A 378:S0000 386:S0002 446:R200E 458:R000D 470:DE0502 477:RL200A 477:PX0000 512:#00E6

2
090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 030:RL000D 030:R0001 378:S0000 386:S0002 446:R2002 458:R0001 470:DE0602 473:RL300A 473:PX0000 512:#00E6

3
090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 030:RL000D 034:R0009 057:RL300A 378:S0000 386:S0002 446:R2006 458:R0005 470:DE0302 485:PX0000 512:#00E6

4
090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 022:R0001 037:RL200A 378:S0000 386:S0002 446:R200A 458:R0009 470:DE0302 481:PX0000 512:#00E6

5
090 - 002:R2004 010:DE1022 014:R1004 016:PX0001 026:R0009 033:RL100A 378:S0000 386:S0002 446:R200E 458:R000D 470:DE0502 477:RL200A 477:PX0000 512:#00E6

In summary (including DE, when the pixel clock starts, and # words in the Shifter at first reload):

Code: Select all

      R2   DE   R1   PX   R0    RL    words
1    002  010  014  016  026   033     1
2    002  010  014  016  030   030     0
3    002  010  014  016  034   030     0
4    002  010  014  016  022   037     2
5    002  010  014  016  026   033     1

Just raw info, it's not an explanation.

[ijor]

First mission of the year, count pixels!
I did on the following frames, the scroll is in fact precisely 4 pixels between each frame, there's no 3 pixel scroll between some frames like I thought:
...
In summary (including DE, when the pixel clock starts, and # words in the Shifter at first reload):

Hmm, not sure I understand. Are you still talking about the 4-bit scroll on Punish Your Machine? Again, we are talking about something completely different.

[Steven Seagal]

This is what runs the ST-Connexion 4bit scroll in the experimental build of Steem (the traces correspond to the frames). This emulation knows nothing about the technique, it doesn't try to emulate it, it just runs the video logic at the lowest level it can. Maybe 4bit scroll works differently from what we thought?

Meanwhile, I found a likely explanation for that lost pixel. The answer is in the traces but only I could know it because that's internal working of Steem.

Like the Shifter, the emulation runs at 32mhz.
In mode 2 (HIRES), it's easy, we run the process every tick, say 0-3.
But for modes 1 and 0, we must choose ticks. In Steem I chose tick 2 for mode 0 and ticks 1 and 2 for mode 1 (arbitrarily).
When RELOAD happens, we're at some definite tick. In one case, we're on tick 1, in the other on tick 2. In the first case, pixels will be output next tick, but in the other only when we reach tick 2 again, that is one 8mhz cycle later.

Code: Select all

clock tick effect
     
    RL   subcycle   subcycle&3   clock for r0  extra cycle   output start
1  033     A          2              2             1            034
2  030     D          1              2             0            030
3  030     D          1              2             0            030
4  037     A          2              2             1            038
5  033     A          2              2             1            034

If we use those values, we get the expected (and observed on screenshots) 4 pixel differences between frames.

Code: Select all

pixel shift

   R0   RL   real start  accelerated pixels  apparent start
              (R0 tick)        (R0-RL>0)
1  026 033       034               0              034
2  030 030       030               0              030
3  034 030       030               4              026
4  022 037       038               0              038
5  026 033       034               0              034 

[Steven Seagal]

There should be traces I posted long ago. They didn't include the end of the line though, only the start.

Must have missed them.

I'm not sure what you mean by multiples of 8MHz cycles. Do you mean the relation between each wakestate or the DE-to-LOAD delay? Or what?

DL latencies apparently are 3-6 cycles, or 12-24 32mhz ticks, precisely, not, say, 3.25 cycles for WS2.

It depends on the MMU version, but that doesn't matter too much. What matters is the raising edge, not the width of the pulse. The pulse width might have some relevance on the issue with Spectrum 512 phantom pixels. Other than that it shouldn't matter.

I probably misread you before, I thought the Shifter fetched data at the falling edge of LOAD.

[ijor]

DL latencies apparently are 3-6 cycles, or 12-24 32mhz ticks, precisely, not, say, 3.25 cycles for WS2.

I still don't see your point. Hardware is never that precise. Of course that is not N cycles exactly, and the instrument used to measure has its own limitations anyway. But why you do care? This is (mostly) a synchronous design. All that matters is if it is within this, or that cycle.

I probably misread you before, I thought the Shifter fetched data at the falling edge of LOAD.

It's at the raising edge, but note that it is a low active signal. Meaning that it is the end edge of the pulse. Or if you prefer, when the signal is deasserted.

"Fetch" is a bit ambiguous here, it is more accurate to say that it latches the data at the end of the pulse, the raising edge.

[troed]

My captures are going to be posted to this thread instead since they might capture things of interested to different projects, not just Shifter: http://atari-forum.com/viewtopic.php?f=15&t=32918

(IMP Shifters are on their way by post atm)

[Steven Seagal]

I still don't see your point. Hardware is never that precise. Of course that is not N cycles exactly, and the instrument used to measure has its own limitations anyway. But why you do care? This is (mostly) a synchronous design. All that matters is if it is within this, or that cycle.

Are you saying that the GLUE "M2CLOCK" can awake at an arbitrary 0-15 tick (~32mhz) on the STF relative to DCYC, and not always on the same n, n+4, n+8 or n+12 tick?

It's at the raising edge, but note that it is a low active signal. Meaning that it is the end edge of the pulse. Or if you prefer, when the signal is deasserted.

Right, but then it is important because of the possible interference between LOAD and RELOAD as you explained.

"Fetch" is a bit ambiguous here, it is more accurate to say that it latches the data at the end of the pulse, the raising edge.

Yes, "latch" is the word I was looking for