ST Chipset decap

[Steven Seagal]

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]

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.

[Steven Seagal]

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]

... 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.

[Steven Seagal]

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.

[Steven Seagal]

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).

[ijor]

- 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.

[Steven Seagal]

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]

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.

[Steven Seagal]

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.

[Smonson]

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]

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.

[Steven Seagal]

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]

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.

[Steven Seagal]

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.

[Smonson]

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!

[Smonson]

Where does pixCtrLoad go?

[ijor]

Where does pixCtrLoad go?

You can ignore it. See my elaboration in this message: http://atari-forum.com/viewtopic.php?f= ... 25#p293030

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

[ijor]

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

http://atari-forum.com/viewtopic.php?f= ... 47#p333724

[ijor]

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.

[Smonson]

Thanks Ijor!

[Steven Seagal]

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]

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.

[Steven Seagal]

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?

[Steven Seagal]

Below are simulation waveforms for the above circuit (SHIFTER Reload Control). Showing both correct and incorrect behavior in all three resolutions.

...

Note that in all the three resolutions, the incorrect behavior produces Reload pulses 16 pixels later than it should. But the effect is different in each resolution.

The last one, the buggy behavior at med rez, AFAIK, is theoretic at this time, nobody actually tried to provoke it.

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.
The med rez one is harder to obtain, must trick it more, otherwise there's just a shift at the start of scanlines. I've never seen it on hardware (so not sure it's right).

LOW:

steem_vl_bandsL-min.png

MED:

steem_vl_bandsM-min.png

HI:

steem_vl_bandsH-min.png