Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
troed wrote: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 ...
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 wrote: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-FWould 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)
ijor wrote:
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.
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.
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)
troed wrote:... 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
troed wrote:Ah ok, then we're in agreement. That's the "state" in my terminology.
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?
calimero wrote:so now you can detect purely in software in what "state" ST wake up?
ijor wrote: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.
ijor wrote:The wakeups are a consequence of the phasing between two different processes. One in GLUE, the other one in MMU.
troed wrote: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
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 wrote: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.
AtariZoll wrote: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.
larsbrinkhoff wrote: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!
Steven Seagal wrote:Hmm, new competitor in emulation soon?
Steven Seagal wrote: ... 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?
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.
ijor wrote: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
ijor wrote: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.
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 wrote: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 wrote:ijor wrote: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.
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.
ijor wrote: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:
Users browsing this forum: No registered users and 4 guests