ST Chipset decap

GFA, ASM, STOS, ...

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

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

Re: ST Chipset decap

Postby Steven Seagal » Tue Sep 26, 2017 6:24 pm

ijor wrote:Yes, the IR registers (as named in the Alien model) can be described as a kind of SHIFT array or FIFO. The FIFO/SHIFT is clocked by a LOAD pulse coming from MMU. No matter what, a LOAD pulse would push one word and discard the last one on the FIFO (the last word in the FIFO is the one that entered first).


Thx, it makes sense. If the new word was blocked instead, we would have very different effects.


It is not a real life example. I just simulated that DE is misaligned so that two words remained from the previous scan.

There are many situations that can lead to the pixel counter not stopping. The logic stops the counter when a Reload happens after DE was deasserted. That would normally be after the last LOAD coming from MMU. The pixel counter can't be stopped before the actual Reload because the Reload logic depends on it.

But if DE is misaligned as in the example you mention, a Reload won't happen at the end of the line after DE is deasserted. That's actually why two words remain in the IR buffers. Without the last Reload the pixel counter won't stop.


I was afraid the 2 words shift wasn't caused by the 'right off' trick.

I have two other questions if you please:

1. Are IR and RR always the same registers with a copy IR->RR every 16 cycles, or are those register functions swapped at reload (like a toggle, sending new words to the other registers while the current one is being shifted - don't know if I'm being clear :)) ? If the former, does copying IR to RR take time?

2. Do the RR always rotate, or only when the pixel counter is enabled?

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

Re: ST Chipset decap

Postby ijor » Tue Sep 26, 2017 8:54 pm

Steven Seagal wrote:I was afraid the 2 words shift wasn't caused by the 'right off' trick.


Well, any shifter trick (overscan, sync, etc) that leaves two words, or just any words, in the shifter would have the same effect.

1. Are IR and RR always the same registers with a copy IR->RR every 16 cycles, or are those register functions swapped at reload (like a toggle, sending new words to the other registers while the current one is being shifted - don't know if I'm being clear :)) ?


There is no toggle. IR registers are always IR, and RR reigsters are always RR. Did you check the schematics? Even if you are not familiar with schematics and can't understand everything, it should still help.

If the former, does copying IR to RR take time?


Not sure that question makes much sense hardware wise. There are all sort of delays and pipelines in hardware, that's why the simulation waveforms are very useful. Are you asking if there is a delay since the fourth LOAD?

2. Do the RR always rotate, or only when the pixel counter is enabled?


Always at every pixel clock, either they shift or they are reloaded from the IR registers. In theory it's possible to stop the pixel clock, but I didn't try or check the exact behavior en real hardware.

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

Re: ST Chipset decap

Postby Steven Seagal » Tue Sep 26, 2017 9:29 pm

ijor wrote:Well, any shifter trick (overscan, sync, etc) that leaves two words, or just any words, in the shifter would have the same effect.


Yes, maybe I wasn't clear: afraid that it wasn't the case for 'right off', because some words would have never been loaded or whatever. (This is what I thought before.)

There is no toggle. IR registers are always IR, and RR reigsters are always RR. Did you check the schematics? Even if you are not familiar with schematics and can't understand everything, it should still help.


Right. Thx for clarifying. I checked the schematics in this thread but obviously didn't understand everything.

Not sure that question makes much sense hardware wise. There are all sort of delays and pipelines in hardware, that's why the simulation waveforms are very useful. Are you asking if there is a delay since the fourth LOAD?


No, I've seen that there is such delay (2 pixel clocks?) apparently, but I was wondering if a short copy delay could be visible on the screen, marking each raster, in monochrome for example.

Always at every pixel clock, either they shift or they are reloaded from the IR registers. In theory it's possible to stop the pixel clock, but I didn't try or check the exact behavior en real hardware.


Thx. I'll have more questions later I'm afraid, also about the MMU. :)

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

Re: ST Chipset decap

Postby ijor » Wed Sep 27, 2017 1:46 am

Steven Seagal wrote: ... but I was wondering if a short copy delay could be visible on the screen, marking each raster, in monochrome for example.


There is nothing like that.

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

Re: ST Chipset decap

Postby Steven Seagal » Thu Sep 28, 2017 9:32 am

As an excuse, I had kept a fuzzy version of the shift array pic (my mistake). Sorry if I ask what you already explained.
Now I examined the correct schematic. If I get it right, just rephrasing:
- The shift array you described is complete. There are 4 rows of 16 cells, not double that.
- Each cell contains two bits, a bit that comes from Din and is pushed "down" the cells, and a bit that comes from ShIn and is shifted through ShOut.
- There's no real transfer IR->RR as between separate registers.
- On RELOAD, the data bit is moved to the "shift" part of the cell right after current bit has been shifted. There's no more delay than if it came from ShIn. That is, there's no delay.
- Each cell can perform LOAD and shift at the same time, moving the new data "down" and the old data "right" according to the LOAD signal and the pixel clock.

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

Re: ST Chipset decap

Postby Steven Seagal » Thu Sep 28, 2017 9:43 am

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



I compared this to Dio's equivalent trace (50hz_video clock DE to load to screen latencies).
One may conclude that the RGB output changes exactly 4 cycles after RELOAD (so after 5 LOADs in Dio's trace).
:shrug:

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

Re: ST Chipset decap

Postby ijor » Thu Sep 28, 2017 11:36 am

Steven Seagal wrote:- The shift array you described is complete. There are 4 rows of 16 cells, not double that.
- Each cell contains two bits, a bit that comes from Din and is pushed "down" the cells, and a bit that comes from ShIn and is shifted through ShOut.
- There's no real transfer IR->RR as between separate registers.


This is just how the physical organization is implemented. Imagine you would build this array on a breadboard using discrete transistors. You would find out it is better like this because the cabling is much simpler.

For the logical point of view (and that is what you really care), you can still consider as they are separate. There is still, of course, a transfer between the registers. Just that the transfers happens inside a cell (which again, it is a purely a physical issue).

- On RELOAD, the data bit is moved to the "shift" part of the cell right after current bit has been shifted. There's no more delay than if it came from ShIn. That is, there's no delay.


Not exactly, not right after but instead. If RELOAD is off, then the RR bit receives a bit from the Shin, a shift is being performed. If it off, then it receives a bit from IR. It's one or the other.

- Each cell can perform LOAD and shift at the same time, moving the new data "down" and the old data "right" according to the LOAD signal and the pixel clock.


Not really. It could but it wouldn't work correctly because each flip-flop, each bit, on a cell is clocked by a different clock. The IR flops are clocked by the LOAD pulse, the RR ones by the pixel clock. And both clocks aren't fully synchronous. If you would try to perform both transfers at the same time the result would be unpredictable, sometimes would work, others would not. That's the whole purpose of the pixel counter and the complicated RELOAD logic. The idea is to make sure that both transfers are separated by enough cycles.

One may conclude that the RGB output changes exactly 4 cycles after RELOAD


That depends on the Shifter wakeup. And you shouldn't care at all anyway because there is no feedback from the RGB pins to anything else inside the computer. For your purpose if doesn't matter if it's 4 or 40.

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

Re: ST Chipset decap

Postby Steven Seagal » Thu Sep 28, 2017 12:18 pm

ijor wrote:This is just how the physical organization is implemented. Imagine you would build this array on a breadboard using discrete transistors. You would find out it is better like this because the cabling is much simpler.

For the logical point of view (and that is what you really care), you can still consider as they are separate. There is still, of course, a transfer between the registers. Just that the transfers happens inside a cell (which again, it is a purely a physical issue).


Oh yes, the physical implementation would be more complicated to imitate, for emulation separate registers are fine. For the moment, they're not emulated anyway :)


- On RELOAD, the data bit is moved to the "shift" part of the cell right after current bit has been shifted. There's no more delay than if it came from ShIn. That is, there's no delay.


Not exactly, not right after but instead. If RELOAD is off, then the RR bit receives a bit from the Shin, a shift is being performed. If it off, then it receives a bit from IR. It's one or the other.


But sill the flow of pixels is uninterrupted, so during RELOAD, bits are shifted too? That's what I mean by 'right after'.
The current bit is shifted out and it is replaced with either a shifted in bit or a reloaded bit.


- Each cell can perform LOAD and shift at the same time, moving the new data "down" and the old data "right" according to the LOAD signal and the pixel clock.


Not really. It could but it wouldn't work correctly because each flip-flop, each bit, on a cell is clocked by a different clock. The IR flops are clocked by the LOAD pulse, the RR ones by the pixel clock. And both clocks aren't fully synchronous. If you would try to perform both transfers at the same time the result would be unpredictable, sometimes would work, others would not. That's the whole purpose of the pixel counter and the complicated RELOAD logic. The idea is to make sure that both transfers are separated by enough cycles.


I think I expressed myself horribly. :) I was trying to say that the LOAD (not RELOAD) and shifting processes are "independent" as if it were separate registers, each following its own clock.

One may conclude that the RGB output changes exactly 4 cycles after RELOAD


That depends on the Shifter wakeup. And you shouldn't care at all anyway because there is no feedback from the RGB pins to anything else inside the computer. For your purpose if doesn't matter if it's 4 or 40.


It's the timing of palette look-up, important in emulation. This is where a 1 cycle difference produces dots in Spectrum pics.
This looks like a big latency.

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

Re: ST Chipset decap

Postby ijor » Thu Sep 28, 2017 1:25 pm

Steven Seagal wrote:But sill the flow of pixels is uninterrupted, so during RELOAD, bits are shifted too? That's what I mean by 'right after'.
The current bit is shifted out and it is replaced with either a shifted in bit or a reloaded bit.


During reload no shifting occurs inside the shift array. Of course, the shift registers still output bits at their far end and the external (to the shift array) flow is not interrupted. You might consider that the array still shift out bits during RELOAD, if you want. But the internal cells don't shift.

I was trying to say that the LOAD (not RELOAD) and shifting processes are "independent" as if it were separate registers, each following its own clock.


That is correct.

One may conclude that the RGB output changes exactly 4 cycles after RELOAD


That depends on the Shifter wakeup. And you shouldn't care at all anyway because there is no feedback from the RGB pins...


It's the timing of palette look-up, important in emulation. This is where a 1 cycle difference produces dots in Spectrum pics.
This looks like a big latency.


Palette look-up and RGB output are two different things. RGB output is, obviously, after palette lookup. I don't see how you could conclude that palette lookup is after 4 cycles. I didn't post yet any simulation that shows that stage. And that is again, shifter wakeup dependent.

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

Re: ST Chipset decap

Postby Steven Seagal » Thu Sep 28, 2017 1:52 pm

ijor wrote:During reload no shifting occurs inside the shift array. Of course, the shift registers still output bits at their far end and the external (to the shift array) flow is not interrupted. You might consider that the array still shift out bits during RELOAD, if you want. But the internal cells don't shift.


OK. And in fact, if they did, the shifted out bit wouldn't be shifted in by the next cell, since it is taking the input bit.
Only the final bits are shifted.

Palette look-up and RGB output are two different things. RGB output is, obviously, after palette lookup. I don't see how you could conclude that palette lookup is after 4 cycles. I didn't post yet any simulation that shows that stage. And that is again, shifter wakeup dependent.


Guess it would just fit with some parameters in Steem. ;) But I have an open mind.

User avatar
Smonson
Atari freak
Atari freak
Posts: 61
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: ST Chipset decap

Postby Smonson » Thu Nov 30, 2017 10:14 am

Thankyou Ijor for this incredible work.

I apologise if this is a silly question, but what is nReset connected to on an STFM shifter which has no hardware reset? Always high, right? Otherwise the LOAD shift register will constantly be cleared.

I'm attempting to understand the reload logic but it's a little over my head.

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

Re: ST Chipset decap

Postby ijor » Thu Nov 30, 2017 12:23 pm

Smonson wrote:I apologise if this is a silly question, but what is nReset connected to on an STFM shifter which has no hardware reset?


Both SHIFTER and MMU do have hardware reset even when lacking a dedicated reset pin. They internally generate a reset when the external signals are at a specific invalid condition that would be produced only at reset. In the case of SHIFTER, it resets when both LOAD and CS are asserted.

I'm attempting to understand the reload logic but it's a little over my head.


It might be easier to follow the simulation waveforms.

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

Re: ST Chipset decap

Postby Steven Seagal » Thu Nov 30, 2017 3:48 pm

Steven Seagal wrote:
Not sure that question makes much sense hardware wise. There are all sort of delays and pipelines in hardware, that's why the simulation waveforms are very useful. Are you asking if there is a delay since the fourth LOAD?


No, I've seen that there is such delay (2 pixel clocks?) apparently, but I was wondering if a short copy delay could be visible on the screen, marking each raster, in monochrome for example.


About the delay between "first LOAD after DE" and "pixel counter starts running" we see on the simulations, I was wondering if it was a delay of about 2 CPU cycles, or 2 pixel clocks, which would be shorter in time units at higher resolution?

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

Re: ST Chipset decap

Postby ijor » Thu Nov 30, 2017 4:48 pm

Steven Seagal wrote:About the delay between "first LOAD after DE" and "pixel counter starts running" we see on the simulations, I was wondering if it was a delay of about 2 CPU cycles, or 2 pixel clocks, which would be shorter in time units at higher resolution?


It is pixel clocks. In the simulation I posted it's one cycle and a half. But that really depends on the SHIFTER wakeup.

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

Re: ST Chipset decap

Postby Steven Seagal » Thu Nov 30, 2017 5:27 pm

ijor wrote:It is pixel clocks. In the simulation I posted it's one cycle and a half. But that really depends on the SHIFTER wakeup.


Argh! That's bad news, as the Shifter can run at 32 mhz (4 times our reference cycles in emulation).
The Shifter emulation should run at 64mhz if we use an integer counter.

User avatar
Smonson
Atari freak
Atari freak
Posts: 61
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: ST Chipset decap

Postby Smonson » Fri Dec 01, 2017 12:23 pm

ijor wrote:Both SHIFTER and MMU do have hardware reset even when lacking a dedicated reset pin. They internally generate a reset when the external signals are at a specific invalid condition that would be produced only at reset. In the case of SHIFTER, it resets when both LOAD and CS are asserted.


Excellent, thanks! :D

User avatar
Smonson
Atari freak
Atari freak
Posts: 61
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: ST Chipset decap

Postby Smonson » Wed Dec 06, 2017 11:08 pm

Where does pixCtrLoad go?

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

Re: ST Chipset decap

Postby ijor » Thu Dec 07, 2017 12:45 am

Smonson wrote:Where does pixCtrLoad go?


You can ignore it. See my elaboration in this message: viewtopic.php?f=16&t=29658&start=25#p293030

Edit: Feel free to ask if you would like more details.

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

Re: ST Chipset decap

Postby ijor » Fri Dec 08, 2017 1:43 pm

I moved all the posts related to reimplementing SHIFTER on a modern FPGA to a new topic:

viewtopic.php?f=16&t=32747#p333724

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

Re: ST Chipset decap

Postby ijor » Sat Dec 09, 2017 4:56 am

SHIFTER clock generator:

ShifterClockGen.jpg


The top circuit is supposed to generate a power up signal (nPor). It is a clever and tricky circuit with the clock and reset connected with the roles inverted (clock as reset and reset as clock). But I don't think it works always. Not big deal if it doesn't, except that it might produce different wake up states.

Note that the clock mux doesn't output ANYTHING AT ALL if both bits of the rez registers are set. No clock would be generated and almost all Shifter processes would freeze until setting a valid resolution.
You do not have the required permissions to view the files attached to this post.

User avatar
Smonson
Atari freak
Atari freak
Posts: 61
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: ST Chipset decap

Postby Smonson » Sat Dec 09, 2017 7:58 am

Thanks Ijor!

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

Re: ST Chipset decap

Postby Steven Seagal » Fri Dec 15, 2017 9:58 pm

ijor wrote:SHIFTER clock generator:


Thx. Still some trouble reading schematics. I suppose the rightmost gate is a (N)OR and the 3 left of it are (N)ANDs?

Note that the clock mux doesn't output ANYTHING AT ALL if both bits of the rez registers are set. No clock would be generated and almost all Shifter processes would freeze until setting a valid resolution.


The World is my Oyster screen #2 uses '3' to remove the left border. For the Glue, it's equivalent to 2. At this point, what the Shifter outputs or not doesn't matter. One wonders why bit 0 can't be set, they could have spared a line.

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

Re: ST Chipset decap

Postby ijor » Sat Dec 16, 2017 12:28 am

Steven Seagal wrote:Thx. Still some trouble reading schematics. I suppose the rightmost gate is a (N)OR and the 3 left of it are (N)ANDs?


They are all NANDs, no NOR here. The inversions are probably confusing you. But logically it does behave like 3 ANDs and an OR.

The World is my Oyster screen #2 uses '3' to remove the left border. For the Glue, it's equivalent to 2. At this point, what the Shifter outputs or not doesn't matter.


Interesting. It doesn't matter too much if Shifter outputs anything or not, it might still be relevant because the pixel counter is affected. It uses a standard stabilizer?

One wonders why bit 0 can't be set, they could have spared a line.


Note sure I get what you mean. Bit 0 of what can't be set? Bit 0 of the rez register can obviously be set.

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

Re: ST Chipset decap

Postby Steven Seagal » Sat Dec 16, 2017 7:19 am

ijor wrote:The inversions are probably confusing you.


Always! And there are a lot on schematics.

It doesn't matter too much if Shifter outputs anything or not, it might still be relevant because the pixel counter is affected. It uses a standard stabilizer?


It uses a med res stabilizer, but not always.
[R res S sync T tricks]

Code: Select all

-63 - 000:R=0000 000:S=0002
-30 - 444:S0000 520:S0002 512:T0100
-29 - 444:R0001 456:R0000 512:T2000
-28 - 004:R0003 016:R0000 444:R0001 456:R0000 512:T2001
-27 - 004:R0003 016:R0000 444:R0001 456:R0000 512:T2001
-26 - 004:R0003 016:R0000 444:R0001 456:R0000 512:T2001
-25 - 004:R0003 016:R0000 376:S0000 384:S0002 512:T0011
-24 - 376:S0000 384:S0002 512:T0010
183 - 440:S0000 520:S0002
199 - 456:S0000 512:T0200
200 - 024:S0002


Code: Select all

-63 - 000:R=0000 000:S=0002
-30 - 444:S0000 520:S0002 512:T0100
-29 - 372:S0000 380:S0002 512:T0008
-28 - 372:S0000 380:S0002 512:T0008
-27 - 376:S0000 384:S0002 512:T0010
-26 - 376:S0000 384:S0002 512:T0010
-25 - 376:S0000 384:S0002 444:R0001 456:R0000 512:T2010
-24 - 004:R0003 016:R0000 376:S0000 384:S0002 444:R0001 456:R0000 512:T2011
-23 - 004:R0003 016:R0000 512:T0001
183 - 460:S0000
184 - 028:S0002
199 - 460:S0000 512:T0200
200 - 028:S0002


EDIT: Apparently you're right, it makes a difference.

Note sure I get what you mean. Bit 0 of what can't be set? Bit 0 of the rez register can obviously be set.


I mean why is rez0 even tested on the top gate? Aren't clk_H and rez1 enough?
Last edited by Steven Seagal on Sat Dec 16, 2017 8:01 am, edited 1 time in total.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: Grabulosaure and 1 guest