Sync-tricks/fullscreen discussion

[troed]

I will appreciate if somebody takes the time to answer the questions:

I'll try

- What's exactly the behavior? It's every other 16 pixels are displayed at background color?

In low res, yes. In high res it's every fifth word. I haven't seen it in medium, but I haven't tried to provoke it either.

- It has some relation to the GLUE-MMU wakestates? It happens in all of them?

It can happen in all of them, but it's possible the wakestate has some influence sometimes.

- I thought the issue happens only when implementing Spectrum 512 effects. But I see it's not the case. That is another different Shifter wakeup issue?

Yes. I believe Spectrum 512 pixels to be a mismatch between external signals to the Shifter (Load, CS) and it's internal pixel/shift-clock. Or rather, Dio proposed that a few years ago and I agree

- It happens only when opening the borders?

Some sort of manipulation needs to take place, but it doesn't need to be border opening. It's enough to try to do the non-fullscreen 4-pixel sync scroll (Paulo's) and it will happen sometimes.

- Does it really have wakeup behavior? Which means that is not affected by hardware reset. Only by power cycling.

In some of the cases it seems to be reset-persistent, but it's also something affected by warming. If you watch my STNICCC 2015 presentation I show some examples at the end where it seems to be affected by the memory address (!) read as well.

I don't understand why a FIFO model would explain the effect. If the problem is indeed that sometimes RR is not reloaded with IR, then it is probably a failure in, precisely, the RR reload logic. That should be the same regardless of IR being a FIFO or not. Or I am missing something?

In low res, where it's "every 16", there could be many simpler explanations, yes. However, for the same explanation to work in high res the behavior must be different. Of course, I'm basing this on Alien's explanation on how IR and RR work - other setups could also explain it.

If IR (four words) get filled, and then transferred to RR (four words) in low res, RR is then shifted out one pixel at a time (all registers together) and when they're empty IR should've been filled with four new words. If the copy from IR to RR fails, the next 16 pixels will be all zeros and IR fills up with four new words.

In high resolution, four words are read into IR, and one word at a time is shifted out from RR. When all RR words are empty a copy from IR is attempted, and if it fails only one word is shifted out as all zeros until the next attempt is made. Now, if IR wasn't a FIFO the next copy could not be made with graphics at the correct location for the next four words.

I hope the above makes sense. On the top of my head it would probably be possible to explain it with IR only being used as four words in low res, two in medium and one word in high (and then the same for RR). However, I don't know if that would then match up with all other known Shifter behavior (basically, how "stabilizers" manage to clear the registers).

Btw, do we know what happens exactly when both bits of the REZ registers are set?
I am pretty sure GLUE doesn't care, it mostly ignores REZ bit 0. But I'm unsure what SHIFTER does. What happens with the mono display?

This I don't know at all.

/Troed

[ijor]

In high res it's every fifth word

So it's four words correct, one word black, four words correct, one word black ... ?
How you provoke it at high res?

Thank you for all your answers on this issue

Of course, I'm basing this on Alien's explanation on how IR and RR work - other setups could also explain it.
...
In high resolution, four words are read into IR, and one word at a time is shifted out from RR.
...
I hope the above makes sense.

If I understand what you mean (which I am not completely sure), then I think you are misunderstanding Alien's model. Or, if you don't misunderstand Alien's model, then Alien model is wrong. Hope what I am saying, makes any sense, LOL.

Anyway, IR load and RR reload is not affected by the resolution. It's always the same. In all resolutions, all the four RR registers are reloaded from IR at the same time.

[joska]

In high res it's every fifth word

So it's four words correct, one word black, four words correct, one word black ... ?
How you provoke it at high res?

This happens "all the time" on my STE. Usually after a reset.

[troed]

So it's four words correct, one word black, four words correct, one word black ... ?
How you provoke it at high res?

Exactly. Switching between hi/low at various points while LOADing can result in that state persisting afterwards.

If I understand what you mean (which I am not completely sure), then I think you are misunderstanding Alien's model. Or, if you don't misunderstand Alien's model, then Alien model is wrong. Hope what I am saying, makes any sense, LOL.

Anyway, IR load and RR reload is not affected by the resolution. It's always the same. In all resolutions, all the four RR registers are reloaded from IR at the same time.

Good, then I haven't misunderstood That's the model I base my FIFO hypothesis on. If a transfer of IR to RR fails, a new one is attempted 4 cycles (16 mono pixels) later - and succeeds. But since all the graphics displayed is in the correct position the word that wasn't displayed must now have been removed from IR and a new word must have been added.

The other option would be to explore that maybe it isn't IR->RR that fails, but a single word read from screen memory, but while that sounds plausible in mono it cannot be the explanation for low res where it's four words that all fail. The same would then apply to why it "cannot" be a single word that fails in the IR->RR transfer, in low res it's again always all four.

This happens "all the time" on my STE. Usually after a reset.

That's extremely interesting, I don't think that's a normal case. Are there any modifications at all made to your machine? Anything that might affect Shifter timings?

/Troed

[joska]

This happens "all the time" on my STE. Usually after a reset.

That's extremely interesting, I don't think that's a normal case. Are there any modifications at all made to your machine? Anything that might affect Shifter timings?

I do have a 16MHz accelerator in that machine, but I don't think that should affect shifter/glue/mmu timings. Or maybe it does? When I see this problem I have to reset a few times to get rid of it. A power cycle is not necessary. I also see another "bug" occasionally after a reset, the display is shifted one word to the right and the rightmost column is wrapped around to the left border.

I'll try to remember to take some pictures the next time I see this.

[ijor]

Exactly. Switching between hi/low at various points while LOADing can result in that state persisting afterwards.

Sorry to insist, but can you be more specific? It persists a few more cycles/words, a few scans, the whole frame?

While LOADing I guess you mean while displaying? You can't really write to SHIFTER while LOAD is active. MMU will not let you. It's one or the other.

Good, then I haven't misunderstood That's the model I base my FIFO hypothesis on. If a transfer of IR to RR fails, a new one is attempted 4 cycles (16 mono pixels) later - and succeeds.

Transfer from IR to RR is always each 16 cycles (when working correctly, at least), disregarding the resolution. Or you mean that an extra transfer is triggered at the wrong timing ?

But since all the graphics displayed is in the correct position the word that wasn't displayed must now have been removed from IR and a new word must have been added.

IR loading doesn't depend on RR reload. IR loading is triggered by LOAD.

The other option would be to explore that maybe it isn't IR->RR that fails

I don't think it is exactly a failed transfer, but more probably a missed transfer. The logic that controls RR reload is quite complex. I am suspecting it is getting confused for some reason. Not completely sure if the mono and color versions have exactly the same origin.

[troed]

Exactly. Switching between hi/low at various points while LOADing can result in that state persisting afterwards.

Sorry to insist, but can you be more specific? It persists a few more cycles/words, a few scans, the whole frame?

Yes.



It can persist for half a scanline. Or a few times over a complete VBL (see the videos from my STNICCC talk) - seemingly correlated with memory adress displayed, or seemingly rock-solid over the whole frame exactly the same every VBL with the same code that after a restart will work fine. Or, for that matter, code that works fine when a machine is "cold" will start showing issues while warming and after a while end up with exactly every-other-banded.

This video shows one of the things I've seen while researching the effect. I'm not changing anything here, it's exactly the same code (and screen address) every VBL and at exactly the same cycles: https://dl.dropboxusercontent.com/u/669647/bands.mp4

While LOADing I guess you mean while displaying? You can't really write to SHIFTER while LOAD is active. MMU will not let you. It's one or the other.

Of course.

Good, then I haven't misunderstood That's the model I base my FIFO hypothesis on. If a transfer of IR to RR fails, a new one is attempted 4 cycles (16 mono pixels) later - and succeeds.

Transfer from IR to RR is always each 16 cycles (when working correctly, at least), disregarding the resolution. Or you mean that an extra transfer is triggered at the wrong timing ?

Since only one word (4 cycles) is black in mono a new transfer must've happened 4 cycles later than the one that didn't happen. My thinking is that a check to see if a transfer should happen is made every 4 cycles, but it normally only triggers every 16 (four words read). Whether the check is triggered by LOAD or by internal Shifter timing could be the whole reason why it sometimes fails.

But since all the graphics displayed is in the correct position the word that wasn't displayed must now have been removed from IR and a new word must have been added.

IR loading doesn't depend on RR reload. IR loading is triggered by LOAD.

Yes, but if it wasn't a FIFO the graphics would end up at the wrong place.

I don't think it is exactly a failed transfer, but more probably a missed transfer. The logic that controls RR reload is quite complex. I am suspecting it is getting confused for some reason. Not completely sure if the mono and color versions have exactly the same origin.

I guess mono and color could be due to different causes, but I have no reason to believe it is. Occam's Razor would apply.

/Troed

[ijor]

Or, for that matter, code that works fine when a machine is "cold" will start showing issues while warming and after a while end up with exactly every-other-banded.

Aha. But then it's not strictly a wake up issue, even when it might happen in certain wake states only. It seems more a synchronization failure (not so surprising, I will try to elaborate at a later post) with non deterministic behavior.

My thinking is that a check to see if a transfer should happen is made every 4 cycles, but it normally only triggers every 16 (four words read).

More or less, yes. The IR => RR transfer logic seems to synchronize pixel shifting with four LOADs, and also uses DE as part of the synchronization. And in a way that looks much more complicated than it should ...

Seems they designed SHIFTER taking in mind a more complicated and advanced MMU (because the logic seems to not depend on the exact timing of LOAD). And/or they faced some GLUE-MMU wakestates issues (because, the logic doesn't assume a fixed DE to LOAD delay).

There is no actual cycle counter. SHIFTER doesn't have the concept of cycles. The pixel clock (which obviously depends on the current resolutions) is the internal clock. And clock muxing, which is a very delicate operation, is done in a very rudimentary way. Any resolution change could have all sort of strange effects, even clock glitches. But I wouldn't expect this kind of effects to persists for too long.

Yes, but if it wasn't a FIFO the graphics would end up at the wrong place.

Ok. I think I understand what you mean. I was thinking in something else when you say FIFO.

The IR registers are organized logically as 16 4-bit shift registers. Each LOAD produces one shift. That's what you mean by a FIFO?

I guess mono and color could be due to different causes, but I have no reason to believe it is.

Well, what both have in common, is that the transfer is produced 16 pixels later (or at least, that's one possible way to look at what happens). But the pixel clock is different, and the pixel clock is the actual clock of that logic ...

[larsbrinkhoff]

The IR => RR transfer logic seems to synchronize pixel shifting with four LOADs, and also uses DE as part of the synchronization.

How is DE involved in in the synchronization?

[ijor]

How is DE involved in in the synchronization?

DE is used to detect the borders and to reset the RR reload control logic. That part of the logic seems quite complicated, probably the most complicated piece of logic inside SHIFTER. But, it seems to me that it won't perform the reset (correctly) in every case. Hence the need of stabilizers.

I'm writing a small WIP of what I see so far in the SHIFTER layout.

[alien]

Another hypothesis would be that the counters are not initialized at powerup, and therefore can be in one of 4 states ... I'm curious whether you have evidence for either hypothesis.

Hi Alien,

That was mi initial hypothesis as well. Mainly because I HAD NO IDEA that those chips implement power-up logic.

GLUE does reset the flops at power-up, I can confirm 100%.

Cool, thanks!

[ijor]

Another hypothesis would be that the counters are not initialized at powerup, and therefore can be in one of 4 states ... I'm curious whether you have evidence for either hypothesis.

To be more precise. There is logic, (that seems to be) power-up logic, that initializes those flip flops. I can't be 100% sure that the logic actually works. It's not a textbook design, and it is not something you normally see on those chips. If it doesn't work, then those flip flops would never be initialized at all.

It doesn't change too much the effect. Initialized by power-up logic (that works always or only sometimes), or not initialized at all and coming up with a non deterministic value, end result would be about the same.

[troed]

So one of my todos for quite some time has been to explain the "mono fullscreen" demo, which I for the moment don't have a link to. It supposedly has a scroller in the left and right borders in mono, and additionally sync scrolls a picture up & down.

* The sync scroll is done by varying numbers of 0-byte lines (no DE by going to LO at cycle 0, back to HI at at the top
* The right border is opened by going to LO covering cycle 164, then back to HI. This of course does mean that the pixels around that switch become black
* The left border is not opened. There's no earlier line starting position than 4 (regular mono line). The demo does however go to LO at cycle 12 and then back to HI, which means the Shifter becomes preloaded and does start to display pixels earlier (no line length change).

It seems the demo during the initial manual calibration phase (which I don't understand the purpose of) tries to open the lower border, in the same way I've tried now for quite some time during a few evenings. Neither the demo nor myself succeeds though, and I don't really understand why. I find no good explanation as to why it isn't possible, naïvely I would expect there to be a cycle X (likely between 164 and 184) where IF(71) V=FALSE on line 434, but I cannot find one.

/Troed

[Steven Seagal]

There's preliminary support for this demo in Steem. Black pixels not emulated.
The "right off" effect is considered a "line +14".
It would be great if you could post a pic or vid.

[ijor]

It seems the demo during the initial manual calibration phase (which I don't understand the purpose of) tries to open the lower border, in the same way I've tried now for quite some time during a few evenings. Neither the demo nor myself succeeds though, and I don't really understand why. I find no good explanation as to why it isn't possible, naïvely I would expect there to be a cycle X (likely between 164 and 184) where IF(71) V=FALSE on line 434, but I cannot find one.

Why between 164 and 168? If I'm not mistaken, it's 14 cycles before opening the left border. Should be analog cycle to the one you open top and bottom borders at color. So according to your numbering convention should be cycle 214 (224+4-14).

The problem is that it's the same cycle that HSYNC ends. So contrary to color, you need accuracy or you would badly alter sync, HSYNC would not end. And if you alter sync like that, not only that the display might be wrong, the border would not open. It would not open, because the horizontal counter depends on HSYNC.

Now, I'm not sure, but it is possible that you might need single cycle accuracy to switch to color without altering sync!

[ijor]

It seems the demo during the initial manual calibration phase (which I don't understand the purpose of) tries to open the lower border, in the same way I've tried now for quite some time during a few evenings. Neither the demo nor myself succeeds though, and I don't really understand why. I find no good explanation as to why it isn't possible, naïvely I would expect there to be a cycle X (likely between 164 and 184) where IF(71) V=FALSE on line 434, but I cannot find one.

Checked a little more. Still not 100%, and certainly untested, but ...

I think it's simply not possible. The cycle is the one I mentioned, or around it. But you will either alter sync this scan, or the other. At about the same cycle, GLUE checks REZ for ending HSYNC, clearing vDE, and to reinitialize the horiz sync counter with the correct value. And they are related one with the other. So alterting sync might mean that the border didn't actually open.

At color it is possible to open the vertical borders because HSYNC doesn't depend on 50 Hz vs 60 Hz.

[joska]

This happens "all the time" on my STE. Usually after a reset.

That's extremely interesting, I don't think that's a normal case. Are there any modifications at all made to your machine? Anything that might affect Shifter timings?

Some screenshots (photos, actually).




Please note that the rightmost 16 pixels are not correctly displayed, but wrapped around to the left border. This can also happen after a reset without the "every fifth word black" problem.



Detail from the left border.

If I press the reset-button a few times this will happen. Press reset again and it's usually OK again.

I have a 16MHz accelerator in this machine. It might have an effect on this. I didn't use this STE much before I got the accelerator (just for the odd gaming session, never with a mono screen) so I can't say if it happened before I fitted the accelerator.

[alanh]

Also, I mentioned to troed offline but the "Closure" demo doesn't work on the MegaSTE.

I wonder if we're hitting new wakestates on this machine that haven't been determined before ??

[alanh]

This is what I occasionally get on one of my stock STE's with the Closure demo too.

No changes at all to this hardware.

IMG_1370.JPG

IMG_1369.JPG

[troed]

Also, I mentioned to troed offline but the "Closure" demo doesn't work on the MegaSTE.

I wonder if we're hitting new wakestates on this machine that haven't been determined before ??

The issue you described on your Mega STE (failure to load, or even corrupt content loaded by the TOS routine from boot sector) is most certainly unrelated to wakestates. I have no idea what could cause it and I'm still trying to purchase a Mega STE of my own ..

The other issue you see with an STE sometimes (banded screen) can happen, yes. It's quite uncommon on STE (at least every other and on all scanlines) but very common in one sub-Shifter state in ST in wakestate 2. I have a Mega ST that can get into it easily. I have a code path that works in that state (but not others) but no way to detect/select in software which to use when

/Troed

[troed]

I think it's simply not possible. The cycle is the one I mentioned, or around it. But you will either alter sync this scan, or the other. At about the same cycle, GLUE checks REZ for ending HSYNC, clearing vDE, and to reinitialize the horiz sync counter with the correct value. And they are related one with the other. So alterting sync might mean that the border didn't actually open.

At color it is possible to open the vertical borders because HSYNC doesn't depend on 50 Hz vs 60 Hz.

Thanks Ijor, I believe I've exhausted all 2-cycle boundary and 4-cycle width switches possible to do, at least on an STE, without succeeding. I will do the same on STF as well before concluding that it isn't possible.

/Troed

[ijor]

Thanks Ijor, I believe I've exhausted all 2-cycle boundary and 4-cycle width switches possible to do, at least on an STE, without succeeding. I will do the same on STF as well before concluding that it isn't possible.

Conceivable, and due to the ST wakestates giving single cycle accuracy (not on the same wakestate though), it might work, but I really doubt it.

The main problem here is not really the width of the switch, how soon you switch back to mono. But the exact point of the first switch, the switch to color. And if I'm correct, there is no position to perform the switch to open the border without altering sync.

[alanh]

Also, I mentioned to troed offline but the "Closure" demo doesn't work on the MegaSTE.

I wonder if we're hitting new wakestates on this machine that haven't been determined before ??

The issue you described on your Mega STE (failure to load, or even corrupt content loaded by the TOS routine from boot sector) is most certainly unrelated to wakestates. I have no idea what could cause it and I'm still trying to purchase a Mega STE of my own ..

To clarify here, the MegaSTE works flawlessly.

When loading Closure, it gets the STNICC initial message and continues to load the next phase. At the point it's meant to start the demo, there are three scenarios.

1. One orange bomb appears on black background and the screen flickers.
2. Four grey bombs appear on the black background.
3. Black screen and nothing is happening.

[troed]

I've spent some time with the GLUE statemachine for ST/STE not only in 50Hz but also 60Hz (and 71Hz, but I still need to wrap my head around a few things there). I've thus updated them a bit, both with the knowledge on how things are different in a 508 cycle line, but also with the confirmation from Ijor on how the GLUE latches FREQ later than RES and uses a combined value for its comparisons.

Also, the "just blank" lines first used by Paulo and by me as well in Closure now have an explanation.

http://www.atari-wiki.com/index.php/ST_STE_Scanlines

/Troed

[larsbrinkhoff]

I've spent some time with the GLUE statemachine for ST/STE not only in 50Hz but also 60Hz (and 71Hz, but I still need to wrap my head around a few things there).

Thanks, I think that's a good improvement.

Regarding 71... is there a LINE = 224 too?