ST Chipset decap

GFA, ASM, STOS, ...

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

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 » 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: 3023
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: 1891
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: 3023
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: 1891
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: 1891
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: 3023
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: 1891
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: 3023
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: 1891
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.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 4 guests

cron