ST Chipset decap

[ijor]

...but what's the role of the pxCtrLoad signal?

I simplified the schematics a bit, hoping that more people would understand the logic. You can see that the counter logic has a dotted box titled "Detail 1", because a lower level detail would be included in the final and full version of the schematics.

Entering expert mode, for Stefan and others that might understand ...

The mux that selects between incrementing or reinitializing the counter receives both the positive (counter Enable) and the inverted (counter load) signals. Normally I don't include those signals in the schematics, say, as the inverted clock that reaches the fllip-flops, because it is useless. But here it has some, remote, relevance ...

The DFF that generates the signals in this case, it is some sort of combination of a DFF and an RS async latch, rather unusual. If both async signals are asserted at the same, both outputs are asserted. In that case the mux would OR both inputs. But the async reset is asserted only during hardware reset. So it doesn't really matters too much.

Leaving expert mode

[larsbrinkhoff]

what's the role of the pxCtrLoad signal?

I'm guessing that's the signal to copy the contents of the IR registers to RR.

EDIT: Nope, guess not.

[larsbrinkhoff]

Basically the logic outputs a one cycle (at the pixel clock) pulse, every 16 pixels, but only if four LOADs have been performed since the last reload. In theory this should be one pulse every 16 CPU cycles.

How does this work in medium and high resolutions? Is this pixel clock always 8 MHz, regardless of the resolution?

[ijor]

I'm guessing that's the signal to copy the contents of the IR registers to RR.
EDIT: Nope, guess not.

This is triggered by the Reload signal. The one with the outgoing arrow at the bottom right.

Basically the logic outputs a one cycle (at the pixel clock) pulse, every 16 pixels, but only if four LOADs have been performed since the last reload. In theory this should be one pulse every 16 CPU cycles.

How does this work in medium and high resolutions? Is this pixel clock always 8 MHz, regardless of the resolution?

No. The pixel clock it's 16 Mhz at medium and 32 Mhz at high. But I guess I might have been a bit misleading in that quoted sentence. A more accurate wording might be:

The logic outputs one clockpixel cycle pulse after four LOAD pulses since the previous Reload, at the next 16 pixels boundary.

It might be helpful to look at the waveforms I posted previously.

[stefanberndtsson]

The DFF that generates the signals in this case, it is some sort of combination of a DFF and an RS async latch, rather unusual. If both async signals are asserted at the same, both outputs are asserted. In that case the mux would OR both inputs. But the async reset is asserted only during hardware reset. So it doesn't really matters too much.

Definitely an interesting piece, although, as you say, not very relevant. Combining sync and async stuff can lead to non-obvious results though. Maybe there are more useful hidden features elsewhere.

Leaving expert mode

Thanks for entering it. From an HDL perspective, this seems fairly simple so far.

[larsbrinkhoff]

The logic outputs one clockpixel cycle pulse after four LOAD pulses since the previous Reload, at the next 16 pixels boundary.

Thank you. I'm a bit outside my domain with this hardware stuff, but it's becoming more clear.

It might be helpful to look at the waveforms I posted previously.

Yes, those do help. Another one that shows the when DE first goes active would be great. If I may be so bold.

One remark: In your waveforms, a LOAD pulse is one 8MHz clock cycle wide. When I look at Dio's waveforms below, I'm eyeballing LOAD to be about two cycles wide. Is that correct, and would a longer LOAD affect anything in your waveform diagrams?

http://www.atari-forum.com/viewtopic.ph ... 63#p238041

[larsbrinkhoff]

EDIT: goofed.

[stefanberndtsson]

No. The pixel clock it's 16 Mhz at medium and 32 Mhz at high.

It would be reasonable to assume that the internal 16MHz (and 8MHz) are directly derived from the 32MHz clock, and to be mostly in phase with each other, right (i.e. just divided down)?

With the waveforms in http://atari-forum.com/viewtopic.php?f= ... 76#p292990 there is quite some offset present, but those are going through a fair few other bits of logic as well, I guess.

[ijor]

Yes, those do help. Another one that shows the when DE first goes active would be great. If I may be so bold.

Here you go ...

ReloadCtrl-Low-Start.jpg

ReloadCtrl-Low-End.jpg

One remark: In your waveforms, a LOAD pulse is one 8MHz clock cycle wide. When I look at Dio's waveforms below, I'm eyeballing LOAD to be about two cycles wide. Is that correct, and would a longer LOAD affect anything in your waveform diagrams? http://www.atari-forum.com/viewtopic.ph ... 63#p238041

LOAD pulse is one cycle, and they look to me one cycle wide on Dio's traces. Anyway, the width of the pulse is not very important. What matters is the ending edge.

[ijor]

It would be reasonable to assume that the internal 16MHz (and 8MHz) are directly derived from the 32MHz clock, and to be mostly in phase with each other, right (i.e. just divided down)?

That's correct. I expect to post the clock logic soon.

With the waveforms in http://atari-forum.com/viewtopic.php?f= ... 76#p292990 there is quite some offset present, but those are going through a fair few other bits of logic as well, I guess.

That's not a simulation waveform, but an actual trace from the external signals. The external 8 Mhz is created by MMU, by dividing the 16 MHz one, and it has no direct relation with Shifter's internal one. So most of the clock offset here comes from the additional division.

[larsbrinkhoff]

Here you go ...

LOAD pulse is one cycle, and they look to me one cycle wide on Dio's traces.

Thank you, kind sir!

You're right about LOAD, I'll have to adjust my eyeballs.

[ijor]

Definitely an interesting piece, although, as you say, not very relevant. Combining sync and async stuff can lead to non-obvious results though.

The chipset is plenty of async logic. But this is case is indeed quite unusual. As you say, the same input is sync in one polarity, but async in the other.

But, oh, well, this is old school logic design. The main design rule was to save as much transistors as possible. LOL. They made things that we'll never do in a modern design.

There were probably other constrains. SHIFTER, at high rez at least, works at 32 MHz. That was pretty fast back then. Some things they probably couldn't afford, not only because the additional transistor cost, but because otherwise they wouldn't meet timing at 32 MHz.

The clock skew we talked about is also relevant. Consider the DE signal. It is registered by the 2 MHz clock in GLUE. That's yet another clock division. May be that's also a reason why they deal with DE completely asynchronously.

[npomarede]

Hi
speaking about transistors, did you count how many of them there was in the glue and the shifter ? (not that it has any practical use, just to get a rough idea of what it represents compared to the 68000)

[ijor]

speaking about transistors, did you count how many of them there was in the glue and the shifter ? (not that it has any practical use, just to get a rough idea of what it represents compared to the 68000)

They are tiny in comparison to the 68K. The technology is different, comparing the number of transistors would probably be misleading. But it would be equivalent to an order of 5,000 transistors. That's less than a tenth the 68K!

[larsbrinkhoff]

I have implemented the reload logic in software. It's a bit of a mess, but it seems to work.

[ijor]

Shift Array Matrix:

ShiftArrayLogic.jpg

ShiftArrayDetail.jpg

Note that the buffer and shift registers (IR and RR registers in Alien model) are physically not separated. The array is constructed with bit cells containing two flip flops (bit registers) one for the shift and another for the buffer register.

This is just a physical organization. Logically it is equivalent to having IR and RR registers completely separated.

Also the Buffer Registers (IR registers in Alien model) are logically organized as 16 4-bit shift registers. They shift vertically in the diagram, from top to bottom.

[ijor]

I forgot to explain the monoColor signal ..,

SHIFTER has a second copy of bit 0 of the first palette register, the color selection for monochrome mode. Both registers are updated together when this palette register is written by the CPU. So logically they normally behave as a single register.

[ijor]

Shifter Re Stabilizing itself:

ReStabilize.png

The attached waveform shows how Shifter can re stabilize itself. A start of a new scanline is captured. Previous line left two words loaded in the buffer (IR) registers. After two new LOAD pulses, at the vertical cursor position, Shifter had the buffer registers fully loaded and was ready to reload the shift (RR) registers. But Shifter won't trigger a reload until the pixel counter overwraps marking that 16 pixels were shifted and the RR registers are empty. In this case this won't happen until two more LOAD pulses.

So what makes Shifter to reStabilize itself is the value of the pixel counter at the moment that the first LOAD pulse on the line arrives. This in turn depends on the switches at the previous line(s). If the value of the counter is low enough, as in this case, it won't overwrap until four LOADs, producing a ReStabilization.

[Steven Seagal]

Shifter Re Stabilizing itself:

The attached waveform shows how Shifter can re stabilize itself. A start of a new scanline is captured. Previous line left two words loaded in the buffer (IR) registers. After two new LOAD pulses, at the vertical cursor position, Shifter had the buffer registers fully loaded and was ready to reload the shift (RR) registers. But Shifter won't trigger a reload until the pixel counter overwraps marking that 16 pixels were shifted and the RR registers are empty. In this case this won't happen until two more LOAD pulses.

So what makes Shifter to reStabilize itself is the value of the pixel counter at the moment that the first LOAD pulse on the line arrives. This in turn depends on the switches at the previous line(s). If the value of the counter is low enough, as in this case, it won't overwrap until four LOADs, producing a ReStabilization.

Thx again for all those efforts, this will save us many raving speculations.

I was wondering if this restabilising could explain why a 'right border off' trick (line +44) wasn't unstable by itself, like in the Amiga demo?
While a spurious line +2 shifts the rest of the frame, even the next frame, like World of Music by New Power Generation on a STE
(http://www.atari-forum.com/viewtopic.ph ... 25#p289647).

[ijor]

I was wondering if this restabilising could explain why a 'right border off' trick (line +44) wasn't unstable by itself, like in the Amiga demo?

Yes, same principle. The pixel counter stays aligned.

While a spurious line +2 shifts the rest of the frame ...

Because it changes the point where the pixel counter starts. It would start four cycles earlier. So pixel counter becomes misaligned without a stabilizer.

..., even the next frame

Because once the pixel counter was moved four cycles earlier, it would stay like that. Shifter will never reset it (it would never detect end of line). But it would keep the same alignment. This is a consequence of the length of the scan line being 512 cycles, a multiple of 16 (which is the value that pixel counter overwraps).

This is the idea behind Paulo's, non full screen, 8-bit hard sync.

[Steven Seagal]

This is the idea behind Paolo's, non full screen, 8-bit hard sync.

4bit?


I checked the pictures again, all are fine except ShiftArrayDetail.jpg that is a bit fuzzy.

[npomarede]

I checked the pictures again, all are fine except ShiftArrayDetail.jpg that is a bit fuzzy.

Yes it's true that even when saving the jpg file and viewing/zooming it it's hard to read, some lines/colums are missing, as if the image was downsized too much or jpg compressed the small text too much
Maybe png would be better suited for these image (lots of white space, should compress correctly)

[ijor]

Seems to be a problem with the forum software. Just tried uploading a PNG file and it's the same thing. The forum software doesn't keep my original files. I get a smaller file size when I download them back.

The schematics pics inside a zip file:

ShifterSchemWip.zip

[alien]

My 4 bit hardscroll had a weird feature: it was offset by k+4n pixels versus the normal beginning of a line (n = 0, 4, 8, 12). Because k wasn't 0, (but small, although I don't remember the value), one couldn't transition from high to low at the beginning of each line when n=0 (corresponding to not shifting the screen right as in normal overscan). Instead one had to always transition from high to medium to low at the beginning of each line for every value of n. If you have time and interest, Ijor, I'd be curious why that is.

Thanks!

[troed]

My 4 bit hardscroll had a weird feature: it was offset by k+4n pixels versus the normal beginning of a line (n = 0, 4, 8, 12). Because k wasn't 0, (but small, although I don't remember the value)

k == 1 IIRC

/Troed