Steven Seagal wrote:See, you got confused by those STE lines +2 too.
Before latest fix, Steem would also only take a change at cycle 36. It seems to work because the rare cases (Forest STE and ?) use this timing.
I guess you could say that
It wasn't until I started documenting the state machines that I realized that there seemed to be no reason for STE to do anything between the "just blank" (no pixels displayed) lines that end at FREQ 28* and cycle 36 for +2 as documented in the 2006 thread. Then it struck me that the tests MiggyMog did for Paulo began at cycle 36. So, cycle 32 (or 34,30) were never tested at all, see
http://www.atari-forum.com/viewtopic.ph ... 7&start=81
(So I did, a few days ago. I will continue testing the last few remains of STE behaviour that might differ from the extensive tests Paulo gave us with the excel sheet)
Steven Seagal wrote:I'm sure it will come down to this because it's the best explanation for the timing difference in STE's left border off trick. Like you say 16 cycles off would make strange traces.
It's not prefetch but the scrolling itself after prefetch that takes #cycles needed for one raster.
Prefetch is always 16 cycles, but then there's scrolling - of one raster, then the still strange latency then rendering.
Here's my current thinking on pre-fetch and why it creates +20 (left border) as well as +4/+6 (regular lines). I don't think it's because of GLUE and I don't think it's the Shifter either at the moment. MMU is the one that decides the values of the current screen address and seems to be the only one where the timing and signals fit.
As always - comments are very welcome. All hypotheses need to be tested and if they survive they become gospel
On STE the check to see if we should start a hires (= left border) screen is done 4 cycles earlier than on ST. This matches the 16 cycle difference for lores.
0 IF(RES == HI) H = TRUE
The reason for this is pre-fetch, needed to be able to hardware scroll. It's always done, but not used unless other STE-specific registers are set. Thus the MMU receives this information and starts LOADing up the Shifter. One word per 4 cycles. For hires, one word is all that's needed for 16 pixels - in lores four words are needed (16 cycles, 8 bytes).
40 IF(FREQ == 50) && (RES == LO) H = TRUE
Let's start at lores. At cycle 40 the pre-fetch starts. 4 cycles later a word has been LOADed into the Shifter - but the actual screen memory adress is not touched at this time. The MMU simply does not know if this will be used. If a switch to hires is made at cycle 44 however, the MMU finds itself in hires pre-fetch which is only 4 cycles long so it's already done. It thus updates the screen memory adress with 6 bytes read - 8 minus the word already done.
The same happens at cycle 48 - two words have been LOADed into the Shifter which is well beyond a hires pre-fetch and when the resolution switch is made the screen memory adress is updated with 4 bytes read - 8 minus the two words already done.
(I tried a short switch, avoiding 56, at cycle 52 but did not get +2 as I had hoped for)
At cycle 4, if we go back to lores, the MMU finds at that there are still 12 cycles left to pre-fetch for lores. It's thus not until cycle 16 the real signal for the Shifter to start displaying data is sent, as well as MMU updating the video counter registers: (56-16)/2 = 20.
56 IF(FREQ == 50) LINE = PAL
Sounds like a reasonable hypothesis? It comes with a caveat: It requires the MMU to know about resolution, something it obviously can do being merged with GLUE in STE but it's not known behaviour and it differs from ST. Also, I use CPU cycle timing even though there's a delay between it and MMU reacting. Not sure how that deals with the overshoot-20 byte thing.
I'll update the wiki with this hypothesis if it survives a few day without obvious holes.
/Troed
*) I'm getting nowhere just pondering what it is that causes these so when I have the STE values for FREQ and RES I'll add those and Paulo's ST values to the state machines
