Sync-tricks/fullscreen discussion

GFA, ASM, STOS, ...

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

User avatar
troed
Atari God
Atari God
Posts: 1182
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Sync-tricks/fullscreen discussion

Postby troed » Thu Mar 17, 2016 1:29 am

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby AtariZoll » Thu Mar 17, 2016 9:04 am

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.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

ijor
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Fri Mar 18, 2016 1:23 pm

Hi Troed,

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


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?

User avatar
troed
Atari God
Atari God
Posts: 1182
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Postby troed » Fri Mar 18, 2016 7:58 pm

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

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby larsbrinkhoff » Sat Mar 19, 2016 7:13 am

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
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Sat Mar 19, 2016 3:28 pm

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

User avatar
troed
Atari God
Atari God
Posts: 1182
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Postby troed » Sat Mar 19, 2016 3:47 pm

ijor wrote:
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

User avatar
troed
Atari God
Atari God
Posts: 1182
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Postby troed » Sat Mar 19, 2016 4:06 pm

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

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2034
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Sync-tricks/fullscreen discussion

Postby calimero » Sat Mar 19, 2016 7:31 pm

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

so now you can detect purely in software in what "state" ST wake up?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

ijor
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Sat Mar 19, 2016 7:32 pm

troed wrote: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
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Sat Mar 19, 2016 7:37 pm

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.

User avatar
troed
Atari God
Atari God
Posts: 1182
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Postby troed » Sat Mar 19, 2016 11:04 pm

calimero wrote: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).

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.


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.

ijor wrote: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
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Sun Mar 20, 2016 1:03 am

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


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
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Sun Mar 20, 2016 3:00 am

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.


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:

viewtopic.php?f=68&t=9056&hilit=wakeup#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.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1897
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 10:07 am

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.


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.
Last edited by Steven Seagal on Sun Mar 20, 2016 10:14 am, edited 1 time in total.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1897
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 10:10 am

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!


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

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1897
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 10:23 am

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?

User avatar
larsbrinkhoff
Atariator
Atariator
Posts: 25
Joined: Fri Mar 18, 2016 3:03 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby larsbrinkhoff » Sun Mar 20, 2016 11:08 am

Steven Seagal wrote: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
Last edited by larsbrinkhoff on Thu Mar 24, 2016 8:48 pm, edited 1 time in total.

ijor
Hardware Guru
Hardware Guru
Posts: 3026
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: Sync-tricks/fullscreen discussion

Postby ijor » Sun Mar 20, 2016 2:23 pm

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


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.

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Sync-tricks/fullscreen discussion

Postby Cyprian » Sun Mar 20, 2016 2:40 pm

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

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?
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1897
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 7:52 pm

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.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1897
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Sync-tricks/fullscreen discussion

Postby Steven Seagal » Sun Mar 20, 2016 7:57 pm

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?


Plz check this old schema:

viewtopic.php?f=94&t=28886#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).

User avatar
npomarede
Atari God
Atari God
Posts: 1132
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Sync-tricks/fullscreen discussion

Postby npomarede » Sun Mar 20, 2016 9:13 pm

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.

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
Atari freak
Atari freak
Posts: 70
Joined: Mon Jul 23, 2012 7:59 am
Contact:

Re: Sync-tricks/fullscreen discussion

Postby tin » Sun Mar 20, 2016 10:05 pm

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.

User avatar
troed
Atari God
Atari God
Posts: 1182
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Sync-tricks/fullscreen discussion

Postby troed » Sun Mar 20, 2016 10:43 pm

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:


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


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 3 guests