horizontal scrolling on ST

GFA, ASM, STOS, ...

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

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: horizontal scrolling on ST

Postby Dio » Fri Oct 04, 2013 9:43 pm

troed wrote:Thanks for the explanation. Does this mean the MMU consults a memory map to know whether it needs to do this for a specific memory address or not?

My expectation is that MMU owns DTACK for everything going through the gateway and the timing of it is run by the same state machine that manages RDAT, WDAT, LATCH, LOAD etc.

So it's Glue's decoding logic that indicates (I think on the /RAM and/or /DEV signals) to MMU that it's MMU's responsibility to handle the operation and MMU takes it from there.

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

Re: horizontal scrolling on ST

Postby troed » Fri Oct 04, 2013 10:10 pm

ljbk wrote:If you look at the source available at DHS, you will see that there is only one STE patch related to line sizes. It is related to the 0 bytes case: 60Hz has to be set at emulator cycle 40 and we go back to 50Hz at emulator cycle 52.
So i assume that the +2 case works in the same way for STE as for STF for the detected (old)wakeup state on STE by that program (probably 1).


Indeed - if we look at the NTSC and PAL starting positions in the state machines:

STF:
52 IF(FREQ == 60) && (RES == LO) H = TRUE
54 IF(FREQ == 50) LINE = PAL
56 IF(FREQ == 50) && (RES == LO) H = TRUE

STE:
36 IF(FREQ == 60) && (RES == LO) H = TRUE
40 IF(FREQ == 50) && (RES == LO) H = TRUE
56 IF(FREQ == 50) LINE = PAL
58 Also related to line length similar to above for 50/60Hz. Unknown cause.

We see that it's very similar - but due to the STEs hardware scroll capability it needs to pre-load 16 pixels so the signal to MMU is raised 16 cycles earlier and the complexities in two cycle timing with the LINE-length position in between is gone. What I wanted to figure out tonight was the STE equivalent to STF cycle 54, that is, the position where the length in cycles (508 or 512, and hi res timings as well) was taken.

I did not expect the answer to be two positions with slightly different behaviour :D

(Btw, contrary to what I have believed and posted before STE +2 can be created not only with 36/xx but also with 34/xx, 32/xx and 30/xx ... as the state machine indicates :P The only thing that's important is to be at 60Hz at cycle 36 and back at 50Hz at cycle 56)

Dio wrote:So it's Glue's decoding logic that indicates (I think on the /RAM and/or /DEV signals) to MMU that it's MMU's responsibility to handle the operation and MMU takes it from there.


Thanks. This logic has always fascinated me but I never took the time to learn it. Appreciated.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Sun Oct 06, 2013 11:49 am

troed wrote:(Btw, contrary to what I have believed and posted before STE +2 can be created not only with 36/xx but also with 34/xx, 32/xx and 30/xx ... as the state machine indicates :P The only thing that's important is to be at 60Hz at cycle 36 and back at 50Hz at cycle 56)


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.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Sun Oct 06, 2013 12:01 pm

troed wrote:(And if it preloads for 16 cycles in high res as well then it actually preloads for 8 cycles before even knowing if there's a screen to start displaying. THAT would look strange in a trace .. )

edit: Maybe I should point out that I assume horisontal scroll is always 16 pixels in all resolution and thus pre-fetch should need one word (4 cycles) in high res, two words (8) in medium and four (16) in low. That works out well with the timings as well, so, no strange traces. It was hypothetical ;)

/Troed


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.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Sun Oct 06, 2013 10:35 pm

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 viewtopic.php?f=68&t=9527&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 :P

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

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Mon Oct 07, 2013 7:15 pm

OK I've looked at part of the "state machine", and it makes sense.
In a later version of Steem, not v3.5.3 because it's risky and demands testing, some parts where we're still looking for specific switches should be replaced with checking the state.

For example for one type of 0-byte line, we have something like this:

Code: Select all

    if(ShiftModeChangeAtCycle(464-4)==2 && !ShiftModeChangeAtCycle(464+8))
      CurrentScanline.Tricks|=TRICK_0BYTE_LINE;


Funcion names are self-explanatory.
Looking for a R2/R0 switch at such timing in a somewhat rigid way. But notice we already hinted at the reason by isolating cycle 464 (the cycle of HSync).

Instead we would have something like that:

Code: Select all

    if(ShiftModeAtCycle(464)==2)
      CurrentScanline.Tricks|=TRICK_0BYTE_LINE;


Which is simpler and more performant, and will work with new cases.
Except that '464' should be computed for: STF/STE, 50Hz/60Hz, WU state...
Other 0-byte lines also make sense: at the cycle of "stop HSync", at the cycle of "stop HBlank", etc.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Thu Oct 10, 2013 7:12 pm

While running some checks I noticed a "line +2" oddity on the STE.

If you switch from 50hz to 60hz at cycle 40, the line isn't +2. (Forest STE tests)
If you switch from 60hz to 50hz at cycle 40, the line isn't +2. (Darkside of the Spoon first screen, it was broken in STE mode, that's how I noticed the problem)

I don't know if that makes sense. In Steem there's a single check for STF, a double for STE.
In STF mode, frequency must be 60hz at cycle 54.
In STE mode, frequency must be 60hz at cycles 38 and 42.


The messy code below works with the cases I know:

Code: Select all

    t=56-16; //The line must "start" earlier on STE due to HSCROLL
#if defined(SS_MMU_WAKE_UP_SHIFTER_TRICKS)
    if(MMU.WakeUpState2())
      t+=2;
#endif

#if defined(SS_STF)
    if(ST_TYPE!=STE)
      t+=16;
    else
#endif
    if(ShiftModeAtCycle(t)==1)
      t+=8; // MED RES, STE starts only 8 cycles earlier

    if(/*CyclesIn>=t+2 &&*/
      FreqAtCycle(t-2)==60
      && (
#if defined(SS_STF)
          ST_TYPE!=STE
#endif
          || FreqAtCycle(t+2)==60 )
      && (FreqAtCycle(376)==50 || CyclesIn<376 && shifter_freq==50)) //TODO WU?
    {
      CurrentScanline.Tricks|=TRICK_LINE_PLUS_2;
//      TRACE("CyclesIn %d t %d\n",CyclesIn,t);
  //    VideoEvents.ReportLine();
    }
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Thu Oct 10, 2013 8:32 pm

Steven Seagal wrote:While running some checks I noticed a "line +2" oddity on the STE.

If you switch from 50hz to 60hz at cycle 40, the line isn't +2. (Forest STE tests)
If you switch from 60hz to 50hz at cycle 40, the line isn't +2. (Darkside of the Spoon first screen, it was broken in STE mode, that's how I noticed the problem)


Code: Select all

STE:
36   IF(FREQ == 60) && (RES == LO) PRELOAD = TRUE
40   IF(FREQ == 50) && (RES == LO) PRELOAD = TRUE
56   IF(FREQ == 50) LINE = PAL


A switch from 50Hz to 60Hz at cycle 40 should produce a 0-byte line, as long as it was 50Hz at 36 as well (which, since our fastest switch is four cycles it was), since both the checks at 36 and 40 will be false. The switch from 60Hz to 50Hz at cycle 40 should however be fine - but I'm sure it can depend on when the switch _to_ 60Hz was made which I don't know from your post. A guess is that there's an init during HSYNC but I haven't researched it. Please post the timings since it'll help me in narrowing it down :D

I don't know if that makes sense. In Steem there's a single check for STF, a double for STE.
In STF mode, frequency must be 60hz at cycle 54.
In STE mode, frequency must be 60hz at cycles 38 and 42.


The checks for ST are indeed different:

Code: Select all

ST:
52   IF(FREQ == 60) && (RES == LO) H = TRUE
54   IF(FREQ == 50) LINE = PAL
56   IF(FREQ == 50) && (RES == LO) H = TRUE


So no, on ST 60Hz at cycle 54 would actually produce a 508 cycle (NTSC) line - the logic is that it needs to be 60Hz at cycle 52 and 50Hz at cycle 54* (that's why it was so hard to make - it needs both two cycle accuracy as well as wakeup detection).

On STE the logic is that 60Hz is needed at cycle 36, 50Hz at cycle 56. In my notes from just the other week I have +2 lines on STE being produced with switches (60Hz/50Hz) at 30/38, 32/40, 34/42 and 36/44. Switches at 38/46 and 40/48 produce 0-byte lines.

The state machines can just be read in sequence to figure out when DE is raised and whether a line is 508 or 512 cycles. The line length in bytes is then calculated from the cycle DE was deactivates minus when DE was raised. So, there would be no hardcoded constants for the different tricks. However, as you point out with the DSOTS example there's most likely knowledge contained in current emulator code that still needs to be added.

(I'm btw somewhat stuck on the "just blank" lines documented by Paulo with FREQ switches at 26-28/52 and RES at 20-24/56. I've verified that the FREQ version works the same, with the same timing, on STE - the RES however is nonexistent there. What I don't know is why a FREQ 24/32 doesn't work, i.e, what dictates the earliest possible switch. I wanted to get GLUE out of the way before starting to document Shifter but I guess I'll have to give it some more attention ... )

/Troed

*) Note: All my ST state machine timings are WS1. See the wiki or Paulo's excel sheet for offsets in other wakestates.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Thu Oct 10, 2013 9:11 pm

troed wrote:A switch from 50Hz to 60Hz at cycle 40 should produce a 0-byte line, as long as it was 50Hz at 36 as well (which, since our fastest switch is four cycles it was), since both the checks at 36 and 40 will be false.


Of course. Thx! I forgot to check 0-byte before doing the +2 test.

The switch from 60Hz to 50Hz at cycle 40 should however be fine - but I'm sure it can depend on when the switch _to_ 60Hz was made which I don't know from your post. A guess is that there's an init during HSYNC but I haven't researched it. Please post the timings since it'll help me in narrowing it down :D


Code: Select all

-30 - 456:S0000 512:T0100 512:#0000
-29 - 040:S0002 344:S0000 392:S0002 440:R0000 456:R0000 508:R0002 512:T2008 512:#0158



I don't know if that makes sense. In Steem there's a single check for STF, a double for STE.
In STF mode, frequency must be 60hz at cycle 54.
In STE mode, frequency must be 60hz at cycles 38 and 42.


The checks for ST are indeed different:

Code: Select all

ST:
52   IF(FREQ == 60) && (RES == LO) H = TRUE
54   IF(FREQ == 50) LINE = PAL
56   IF(FREQ == 50) && (RES == LO) H = TRUE


So no, on ST 60Hz at cycle 54 would actually produce a 508 cycle (NTSC) line - the logic is that it needs to be 60Hz at cycle 52 and 50Hz at cycle 54* (that's why it was so hard to make - it needs both two cycle accuracy as well as wakeup detection).


This is a problem for the moment in Steem, the checks assume "before that cycle". If you write at cycle 54, the Steem tests report the value just before the write, don't waste your time with this, it's my problem.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Thu Oct 10, 2013 9:39 pm

Steven Seagal wrote:Of course. Thx! I forgot to check 0-byte before doing the +2 test.


Just another thing that would be a lot simpler by converting to state checks at the specific cycles ;)

troed wrote:The switch from 60Hz to 50Hz at cycle 40 should however be fine - but I'm sure it can depend on when the switch _to_ 60Hz was made which I don't know from your post. A guess is that there's an init during HSYNC but I haven't researched it. Please post the timings since it'll help me in narrowing it down :D


Code: Select all

-30 - 456:S0000 512:T0100 512:#0000
-29 - 040:S0002 344:S0000 392:S0002 440:R0000 456:R0000 508:R0002 512:T2008 512:#0158


Ah, there we are! The switch to 60Hz happens just before HSYNC. It's not the first time I suspect there's an init happening there - it really needs to be investigated and codified. I'm not really sure why that would affect the checks though so currently I can offer no help. Paulo's investigation (STF) says the 60Hz switch can be as early as 378 on the line before so whatever causes it could be STE specific (even preload-related .. hmm. Another thing to test).

The -2 is obvious from 344/392 though - but setting lores/lores at 440/456 looks very strange. Is that a failed ULM stabilizer that should've set medres/lores instead? Also, unusually early (but fully working in all wakestates) switch for opening the left border on the next line at cycle 508.

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

Re: horizontal scrolling on ST

Postby npomarede » Thu Oct 10, 2013 9:56 pm

troed wrote:The -2 is obvious from 344/392 though - but setting lores/lores at 440/456 looks very strange. Is that a failed ULM stabilizer that should've set medres/lores instead? Also, unusually early (but fully working in all wakestates) switch for opening the left border on the next line at cycle 508.

I saw many sync scroller where all used overscan lines are made on the same template with 3 actions : change res on start, change freq at end of line, change res for stabiliser. Sometimes, unused switches are left in place, either with their usual hi/lo switches, or they become a lo/lo (=nop) switch. It's not rare to see that the stabilizer is always present, even when right border is not removed or you have a right-2.
I guess that was just to make it easier for the coder to count the cycles per line and ensure each combination was always 512 cycles :)

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Fri Oct 11, 2013 8:08 pm

troed wrote:
Steven Seagal wrote:Of course. Thx! I forgot to check 0-byte before doing the +2 test.


Just another thing that would be a lot simpler by converting to state checks at the specific cycles ;)


Yes I reckon it's the next phase, though what would replace checking for "this line is 0-byte"?

Ah, there we are! The switch to 60Hz happens just before HSYNC. It's not the first time I suspect there's an init happening there - it really needs to be investigated and codified. I'm not really sure why that would affect the checks though so currently I can offer no help. Paulo's investigation (STF) says the 60Hz switch can be as early as 378 on the line before so whatever causes it could be STE specific (even preload-related .. hmm. Another thing to test).

The -2 is obvious from 344/392 though - but setting lores/lores at 440/456 looks very strange. Is that a failed ULM stabilizer that should've set medres/lores instead? Also, unusually early (but fully working in all wakestates) switch for opening the left border on the next line at cycle 508.


I posted only some part, here's the full frame.

Code: Select all

-38 - 372:j0006
-30 - 456:S0000 512:T0100 512:#0000
-29 - 040:S0002 344:S0000 392:S0002 440:R0000 456:R0000 508:R0002 512:T2008 512:#0158
-28 - 012:R0000 344:S0000 392:S0002 512:T0009 512:#0184
-27 - 160:R0002 176:R0000 392:S0002 440:R0000 456:R0000 508:R0002 512:T2004 512:#0054
-26 - 012:R0000 376:S0000 392:S0002 512:T0011 512:#0230
-25 - 392:S0002 440:R0000 456:R0000 508:R0002 512:T2000 512:#0160
-24 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-23 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-22 - 012:R0000 200:V0005 204:M00CF 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-21 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-20 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-19 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-18 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-17 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-16 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-15 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-14 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-13 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-12 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-11 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-10 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-09 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-08 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-07 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-06 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-05 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-04 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-03 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-02 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
-01 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
000 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
001 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
002 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
003 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
004 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
005 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
006 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
007 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
008 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
009 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
010 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
011 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
012 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
013 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
014 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
015 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
016 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
017 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
018 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
019 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
020 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
021 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
022 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
023 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
024 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
025 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
026 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
027 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
028 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
029 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
030 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
031 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
032 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
033 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
034 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
035 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
036 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
037 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
038 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
039 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
040 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
041 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
042 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
043 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
044 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
045 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
046 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
047 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
048 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
049 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
050 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
051 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
052 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
053 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
054 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
055 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
056 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
057 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
058 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
059 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
060 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
061 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
062 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
063 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
064 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
065 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
066 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
067 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
068 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
069 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
070 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
071 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
072 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
073 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
074 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
075 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
076 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
077 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
078 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
079 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
080 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
081 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
082 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
083 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
084 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
085 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
086 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
087 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
088 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
089 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
090 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
091 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
092 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
093 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
094 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
095 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
096 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
097 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
098 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
099 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
100 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
101 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
102 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
103 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
104 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
105 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
106 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
107 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
108 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
109 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
110 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
111 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
112 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
113 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
114 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
115 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
116 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
117 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
118 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
119 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
120 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
121 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
122 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
123 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
124 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
125 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
126 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
127 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
128 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
129 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
130 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
131 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
132 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
133 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
134 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
135 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
136 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
137 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
138 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
139 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
140 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
141 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
142 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
143 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
144 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
145 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
146 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
147 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
148 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
149 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
150 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
151 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
152 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
153 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
154 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
155 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
156 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
157 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
158 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
159 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
160 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
161 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
162 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
163 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
164 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
165 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
166 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
167 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
168 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
169 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
170 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
171 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
172 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
173 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
174 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
175 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
176 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
177 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
178 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
179 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
180 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
181 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
182 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
183 - 012:R0000 376:S0000 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
184 - 012:R0000 028:S0002 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
185 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
186 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
187 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
188 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
189 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
190 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
191 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
192 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
193 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
194 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
195 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
196 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
197 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
198 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
199 - 012:R0000 376:S0000 440:R0001 456:R0000 508:R0002 512:T2211 512:#0230
200 - 012:R0000 028:S0002 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
201 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
202 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
203 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
204 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
205 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
206 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
207 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
208 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
209 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
210 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
211 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
212 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
213 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
214 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
215 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
216 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
217 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
218 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
219 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
220 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
221 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
222 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
223 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
224 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
225 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
226 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
227 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
228 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
229 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
230 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
231 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
232 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
233 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
234 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
235 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
236 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
237 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
238 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
239 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
240 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
241 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
242 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
243 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230
244 - 012:R0000 376:S0000 392:S0002 512:T0011 512:#0230


Switch to R2 is at 508 for "left off".
We recognise the ULM stabiliser R1/R0.

And I confirm what Nicolas says, many demos write useless switches, I guess because they use a sync table.
Eg Forest by Paolo:

Code: Select all

-30 - 460:S0000 512:R0002 512:T0100 512:#0000
-29 - 016:R0000 024:S0002 376:S0002 384:S0002 444:R0002 456:R0000 512:R0002 512:T2001 512:#0186
-28 - 012:R0000 376:S0002 384:S0002 444:R0002 456:R0000 512:R0002 512:T2001 512:#0186
-27 - 012:R0000 376:S0002 384:S0002 444:R0002 456:R0000 512:R0002 512:T2001 512:#0186
-26 - 012:R0000 028:S0000 036:S0002 368:S0000 376:S0002 444:R0000 456:R0000 512:R0002 512:T2089 512:#0184


The 186 bytes lines have a fake 376/384 switch S2/S2.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Fri Oct 11, 2013 10:03 pm

Steven Seagal wrote:Yes I reckon it's the next phase, though what would replace checking for "this line is 0-byte"?


If DE hasn't been raised there are no pixels to display and no video counter to increase. A 0-byte line is a line where care has been taken to make sure DE isn't raised during the duration of the line :)

Code: Select all

4   IF(RES == HI) H = TRUE
52   IF(FREQ == 60) && (RES == LO) H = TRUE
54   IF(FREQ == 50) LINE = PAL
56   IF(FREQ == 50) && (RES == LO) H = TRUE


If we skip the sync-distorting ways*, the following logic will produce a 0-byte line on ST WS1:

*) Cycle 4: Are we in low resolution? Yes
*) Cycle 52: Are we in 50Hz or high resolution? Yes
*) Cycle 56: Are we in 60Hz or high resolution? Yes

(And type of line is decided at cycle 54 - needs to be low res PAL for regular demo use)

Being able to just calculate the resulting line length from the cycle where DE is raised minus where its deactivated is a neat bonus: http://atari-forum.com/wiki/index.php?t ... ne_lengths

When I have time to spend with my STE again I will try to figure out the "just blank" lines as well as how come the DSOTS switch back at cycle 40 doesn't produce a +2 line on STE. After that I might do some (surely naïve) pseudo code around how I would implement the state machines for emulator usage.

(My plans for the Shifter is to start with the STE, where the behaviour seems much simpler, and then move on to ST WS1, followed by WS3-WS4-WS2 ... I have some ideas as to why "warm/warming/cold" behaviour arise and how they can affect the stabilizers but so far the math doesn't check out, but I will leave it for now and concentrate on the STE first)

/Troed

*) Cancel HSYNC at 462 doesn't really produce a 0-byte line as it produces "no line". The behaviour of a double length (in duration) line is very TV/monitor specific but from the ST point of side it doesn't exist. HBL isn't increased so there will be an extra line at the bottom of the screen. Extending HSYNC at 502 might produce something similar although I'm less sure. Extending BLANK at 30 is probably the "best" of the sync distorting 0-byte lines. To cover these cases the state machine would need a bit more logic looking like "&& !BLANK" etc on the DE raising line.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Sat Oct 12, 2013 8:19 am

Practically, in an emulator, since the tests for 0 byte line have been done, we use the result.
We don't test again why it's 0 byte.

troed wrote:*) Cancel HSYNC at 462 doesn't really produce a 0-byte line as it produces "no line". The behaviour of a double length (in duration) line is very TV/monitor specific but from the ST point of side it doesn't exist.

I agree with this: there's no HSync, the line is fetched but the monitor can't display it, so it has the same effect as a 0 byte line.

Code: Select all

scanline 1
scanline 2 not fetched  (other tricks)
scanline 3

scanline 1 | scanline 2  (this trick)
scanline 3

visible effect:
scanline 1
scanline 3

Is this correct? [edit: I ask because I suspect it's wrong]

Case: Beyond/Pax Plax Parallax STF

HBL isn't increased so there will be an extra line at the bottom of the screen.


In emulation we mustn't add an extra line, I think HBL++ occurs at around cycle 500 when HSYNC is cleared.

Extending HSYNC at 502 might produce something similar although I'm less sure.

Here you have a 0-byte line and you must add one line at the end. That's why I would place HBL++ at that cycle.
Cases: No Buddies Land, Delirious 4/NGC
Last edited by Steven Seagal on Sat Oct 12, 2013 9:30 am, edited 1 time in total.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Sat Oct 12, 2013 9:22 am

Coming back to 184 bytes lines, running tests reminded me of this case:

Code: Select all

Frame freq: 60 shift mode: 1 WU: 0
Disk A: HighResMode STE
-34 - 390:V000C 394:M0006 416:v0000
-33 - 120:j0006
000 - 452:w050C 456:w0706 468:w0948 504:R0002 508:TC000 508:#0160
001 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
002 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
003 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
004 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
...


In HighResMode, the frames stay at 60hz all the time, there's not a single sync switch.
Conceptually (nice word), those are 60hz lines without left border, hence, directly, 184 byte lines.
By the way the res switches are exclusively R2/R1.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Sun Oct 13, 2013 10:32 pm

troed wrote:Ah, there we are! The switch to 60Hz happens just before HSYNC. It's not the first time I suspect there's an init happening there - it really needs to be investigated and codified. I'm not really sure why that would affect the checks though so currently I can offer no help. Paulo's investigation (STF) says the 60Hz switch can be as early as 378 on the line before so whatever causes it could be STE specific (even preload-related .. hmm. Another thing to test).


Now tested. So the question was how come some demos (DSOTS) don't produce +2 lines on STE even though they switch back to 50Hz at cycle 40, being in 60Hz since the line before. Unfortunately my test did not support STE init behaviour different from STF and as Paulo has documented the switch to 60Hz can be just after the right border position. I just ran the following test suite tonight:

60Hz/50Hz

Code: Select all

432/36     160
432/38     162
432/40     162
432/42     162
432/52     162
452/52     162
464/52     162
476/52     162
488/52     162
500/52     162
0/52         162


Steven Seagal wrote:CODE: SELECT ALL
-30 - 456:S0000 512:T0100 512:#0000
-29 - 040:S0002 344:S0000 392:S0002 440:R0000 456:R0000 508:R0002 512:T2008 512:#0158


.. and so would still consider switches like the ones above to produce an NTSC-position 160-byte line (+2 left and -2 right) on STE. It's very strange if they don't on real hardware.

Steven Seagal wrote:Is this correct? [edit: I ask because I suspect it's wrong]


It's fully possible I've misunderstood posts on which type of modifications to BLANK start and HSYNC start/end cause long-duration lines without increasing HBL. I'll have to either test myself or re-read the old threads :) Or defer to Paulo who might have that documented already.

Steven Seagal wrote:Coming back to 184 bytes lines, running tests reminded me of this case:

CODE: SELECT ALL
Frame freq: 60 shift mode: 1 WU: 0
Disk A: HighResMode STE
-34 - 390:V000C 394:M0006 416:v0000
-33 - 120:j0006
000 - 452:w050C 456:w0706 468:w0948 504:R0002 508:TC000 508:#0160
001 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
002 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
003 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
004 - 012:R0001 432:R0002 444:R0001 504:R0002 508:T20000 508:#0184
...


In HighResMode, the frames stay at 60hz all the time, there's not a single sync switch.
Conceptually (nice word), those are 60hz lines without left border, hence, directly, 184 byte lines.
By the way the res switches are exclusively R2/R1.


Yeah, what happens is that the left border is opened (using the hires/71Hz position at cycle 0 to activate preload - which is finished and DE raised at cycle 4) and then by always being in 60Hz the check at cycle 56 will produce a 508 cycle line and the check at 372 for deactivating DE will be true.

(372-4)/2 = 184

/Troed

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Mon Oct 14, 2013 6:46 pm

troed wrote:Now tested. So the question was how come some demos (DSOTS) don't produce +2 lines on STE even though they switch back to 50Hz at cycle 40, being in 60Hz since the line before. Unfortunately my test did not support STE init behaviour different from STF and as Paulo has documented the switch to 60Hz can be just after the right border position. I just ran the following test suite tonight:

60Hz/50Hz

Code: Select all

432/36     160
432/38     162
432/40     162
432/42     162
432/52     162
452/52     162
464/52     162
476/52     162
488/52     162
500/52     162
0/52         162

/Troed


Well, the test results are clear. Is it possible that DSOTS was broken on STE?
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Mon Oct 14, 2013 7:17 pm

Steven Seagal wrote:Well, the test results are clear. Is it possible that DSOTS was broken on STE?


:P So I have an HxC floppy emu with No Fragments 1 on the SD-card and an STE right next to me ...

*booting up Dark Side of the Spoon*

Which screen do you mean by "first screen" btw? The intro with the repeating coloured balls background and rotating info-logo? "The intro".

It looks fine. Can't see a single line off and the info-logo is centred. (Slight discolorization of 8 pixels at the extreme right sometimes which I recall to be fully normal)

(My next guess would be the leftmost door - the syncscrolling woman holding up a scroll text. It also looks fine)

I love this demo. What a masterpiece.

edit: There are three images of DSOTS on No Fragments 1: SPOON.MSA, SPOON_P.MSA and DARKSIDE_P.MSA. "P" means patched, as far as I've understood, but I've tested the intro screen on all three with the same results.

/Troed

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Mon Oct 14, 2013 7:59 pm

troed wrote:
Which screen do you mean by "first screen" btw? The intro with the repeating coloured balls background and rotating info-logo? "The intro".

/Troed


Yeah, the first fullscreen after boot.
It's great that you can test such thing.

There are other possibilities:
- for some reason timing is off in Steem and DSOS actually never hits S2 at cycle 40
- your cycles are off by 4 in the test, I'm surprised by 432/38 162

About the demo, I appreciate it for its test-value, but also the rotating ball screen for itself, found it impressive.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Mon Oct 14, 2013 8:51 pm

Steven Seagal wrote:There are other possibilities:
- for some reason timing is off in Steem and DSOS actually never hits S2 at cycle 40
- your cycles are off by 4 in the test, I'm surprised by 432/38 162


Well, don't know about Steem but I don't think my test is off ;) It's compliant with the other research on the state machine for STE:

Code: Select all

0   IF(RES == HI) PRELOAD = TRUE
...
36   IF(FREQ == 60) && (RES == LO) PRELOAD = TRUE
40   IF(FREQ == 50) && (RES == LO) PRELOAD = TRUE
56   IF(FREQ == 50) LINE = PAL
...
376   IF(FREQ == 50) && (RES == LO) H = FALSE


Line being in 60Hz since cycle 432 on the line before doesn't trigger the check at cycle 0 but it does trigger at cycle 36 (which preloads for 16 cycles and then raises DE at cycle 52). The switch back to 50Hz can be done at any time from cycle 38 to cycle 56 (if we want a PAL 512 cycle line).

(376-52)/2 = 162

DSOTS was released in 1991 so I'm sure they tested it extensively on STE. Whether the switch back is really at cycle 36 instead of 40 (the "nearest" error) or if there's an STE test that changes the code but isn't picked up in emulation is difficult to know without stepping through the actual code.

/Troed

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Mon Oct 14, 2013 9:46 pm

No, I think timings are the same for STF & STE.
There must be a bug in Steem then (VBI timing?).
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

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

Re: horizontal scrolling on ST

Postby troed » Mon Oct 14, 2013 10:13 pm

Steven Seagal wrote:No, I think timings are the same for STF & STE.
There must be a bug in Steem then (VBI timing?).


I'm not sure what such a bug would look like - the timings in the frame you posted make perfect sense otherwise.

However, recall that LoSTE top border also works perfectly on my STE but fails on an NTSC-MSTE. I also spent quite some time making it stable in Hatari*. Top border removal is sensitive to MFP timer differences and I guess since there are differences between ST hardware models that applies to emulators vs hardware as well. Maybe that's why you see the switch back at cycle 40 in Steem even though my STE doesn't.

/Troed

*) From my LoSTE testing notes just minutes before I decided it was time for release:

Done: That same image is completely unstable in Hatari ST. Looks like top border +2. In Hatari STE it's ok. Loading logo correct in both 1Mb and 4Mb config on both ST and STE.

The unstableness is not connected to EXG before first switch. It might be connected to #20 instead of #17 delay though. If we switch this on, it might work on all my hardware but I'm wary about those STs with different clock chips …


(It did work on all my hardware, incl. emulators, but not on slower STFs nor faster STEs ... I'll release an updated version within the next 22 years or so)

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Tue Oct 15, 2013 7:30 pm

troed wrote:edit: There are three images of DSOTS on No Fragments 1: SPOON.MSA, SPOON_P.MSA and DARKSIDE_P.MSA. "P" means patched, as far as I've understood, but I've tested the intro screen on all three with the same results.


The patch is for a CPU exception in the loader that wasn't correctly handled by emulators before (low stack?):

Code: Select all

Exception #2, 2 bombs (BOMBS_BUS_ERROR) during Write
PC=4AE-IR=1941-Ins: move.b d1,+$2476(a4) -SR=2708-Bus=6396D7-Vector $8=4FE
D0=CF8 D1=78E507C6 D2=FFFF D3=1180000 D4=FFEC D5=14 D6=72FB0 D7=467265FF
A0=20300 A1=4B6 A2=FFFFF6E6 A3=48 A4=20637261 A5=50953577 A6=484 A7=1C
Push PC 4B2 on 18
Push SR 2708 on 16
Push IR 1941 on 14
Push address 6396D7 on 10
Push status 1945 on E


troed wrote:I'm not sure what such a bug would look like


Bugs look like this:
Image
Ha ha :roll:

- the timings in the frame you posted make perfect sense otherwise.


It's because after the suspect 40 S2, the timings are synchronised on the video counter:

Code: Select all

-29 - 040:S0002 048:r0900 068:r0902 392:S0002


However, recall that LoSTE top border also works perfectly on my STE but fails on an NTSC-MSTE. I also spent quite some time making it stable in Hatari*. Top border removal is sensitive to MFP timer differences and I guess since there are differences between ST hardware models that applies to emulators vs hardware as well. Maybe that's why you see the switch back at cycle 40 in Steem even though my STE doesn't.
/Troed


Yes, but Steem's should be a PAL STE, its CPU/MFP timings are like SainT's and Hatari's.
Now I think that the 40 S2 is at its place and that the mystery could be something different and very interesting.
Remark that the frame ends like this:

Code: Select all

244 - 012:R0000 376:S0000 392:S0002 512:T0011 512:#0230


This is an unstable 230 byte line, and this could very well have an impact on the line +2 of next frame.
Didn't Paolo say that a scanline at 60hz resets the Shifter?
This is no precise explanation but I will go with this theory like I did for Dragon by Ghost, because unless timings are wrong, it's the thing that makes most sense to me (and it's fun).

Code: Select all

T0011 -> Shifter PreLoad=3

Line +2 test positive -> If PreLoad=0, +2, if PreLoad<>0, reset Shifter


Note that the Shifter is reset by another sync line even if there's no "+2", eg:

Code: Select all

-26 - 012:R0000 376:S0000 392:S0002 440:R0001 456:R0000 508:R0002 512:T2011 512:#0230


So that screen is guaranteed to work.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: horizontal scrolling on ST

Postby Steven Seagal » Thu Oct 17, 2013 6:09 pm

Steven Seagal wrote:
troed wrote:*) Cancel HSYNC at 462 doesn't really produce a 0-byte line as it produces "no line". The behaviour of a double length (in duration) line is very TV/monitor specific but from the ST point of side it doesn't exist.

I agree with this: there's no HSync, the line is fetched but the monitor can't display it, so it has the same effect as a 0 byte line.

Code: Select all

scanline 1
scanline 2 not fetched  (other tricks)
scanline 3

scanline 1 | scanline 2  (this trick)
scanline 3

visible effect:
scanline 1
scanline 3

Is this correct? [edit: I ask because I suspect it's wrong]

Case: Beyond/Pax Plax Parallax STF

HBL isn't increased so there will be an extra line at the bottom of the screen.


In emulation we mustn't add an extra line, I think HBL++ occurs at around cycle 500 when HSYNC is cleared.

Extending HSYNC at 502 might produce something similar although I'm less sure.

Here you have a 0-byte line and you must add one line at the end. That's why I would place HBL++ at that cycle.
Cases: No Buddies Land, Delirious 4/NGC


After looking at it again...

- My little schema wasn't correct. It was as if the screen was scrolled upward, but it's scrolled downward. The monitor displays one extra line while the video RAM isn't fetched.
My explanation "the line is fetched but the monitor can't display it" is wrong.
I think now that when HSYNC isn't completed (no start or no end), the machine state won't set DE on next line. Exactly how I don't know.
But the cathodic ray doesn't depend on HSYNC to go downward, its movement is continuous (I learnt that today), hence the scrolling effect.

- Timing of HBL++ could be HSYNC stop, or depend on HSYNC being completed at the end of the line.
Concretely in emulation we must count one bonus HBL for D4/NGC (end HSYNC), but if we count one for Pax Plax Parallax, it's fine too.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: horizontal scrolling on ST

Postby Dio » Thu Oct 17, 2013 6:13 pm

Steven Seagal wrote:But the cathodic ray doesn't depend on HSYNC to go downward, its movement is continuous (I learnt that today), hence the scrolling effect.

I would expect it to depend on the circuitry inside the TV - assuming it's a PLL, then you'll get a 'default period' HSYNC which will be about right, but not exactly right.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 2 guests