ST Chipset decap

GFA, ASM, STOS, ...

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

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

Re: ST Chipset decap

Postby ijor » Wed Apr 06, 2016 9:18 pm

stefanberndtsson wrote:...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 :)

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

Re: ST Chipset decap

Postby larsbrinkhoff » Thu Apr 07, 2016 10:18 am

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

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

Re: ST Chipset decap

Postby larsbrinkhoff » Thu Apr 07, 2016 11:51 am

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

Re: ST Chipset decap

Postby ijor » Thu Apr 07, 2016 1:01 pm

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

ijor wrote: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
Atarian
Atarian
Posts: 4
Joined: Wed Mar 23, 2016 10:48 am

Re: ST Chipset decap

Postby stefanberndtsson » Thu Apr 07, 2016 6:46 pm

ijor wrote: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. :)

ijor wrote:Leaving expert mode :)


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

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

Re: ST Chipset decap

Postby larsbrinkhoff » Thu Apr 07, 2016 6:52 pm

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

ijor wrote: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?

viewtopic.php?f=16&t=24855&start=363#p238041
Last edited by larsbrinkhoff on Thu Apr 07, 2016 6:54 pm, edited 2 times in total.

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

Re: ST Chipset decap

Postby larsbrinkhoff » Thu Apr 07, 2016 6:52 pm

EDIT: goofed.

stefanberndtsson
Atarian
Atarian
Posts: 4
Joined: Wed Mar 23, 2016 10:48 am

Re: ST Chipset decap

Postby stefanberndtsson » Thu Apr 07, 2016 7:11 pm

ijor wrote: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=16&t=29608&p=292976#p292990 there is quite some offset present, but those are going through a fair few other bits of logic as well, I guess.

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

Re: ST Chipset decap

Postby ijor » Fri Apr 08, 2016 1:10 am

larsbrinkhoff wrote: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? viewtopic.php?f=16&t=24855&start=363#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.
You do not have the required permissions to view the files attached to this post.

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

Re: ST Chipset decap

Postby ijor » Fri Apr 08, 2016 1:16 am

stefanberndtsson wrote: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=16&t=29608&p=292976#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.

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

Re: ST Chipset decap

Postby larsbrinkhoff » Fri Apr 08, 2016 11:22 am

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

Re: ST Chipset decap

Postby ijor » Fri Apr 08, 2016 6:35 pm

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

User avatar
npomarede
Atari God
Atari God
Posts: 1129
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Fri Apr 08, 2016 6:49 pm

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

Re: ST Chipset decap

Postby ijor » Sat Apr 09, 2016 4:20 am

npomarede wrote: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!

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

Re: ST Chipset decap

Postby larsbrinkhoff » Fri Apr 15, 2016 5:08 am

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

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

Re: ST Chipset decap

Postby ijor » Sat Apr 23, 2016 2:49 am

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

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

Re: ST Chipset decap

Postby ijor » Sat Apr 23, 2016 12:53 pm

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

Re: ST Chipset decap

Postby ijor » Thu Apr 28, 2016 3:30 am

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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1891
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: ST Chipset decap

Postby Steven Seagal » Thu May 05, 2016 7:14 am

ijor wrote: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.php?f=94&t=28886&start=25#p289647).

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

Re: ST Chipset decap

Postby ijor » Thu May 05, 2016 9:16 pm

Steven Seagal wrote: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.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1891
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: ST Chipset decap

Postby Steven Seagal » Fri May 06, 2016 7:24 am

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

User avatar
npomarede
Atari God
Atari God
Posts: 1129
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Fri May 06, 2016 7:56 am

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

Re: ST Chipset decap

Postby ijor » Fri May 06, 2016 11:15 am

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

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Fri May 06, 2016 10:02 pm

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!
Alien / ST-Connexion

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

Re: ST Chipset decap

Postby troed » Sat May 07, 2016 2:23 pm

alien wrote: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


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests