Sync-tricks/fullscreen discussion

[troed]

Hi all,

Over the years various threads on Atari-Forum have explored the intricate workings of the GLUE, Shifter and assorted partners in crime. Some of the threads have been aptly named, others haven't. Due to the collection of those findings into first a wiki page*, and more recently a talk at STNICCC 2015**, I thought it might be time to create a thread on point.

To start off the discussions, I'd like to post something that had me slightly confused for a while. Or possibly still has. I brought it up in a private discussions with Gunstick who came to the same conclusion as I did - but I think it would be interesting to hear more opinions. So:

Why is it possible to "open" the right border with a switch to high resolution?

The capability to cause the MMU to keep latching addresses and the Shifter to keep outputting pixels in the right border is due to making the GLUE forget to end the line. This is due to there being two checks, four cycles apart, for ending the line in 60Hz and 50Hz respectively:

cycle 372: IF FREQ==60 H=FALSE
cycle 376: IF FREQ==50 H=FALSE

... as you can see, it's obviously so that being in 50Hz up until cycle 375 but making sure we're in 60Hz at cycle 376 will cause H to stay TRUE and thus we have opened the right border. A 60Hz scanline is 508 cycles long and a 50Hz scanline is 512 cycles long so we're well within that.

A high resolution scanline is 224 cycles long.

Let that sink in for a bit. There's no reason whatsoever for the GLUE to care, at all, what happens with the resolution register past cycle 224 (or 184 actually, but I digress). So why does it - apparently - since it's fully possible to skip both of the checks above by RES being HI?

I suspect the answer must be something "in silicon", but I'm not a hardware expert. Does it make for a simpler GLUE statemachine if the inputs (FREQ, ff820a and RES, ff8260) are combined into a new composite value - which is the one then tested against? How does that rhyme with the speculated "RES checks are made one cycle later than FREQ" hypothesis which is the current best effort in explaining the wakestates?

/Troed

*) http://www.atari-wiki.com/index.php/ST_STE_Scanlines - freshly updated with the vertical statemachine
**) https://www.youtube.com/watch?v=F4WJYyoF1Lk

[AtariZoll]

Yes, this needs own thread - although I must grumble about fullscreen term - we can not achieve it - there will be some border on normal TVs and CRT monitors. On LCD possible, of course.

To know exactly those details about chips involved in ST(E) video generation best would be to get somehow their design. But that will hardly happen. Reverse engineering is almost impossible - at least when want to go so deep, and support wake states and other undocumented features, which were most likely not planned by designers at all. Maybe doing some X-ray microscope shots of chips ? All it is just idea. Most likely only way is to do lot of experimenting and then perform deductions about internal logic.

[ijor]

Hi Troed,

Let that sink in for a bit. There's no reason whatsoever for the GLUE to care, at all, what happens with the resolution register past cycle 224 (or 184 actually, but I digress). So why does it - apparently - since it's fully possible to skip both of the checks above by RES being HI?

Does it make for a simpler GLUE statemachine ...

Because GLUE doesn't actually have a state machine. The GLUE video logic is not sequenced. There are no states (except the counters, of course) that drive the decisions or tests.

Most (if not all) tests are performed every clock tick. But do note that there isn't just a single clock tick for the whole video logic. As I said recently in other thread, some horiz video logic is clocked by one edge of the clock, some by the opposite. Vertical logic clock is another story.

How does that rhyme with the speculated "RES checks are made one cycle later than FREQ" hypothesis which is the current best effort in explaining the wakestates?

I don't know what is that speculation. Are you talking about GLUE wakestates? They have nothing to do with that. They are much more fundamental. I think I described already, what the wake states exactly are, didn't I? Or again, do you mean SHIFTER wake states?

[troed]

Hi Ijor,

Please see the wiki link in the bottom of the first post. I haven't seen any posts from you describing how the wake state arise (and cause the effects they do) here on A-F Would love to get your insights.

(When you say the checks are made every tick I then assume you imply it checks the current cycle # as well? Again, that doesn't explain why a right border can be opened by going to hi resolution)

/Troed

[larsbrinkhoff]

Hello,

I'm writing a detailed software simulator of the GLUE-MMU-Shifter, so I'm watching this thread and the corresponding wiki page with great interest.

Thanks for all the great information so far!

[ijor]

Please see the wiki link in the bottom of the first post. I haven't seen any posts from you describing how the wake state arise (and cause the effects they do) here on A-F Would love to get your insights.

There should be a thread I started long ago about wake ups. Afaik that was the first formal description of wakeups, and I released there the very first wake up detection program (two wakeups only at that time). It is not updated with my latest research, but it should describe the basic concept.

Anyway, I'll write a small updated note, just about the cause of the wakeups. Will post it later today.

(When you say the checks are made every tick I then assume you imply it checks the current cycle # as well?

Yes, of course.

Again, that doesn't explain why a right border can be opened by going to hi resolution)

Ah, I think I see what you mean now. You mean why GLUE, at the right border on lower resolutions, doesn't check the current position and just the sync bit? Well, what you would gain like that? Nothing. Yes, of course, GLUE combines the registers and internally generates frequency signals (50Hz, 60Hz, 70Hz). It would be less efficient, and even less elegant, otherwise.

And even if it those frequency signals wouldn't have been combined, and each comparison would use both registers; I still would check the resolution at the right border. The gain by avoiding that would be so small, that I wouldn't consider it worth the risk.

In general, GLUE uses the frequency concept, it doesn't care too much about the actual resolution or color modes. The register model as seen by the programmer are just a consequence of different addressing for SHIFTER vs GLUE.

[troed]

Anyway, I'll write a small updated note, just about the cause of the wakeups. Will post it later today.

Thanks! The description I've made on the wiki is a "black box" deduction that explains both what's known and has managed to make successful predictions. It's not based on actual probing of the hardware though, which I believe you've indicated you have done. I have of course read yours and Paulo's old 2006 thread where wakeups were first documented, but I don't remember seeing anything about what caused them back then.

(When you say the checks are made every tick I then assume you imply it checks the current cycle # as well?
Yes, of course.

Ah ok, then we're in agreement. That's the "state" in my terminology.

Ah, I think I see what you mean now. You mean why GLUE, at the right border on lower resolutions, doesn't check the current position and just the sync bit? Well, what you would gain like that? Nothing. Yes, of course, GLUE combines the registers and internally generates frequency signals (50Hz, 60Hz, 70Hz). It would be less efficient, and even less elegant, otherwise.

I agree, it indeed makes sense that the registers are combined for GLUE's own usage. I'll have a look at the logic I've documented so far to see if it makes things easier. It makes one thing more difficult though, and that is why the 71Hz frequence "happens"/"is checked against" one cycle later, i.e (from the wiki):

Due to the internal workings of the GLUE, cause unknown, all state checks of the RES register are made one cycle later than FREQ. This is best described with an example using position 56 in the table above:

Offset 0 reads values at cycle 56 (FREQ) and 57 (RES)
Offset 1 reads values at cycle 57 (FREQ) and 58 (RES)
Offset 2 reads values at cycle 58 (FREQ) and 59 (RES)
Offset 3 reads values at cycle 59 (FREQ) and 60 (RES)

The above, as seen by a program running on the CPU, means that to be able to change the values of the registers for the GLUE to pick them up in the current wakestate they need to have been done at the following cycles:

WS1 (DL6): Changes made by 56 (FREQ), 56 (RES)
WS3 (DL5): Changes made by 56 (FREQ), 58 (RES)
WS4 (DL4): Changes made by 58 (FREQ), 58 (RES)
WS2 (DL3): Changes made by 58 (FREQ), 60 (RES)

I don't know if it would make sense, in hardware logic, for the GLUE to pick up the resolution register one cycle later than the frequency when making it's combined signal?

/Troed

[troed]

... and on that note, I've put the wakestate detection code I used in Closure up on Github. It crafts a single scanline that results in different line lengths for STE, WS1, WS2, WS3 and WS4. Feel free to use in your own demo code of course: https://github.com/troed/WSDETECT

The code as is can be compiled either for .PRG or bootsector use. The latter since I must've power cycled my poor STs a few thousand times over the last few years and the quicker I can get the current wakestate printed to screen the better

/Troed

[calimero]

... and on that note, I've put the wakestate detection code I used in Closure up on Github. It crafts a single scanline that results in different line lengths for STE, WS1, WS2, WS3 and WS4. Feel free to use in your own demo code of course: https://github.com/troed/WSDETECT

The code as is can be compiled either for .PRG or bootsector use. The latter since I must've power cycled my poor STs a few thousand times over the last few years and the quicker I can get the current wakestate printed to screen the better

/Troed

so now you can detect purely in software in what "state" ST wake up?

[ijor]

Ah ok, then we're in agreement. That's the "state" in my terminology.

Well, we are back to semantics, jaja. But I wouldn't consider this a machine state.

Due to the internal workings of the GLUE, cause unknown, all state checks of the RES register are made one cycle later than FREQ.
...
I don't know if it would make sense, in hardware logic, for the GLUE to pick up the resolution register one cycle later than the frequency when making it's combined signal?

I would need to double check it. But I do think that yes, GLUE latches the resolution register later. I don't think this has anything to do with combining the signal. It is done before the combination. I don't know for sure the exact reason, and again, I would need to double check it.

[ijor]

Quick (wording and phrasing probably should be improved) write-up about the cause of GLUE-MMU wakeups on the ST.

The wakeups are a consequence of the phasing between two different processes. One in GLUE, the other one in MMU.
The process in GLUE controls the video logic and signals. The process in MMU arbitrates DRAM access. This in turns determines the exact timing of the LOAD signal going to SHIFTER, and the generation of wait states when the CPU attempts to access RAM.

Each one of these chips has a two bits counter that clocks its respective process. The counters are not affected by hardware reset. This is by design because the processes are not completely stopped during Reset. The counters then are initialized at power up time only.

There is no board level power up logic. Each chip implements its own power up detection. Power up timing is not fully deterministic and partially random. Depending on environmental and voltage factors, power up logic will end, and then let the counters run free, at a different cycle.

The end result is that the two counters, and then the processes, are not aligned. Even when they are synchronized by the same master clock, the relation between the values of each counter will vary across power up cycles.

[troed]

so now you can detect purely in software in what "state" ST wake up?

Ijor and Paulo has been able to do that since 2006 (2 wakeup modes) and 2012 (four) already. My code builds on that research and is just an example of the current state of the art. If you want to do "modern" sync tricks (12 line combo sync scroller using 3/4 scanlines etc) you absolutely need to know which wakestate you're in and modify your "switches" accordingly.

In addition to CPU(MMU)-GLUE wakestates there are a few more involving (I speculate) offsets between GLUE/Shifter and MMU/Shifter. These I have so far had no luck being able to detect in software. (Spectrum 512 "black dots" is an example of such a state).

But I do think that yes, GLUE latches the resolution register later. I don't think this has anything to do with combining the signal. It is done before the combination.

Ok, well, as long as it means any changes to resolution by a program running on the CPU is "detected" a cycle later by the GLUE than a change to the frequency register is then the model documented on the wiki holds Luckily, since it so far seems to accurately describe the effect of the wake states.

The wakeups are a consequence of the phasing between two different processes. One in GLUE, the other one in MMU.

Thanks for the writeup. It's slightly different from the 0-3 cycles difference between GLUE and CPU that the model on the wiki is built from, but it might be that it in the end becomes the same thing due to the MMU arbitrating the CPU.

/Troed

[ijor]

Ok, well, as long as it means any changes to resolution by a program running on the CPU is "detected" a cycle later by the GLUE than a change to the frequency register is then the model documented on the wiki holds

I checked. It's actually the opposite. The writes to the FREQ register are the ones that are latched later by GLUE. Or if you want, the same thing, GLUE snoops writes to the REZ register earlier.

And this is consistent with your table. You have to write to FREQ earlier to compensate for the GLUE internal delay. If you write to FREQ at the same time as REZ, GLUE would see the change too late.

To be more precise it's not one cycle, but one and a half cycle. GLUE latches the resolution register at the start of the CPU strobe. But it latches the freq/sync register bits at the end of the strobe.

Thanks for the writeup. It's slightly different from the 0-3 cycles difference between GLUE and CPU that the model on the wiki is built from, but it might be that it in the end becomes the same thing due to the MMU arbitrating the CPU.

It is the same thing. Or perhaps more accurately, as I said in the other thread the CPU shift is a side effect. The 0-3 cycles difference are between GLUE and MMU, and they reflect the relation between both counters I described. MMU gets the CPU aligned with its own timing whenever it attempts a RAM (or SHIFTER) access. And this is because RAM access can only happen at the cycle slots allocated by the given MMU DRAM process.

[ijor]

I have of course read yours and Paulo's old 2006 thread where wakeups were first documented, but I don't remember seeing anything about what caused them back then.

I checked the thread you point in the wiki. No, that's not the thread I was talking about. There is an earlier (much shorter) thread, where I described wakeups and released a wake up test code:

http://www.atari-forum.com/viewtopic.ph ... eup#p69958

The long thread you mention was more about wakeup aware code (plus some other things as predicting sync interrupt jitter), than about a formal description of wakeups. This is a much more interesting thread, I agree, but the initial wakeup reference was done earlier in the other thread.

[Steven Seagal]

Yes, this needs own thread - although I must grumble about fullscreen term - we can not achieve it - there will be some border on normal TVs and CRT monitors. On LCD possible, of course.

For the right border, display stops at HBLANK.
For the bottom border, display stops at VBLANK.
Left border, maybe 2 pixels (DE at 6, HBLANK off at 32, picture at 6+28=34)? [edit: in "emulator cycles"]
Top border, yes, there's still some border.

[Steven Seagal]

Hello,

I'm writing a detailed software simulator of the GLUE-MMU-Shifter, so I'm watching this thread and the corresponding wiki page with great interest.

Thanks for all the great information so far!

Welcome to the forum.
Hmm, new competitor in emulation soon?

[Steven Seagal]

For what it's worth, in its tests for GLU/Shifter tricks, Steem SSE first checks bit 1 of shift mode, and only if it's 0, it checks bit 1 of sync mode. Of course, timing of those mode changes is the one that matters for the GLUE, not when the actual register is updated. This means that there's no "rounding up to 4" for sync and shift mode changes (right?).

We could have a combined variable Glue.Frequency that would take values 50, 60, 72 according to shift mode and sync mode at the precise cycle, and that would actually be better emulation?

[larsbrinkhoff]

Hmm, new competitor in emulation soon?

Not really. It's more of a fun toy. We're not focused on emulation performance, but simple code and working towards cycle-accurate simulation of most components.

https://github.com/nocrew/ostis

[ijor]

... Of course, timing of those mode changes is the one that matters for the GLUE, not when the actual register is updated. This means that there's no "rounding up to 4" for sync and shift mode changes (right?).

First of all, access to the SYNC register is not aligned (rounded) AT ALL because it is only in GLUE. Round up to 4 happens only when accessing the RAM data bus. Access to REZ (shift) register is aligned because it goes to SHIFTER as well. But yes, GLUE gets the new value without waiting for the rounding up

We could have a combined variable Glue.Frequency that would take values 50, 60, 72 according to shift mode and sync mode at the precise cycle, and that would actually be better emulation?

I don’t think this matter at all for the purpose of better emulation. What does matter is to consider the different timing between writes to SYNC and writes to REZ.

For what it's worth, in its tests for GLU/Shifter tricks, Steem SSE first checks bit 1 of shift mode, and only if it's 0, it checks bit 1 of sync mode.

Btw, for perfect accuracy you should check first bit 0 of SYNC! But I’m not completely sure what would happen in real hardware when you set this bit that enables external sync. If this makes the sync signals to float (nobody will drive them and I don't see on board pull-ups), then GLUE might misbehave, and then you probably don’t care to emulate it. It might depend on a monitor being connected (because it might have pull-ups) or on the presence of a modulator. If the signals do not float for some reason, then the behavior will be stable and it should be emulated for perfect accuracy.

[Cyprian]

Access to REZ (shift) register is aligned because it goes to SHIFTER as well. But yes, GLUE gets the new value without waiting for the rounding up

by "rounding up to 4" we understand process when GLUE inserts wait states when CPU tries to access RAM/Hardware.
Therefore in case of access REZ (shift) register, how GLUE can "gets the new value without waiting for the rounding up", when in the same time it inserts wait states for the CPU?

[Steven Seagal]

I don’t think this matter at all for the purpose of better emulation. What does matter is to consider the different timing between writes to SYNC and writes to REZ.

Not the result, but the inside concepts.

Btw, for perfect accuracy you should check first bit 0 of SYNC! But I’m not completely sure what would happen in real hardware when you set this bit that enables external sync. If this makes the sync signals to float (nobody will drive them and I don't see on board pull-ups), then GLUE might misbehave, and then you probably don’t care to emulate it. It might depend on a monitor being connected (because it might have pull-ups) or on the presence of a modulator. If the signals do not float for some reason, then the behavior will be stable and it should be emulated for perfect accuracy.

Why isn't it common knowledge yet? Nobody tried that?
Just did on my STE + CRT monitor in devpac, instant black display, reset necessary... yes, this should be emulated.

[Steven Seagal]

by "rounding up to 4" we understand process when GLUE inserts wait states when CPU tries to access RAM/Hardware.
Therefore in case of access REZ (shift) register, how GLUE can "gets the new value without waiting for the rounding up", when in the same time it inserts wait states for the CPU?

Plz check this old schema:

http://www.atari-forum.com/viewtopic.ph ... 86#p286152

GLUE latches a bit, then sends the value to the Shifter through the MMU, which could add wait states.
Just thinking now, If you read the register, it will be rounded (not in current version of Steem SSE AFAIK, a TODO for me).

[npomarede]

I don’t think this matter at all for the purpose of better emulation. What does matter is to consider the different timing between writes to SYNC and writes to REZ.

Not the result, but the inside concepts.

For the inside work, I don't see how we could know if sync and res are combined into a signal internally into glue or if they're checked one after the other. We can speculate about the pro/cons of merging both values or testing them one after the other, but unless someone could get a microscope shot of the chip and interpret it, it will be hard to tell.
As Ijor wrote, what matter is that for any input value of res/sync we get the correct output value and the "formula" that was used, but the glue remains a black box and unless its inner work has visible outside effect we can't know how the logic was implemented.

Btw, for perfect accuracy you should check first bit 0 of SYNC! But I’m not completely sure what would happen in real hardware when you set this bit that enables external sync. If this makes the sync signals to float (nobody will drive them and I don't see on board pull-ups), then GLUE might misbehave, and then you probably don’t care to emulate it. It might depend on a monitor being connected (because it might have pull-ups) or on the presence of a modulator. If the signals do not float for some reason, then the behavior will be stable and it should be emulated for perfect accuracy.

Why isn't it common knowledge yet? Nobody tried that?
Just did on my STE + CRT monitor in devpac, instant black display, reset necessary... yes, this should be emulated.

Any demo code certainly experimented crash / bad video when setting bit 0 by mistake. I remember trying it in the 90's, expecting that it could give some kind of vertical hardscroll or similar by carefully setting bit to 1/0, but it mostly gave unstable picture. Results certainly depended on STF vs STE and the kind of CRT monitor.
I don't think it was ever used in any demo or allowed special tricks, so that's certainly why nobody cared to do more research on it as it has no usage in games/demos.

Nicolas

[tin]

Any demo code certainly experimented crash / bad video when setting bit 0 by mistake. I remember trying it in the 90's, expecting that it could give some kind of vertical hardscroll or similar by carefully setting bit to 1/0, but it mostly gave unstable picture. Results certainly depended on STF vs STE and the kind of CRT monitor.
I don't think it was ever used in any demo or allowed special tricks, so that's certainly why nobody cared to do more research on it as it has no usage in games/demos.

I did use external sync for sync scrolling back in the days. Unfortunately it wasn't only depending on the monitor, but even on the SCART cable A one line sync scroller was done this way - but after sending a screen using this around we quickly realized that it worked almost nowhere and there was no way to get it stable (except via hardware mods). So we scrapped it.
I guess I was lucky that my cable/monitor combinated allowed me to discover this.

[troed]

I checked the thread you point in the wiki. No, that's not the thread I was talking about. There is an earlier (much shorter) thread, where I described wakeups and released a wake up test code:

Thanks. I must've read that thread at some point because at STNICCC 2015 I commented to Gunstick that one of his screens failed in one wakeup, but I see now that I misremembered and it was one of Leonard's.

However, while I'm positive you're correct in that the MMU and CPU can occupy one or the other of two possible 2-cycle slots respectively, which indeed is the original wakestate hypothesis - and one I think Steven has implemented in Steem SSE - it actually isn't what I have deduced from my black box reverse engineering. Of course, my hypothesis could be false, but the original only allows for two wakestates and we know that there are four.

Since both ff820a and ff8260 are visible directly to GLUE, at least I don't think the MMU inserts any wakestates if they're modified by the CPU before GLUE sees them, all four wakestates are explained by 0-3 cycle offsets between the GLUE and CPU (the table from the wiki I cited above).

For the record, of the three STFs I have here I've experienced the following:

1) 1040 STF - always boots in WS3 when cold, always prefers WS1 when warm. It can reach WS2 and WS4 as well at any point in time if I try many times, but most easily they're found "in between" cold and warm.

2) 1040 STF - always boots in WS1 when cold, always prefers WS3 when warm. It can reach WS2 and WS4 as well at any point in time if I try many times, but most easily they're found "in between" cold and warm.

3) Mega ST (8.01MHz) - almost exclusively boots in WS2 when cold. Can reach all other wakestates as well. Really really prefers WS2.

... and maybe something unexpected: One of the 1040s above (haven't tried the same with the others yet) _always_ - and I mean always - boots in WS3 if a mono monitor is connected.

/Troed