horizontal scrolling on ST

[Steven Seagal]

More line+2 troubles in STE mode!

Code: Select all

Cuddly Demos STE
-30 - 344:w0920 378:w075A 396:w0507 472:S0000 512:T4100 512:#0000
-29 - 048:S0002 512:T0002 512:#0162 
This time no "unstable shifter" to save us. (unlike DSOS)

S2 at 48 (or 40,44) -> line +2 breaks the screen.

I just don't understand, so being pragmatical I tuned tests in Steem so that the rare cases where we want a line +2 will work in STE (Mindbomb, Forest, and?) mode and STF (Beeshift...), while avoiding false alerts (DSOS, Cuddly, LoSTE screens...)

[troed]

More line+2 troubles in STE mode!

CODE: SELECT ALL
Cuddly Demos STE
-30 - 344:w0920 378:w075A 396:w0507 472:S0000 512:T4100 512:#0000
-29 - 048:S0002 512:T0002 512:#0162
This time no "unstable shifter" to save us. (unlike DSOS)

S2 at 48 (or 40,44) -> line +2 breaks the screen.

I wonder if this might be related to the not-60Hz-even-though-it-should-be top line on the TCB SNYD-screen I never could explain:

my visual inspection tells me the first line isn't in 60Hz (it's visibly four pixels to the right of the 60Hz line below) [...] So, I'm guessing that when starting out in 50Hz removing the top border, in that failed way, the state machine cannot (?) create a 60Hz first line. This would of course have to be verified but I cannot really explain why it's in 50Hz otherwise just by looking at the top border switch position.

It seems the behaviour of the next line after the opening of the top border might be slightly different. It needs testing on real hardware (both STE and STF I think) - but it almost looks like the 60Hz starting position is invalid (cannot trigger).

/Troed

[Steven Seagal]

I wonder if this might be related to the not-60Hz-even-though-it-should-be top line on the TCB SNYD-screen I never could explain:

my visual inspection tells me the first line isn't in 60Hz (it's visibly four pixels to the right of the 60Hz line below) [...] So, I'm guessing that when starting out in 50Hz removing the top border, in that failed way, the state machine cannot (?) create a 60Hz first line. This would of course have to be verified but I cannot really explain why it's in 50Hz otherwise just by looking at the top border switch position.

It seems the behaviour of the next line after the opening of the top border might be slightly different. It needs testing on real hardware (both STE and STF I think) - but it almost looks like the 60Hz starting position is invalid (cannot trigger).

/Troed

For the moment I don't claim I can explain anything about it, but we also have this case, where we need the +2:

Mindbomb/No poo
-30 - 428:S0000 512:T0100 512:#0160
-29 - 248:S0002 508:T0002 508:#0162


I should also mention here (unrelated to "+2") that in Steem, current build, the "hardware test" of Enchanted Land fails in WS1.

[troed]

For the moment I don't claim I can explain anything about it, but we also have this case, where we need the +2:

Mindbomb/No poo
-30 - 428:S0000 512:T0100 512:#0160
-29 - 248:S0002 508:T0002 508:#0162

Ah yes - a 508 cycle line. We talked about that earlier IIRC? It needs to end in 50Hz (since it starts in 60Hz) to become a +2 in a "different" way. Interesting that the cycle length of the line seems to play a role.

Since I've already tested whether a 60Hz switch on the line before was the cause (see http://www.atari-forum.com/viewtopic.ph ... &start=440 ) I think the only viable solution is that the first line after an opened top border has a slightly different behaviour. I'll put it on my list of things to test - I guess during the next few days.

[Steven Seagal]

Coming back to Union/Level 16...

I did this this morning, as last minute change in Steem v3.5.4, we display 413 pixels for overscan:



In my eyes it's close to the screenshot.

[Steven Seagal]

More line+2 troubles!

Panic

http://www.pouet.net/prod.php?which=14827

Code: Select all

-30 - 492:S0000 512:T0100 512:#0000
-29 - 056:S0082 376:S0000 384:S0082 444:R0082 456:R0000 508:R0082 512:T2012 512:#0206

+2 is wrong

[troed]

More line+2 troubles!

Panic

http://www.pouet.net/prod.php?which=14827

Code: Select all

-30 - 492:S0000 512:T0100 512:#0000
-29 - 056:S0082 376:S0000 384:S0082 444:R0082 456:R0000 508:R0082 512:T2012 512:#0206

+2 is wrong

Thanks, it's again a case of "first line after top border opening". Being 60Hz at cycle 54 it "should" be a 508 cycle line but it seems to not be. I guess it, as speculated earlier, supports the view that the first line after an opened top border doesn't react to the NTSC screen start position - and seemingly not to the cycle length decision either.

It seems the behaviour of the next line after the opening of the top border might be slightly different. It needs testing on real hardware (both STE and STF I think) - but it almost looks like the 60Hz starting position is invalid (cannot trigger).

(I will get around to test it )

/Troed

[Steven Seagal]

Being 60Hz at cycle 54 it "should" be a 508 cycle line but it seems to not be.

/Troed

Note that the '512' isn't authoritative, this business is still sketchy in Steem. Could be wrong...


edit- I remind those cases where we want "+2":

Code: Select all

Forest STF1
-27 - 036:S0000 054:S0002 376:S0000 384:S0002 444:R0002 456:R0000 512:T42012 512:#0206
Forest STF2
-27 - 036:S0000 056:S0002 160:R0002 174:R0000 376:S0002 384:S0002 444:R0002 458:R0000 512:R0002 512:T42006 512:#0056
Forest STE
-27 - 036:S0000 056:S0002 376:S0002 384:S0002 444:R0000 456:R0000 512:T2002 512:#0162

edit2: in current test build, Panic needs WS4 or it will lose top & bottom borders pretty soon. In WS4 it flickers sometimes. I'm not sure it runs on a STE.
edit3: also TOS1.02 is necessary

[joefish]

New here, but I did a scroll using four screen buffers, each a little wider than necessary and each offset by 4 pixels, and two alternating screens to copy them into. I wrote a bit of self-modifying code that would copy from one of the buffers to the hidden screen but with a mid-line wrap-around, making a circular buffer so that you wouldn't run-on through memory as you scrolled. The idea was then to fill in the edges of these rolling buffer by shifting tiles in real time. And because the buffer was wider than a whole screen, it meant you could process all four frames of a tile at once, rather than having to process all the edge tiles with a different shift each frame (and the associated timing differences).

It was going 4 pixels at 25fps, and could do parallax by processing different bitplanes separately. Truth be told, by making the foreground only 2 planes deep, those four buffers only took up the space of two screens. The background, I pre-shifted 16 times, but only 2 planes again and half-height (it was doubled up when displayed), so I could get that in another four screens. So that's 8 working screens or only 256K.

Personally, I can see the advantage of 50fps, but I don't think you lose much by running at 25fps - particularly if you can have more impressive graphics.

[Steven Seagal]

While working on Steem, I recently came by two insights that will one day be in Steem documentation, but that also belong here:

1) Does MMU prefetch really start earlier on the STE for HSCROLL? Or is the HSCROLL done some other way?
This question because programs that read the video counter for sync get the same value at the same time on STF and STE, or fullscreens would be broken.

2) Right border removal has no effect on shifter registers at 50hz, as Alien already observed. The trick grants +44 bytes, apparently the last 4 bytes are fetched but not loaded in the shifter. So when looking at unstable overscan, the effect of a 186 line is the same as 230. Case: Ventura/Naos.

[npomarede]

While working on Steem, I recently came by two insights that will one day be in Steem documentation, but that also belong here:

1) Does MMU prefetch really start earlier on the STE for HSCROLL? Or is the HSCROLL done some other way?
This question because programs that read the video counter for sync get the same value at the same time on STF and STE, or fullscreens would be broken.

hscroll at $ff8265 (the most commonly used) affects the prefetch, when STE demo wants to get in synch with the video counter at the start of the screen, they will usually force hscroll to 0 before doing the loop that waits for $ff8209 to change. Once you're synchronised with the video counter, you can change hscroll again.
If you try to get in synch while scrolling the screen, you will get different result when hscroll=0 and hscroll!=0, so the rest of the code that try to remove border for example will not work in all cases.

Nicolas

[Steven Seagal]

It makes sense that there's early prefetch only when HSCROLL<>0 (and it's emulated so in Steem and certainly Hatari) but it makes the state machine more complicated.
Also, is HSCROLL register both in Shifter (for actual scrolling) and in GLUE (for prefetch timing), like SHIFTMODE?
The addresses are close, could it be an indication?
We still don't get a complete, clear picture. This vindicates the pragmatic approach of emulators.

[npomarede]

It makes sense that there's early prefetch only when HSCROLL<>0 (and it's emulated so in Steem and certainly Hatari) but it makes the state machine more complicated.
Also, is HSCROLL register both in Shifter (for actual scrolling) and in GLUE (for prefetch timing), like SHIFTMODE?
The addresses are close, could it be an indication?

Not sure this is related, maybe they just took unused IO address in increasing order

We still don't get a complete, clear picture. This vindicates the pragmatic approach of emulators.

I'm not sure there're STE programs that rely on hscroll being in glue or shifter and that it affects emulation (like the different video states of the STF).
But we could get a clean picture by plugging a logic analyzer in the STE (like Dio already did), and comparing the different signal when hscroll==0 or hscroll!=0

Nicolas

[troed]

I'm not really sure where this was discussed, but since I'm researching things in the vicinity I wanted to share.

On STE the state machine for the regular bottom and top border removal in 50Hz is:

Code: Select all

502 IF(LINE_COUNT==34 && FREQ==60) V = TRUE
502 IF(LINE_COUNT==263 && FREQ==50) V = FALSE

(Note: Per Alien's doc the line number value 263 is correct for new STs and STEs for the bottom border, on old STs it would not be)

HSYNC END is at cycle 500 so this is the earliest possible check the state machine can perform after that.

I've seen no difference in creating a 60Hz starting position (+2 line) on the first line after opening either the top or bottom border compared to any other line. Next up is to test both on STF.

Examples (60/50Hz switch):

492/500 = no opened border
492/502 = no opened border
496/504 = opened border
500/508 = opened border
502/512 = opened border
502/36 = opened border
502/40 = opened border and first line +2
502/60 = opened border and first line 508 cycles

/Troed

[troed]

Followup to the post above.

On ST the state machine for the regular bottom and top border removal in 50Hz is:

Code: Select all

502 IF(LINE_COUNT==34 && FREQ==60) V = TRUE
502 IF(LINE_COUNT==263 && FREQ==50) V = FALSE

I.e, I see no difference between ST and STE when it comes to top/bottom border timing. However, regular rules apply when it comes to wakestates:

WS1 (DL6): Offset by 0 (FREQ), 0 (RES)
WS3 (DL5): Offset by 0 (FREQ), 2 (RES)
WS4 (DL4): Offset by 2 (FREQ), 2 (RES)
WS2 (DL3): Offset by 2 (FREQ), 4 (RES)

(See the wiki: http://atari-forum.com/wiki/index.php?t ... _Scanlines)

... and since top/bottom borders are opened with FREQ changes it means that the state machine check is at cycle 502 in WS1/WS3 and cycle 504 in WS2/WS4.

Disclaimer: This is valid when synclocked. I did find other differences that could explain why ST demo code fails on STE and vice versa, to be researched in more detail.

/Troed

[troed]

Here are some extra results for BEESCRN4:
- WS1 "banded" does not work as expected for position -4 and that error can proceed to the next position as there is no stabilizer;
- WS4 "normal" works after ESCAPE (M unstabilizer) and does not work with with H unstabilizer;
- WS3 "banded" behaves as with WS1 "banded" above fails with all cases and fails also with all previous versions of the program: this is the first time i get this WS3 working as WS1 !!! This means that there are at least 4 sub wake up states for WS3 not counting the warming cases: WS3N (WS3 normal), WS3B (WS3 banded), WS3N1 (WS3 normal as WS1) and WS3B1 (WS3 banded as WS1 (the one i just got));

Hi Paulo,

Just to let you know that I've just found - when researching something completely different (not a 4 pixel scroll, not unstabilizers) - the exact same thing WS1 and one WS3 substate needs special treatment, the other WS3 substate and WS2/WS4 are fine.

This does give me something to work with when it comes to figuring out exactly what it is that differs, and what the WS3 substate might be. I'll get back to you if I find anything.

/Troed

[ljbk]

Hi Troed !

Nice to see you are still working on this.
Nothing new here as i spent no time at all on ST for the last couple of months.

Good luck !

Paulo.

[troed]

This is not an especially surprising result for anyone having followed the discussions in this thread, but since I've looked into it I thought I should post it (and it'll go up on the wiki as well later).

The famous effect probably mostly known from the Omega demo's fullscreen (the first ever) where the screen is displaying alternating columns of 16 pixels graphics and 16 pixels border color is a Shifter wakeup state. It can happen regardless of GLUE wakeup state (WS1, WS2, WS3 and WS4) and while I do not know of a way to detect it from software (and I'm not certain it could ever be) it's possible to mitigate, at least in some cases.

I've produced code which would either look fine or result in a banded screen - and then added code that made it work regardless of the Shifter wakeup state. I expect there to be no universal trick though - in this specific case I switched the Shifter to medium resolution for a short while before screen start.

It's thus likely the ST used by The Flying Egg / Omega when producing their fullscreen had a tendency to often (or always) prefer the more uncommon Shifter wakeup state. I have vague memories of the same happening often (but not always) on my system with TNT Crew's DOTLB as well. Common to both those left-border removing demos is the lack of a stabiliser - which fits with the tests I've made.

However - I do not believe this to be a case of the Shifter's internal buffers not having been cleared (which is what a "stabiliser" does). For one thing - it wouldn't be a wakeup state then There are some tests that point to the amount of words cleared by a stabiliser being wakeup state dependent (still an area of active research) but it would still not explain the alternating columns.

So - what would? For some reason the Shifter fails to read every second group of four words when having been made available by the MMU - and "jostling" it before the line starts fixes whatever causes it. Since the state is very stable it doesn't strike me as being on the edge of a clock - but there are people here better at that side of things than I am.

I believe the current knowledge about four GLUE wakeup states to be exhaustive - I don't think there are others. When it comes to the Shifter I believe there are several - this being just one of them.

/Troed

[troed]

Observation regarding GLUE wakestates that I found interesting:

My coding setup at the moment is using a mono monitor to develop on and then when the code switches to low resolution the signal is sent to a TV instead and when exiting the code sets mono mode again. As described here: http://www.atari-forum.com/viewtopic.php?f=1&t=26187

This has the interesting side effect of _all_ boots having been made since I started using this setup have been in GLUE wakestate 3 (which is the wakestate my STFM prefers when cold*). I've actually been unable to force it into another wakeup state until I disconnected mono and booted directly into color.

Interesting topic to speculate around? And also if others can replicate it - my assumption is that an STFM which prefers WS1 when cold would be forced into it etc. I think this is indicative of the hardware's "default state" - and somehow mono mode enforces it, or at least the fact that the machine is already running when entering color mode.

Do note: The wakestate detection code must run _after_ the switch to color, of course.

/Troed

*) My STFM preferred behaviour IIRC:

Cold: WS3 - possible to get into WS2 quite easily with a short power off/on. WS4 very seldom. WS1 almost never.
Warm: WS1 - possible to get into WS3 every now and then and also WS4 somewhat regularly. Almost never WS2.

[npomarede]

Thanks, it's again a case of "first line after top border opening". Being 60Hz at cycle 54 it "should" be a 508 cycle line but it seems to not be. I guess it, as speculated earlier, supports the view that the first line after an opened top border doesn't react to the NTSC screen start position - and seemingly not to the cycle length decision either.

It seems the behaviour of the next line after the opening of the top border might be slightly different. It needs testing on real hardware (both STE and STF I think) - but it almost looks like the 60Hz starting position is invalid (cannot trigger).

(I will get around to test it )

/Troed

Hello
Were you able to do some more testing on the case of the 1st line after top border is opened and its 60 Hz timings ? Especially in the case of Panic by Paulo, the switch back to 50 Hz is made at a point where I think the line should have started in 60 Hz for any wakeup state.
In pouet.net comments for this demo https://www.pouet.net/prod.php?which=14827, Paulo mentions a fixed version for other ST where top border is not correctly removed. Anyone has this version ? (I guess the switch back to 50 Hz just happen 4 or 8 switch earlier to be sure ?)

Nicolas

[troed]

Hello
Were you able to do some more testing on the case of the 1st line after top border is opened and its 60 Hz timings ? Especially in the case of Panic by Paulo, the switch back to 50 Hz is made at a point where I think the line should have started in 60 Hz for any wakeup state.
In pouet.net comments for this demo https://www.pouet.net/prod.php?which=14827, Paulo mentions a fixed version for other ST where top border is not correctly removed. Anyone has this version ? (I guess the switch back to 50 Hz just happen 4 or 8 switch earlier to be sure ?)

Nicolas

Well, what I have is what I posted above: http://www.atari-forum.com/viewtopic.ph ... &start=488

There's no special treatment of "next line after opening border" and the timings for +2 etc are as expected from the existing state machine documentation. I guess the new thing I verified is that the check for top/bottom border is at cycle 502 (STE/WS1/WS3 - cycle 504 in WS2/WS4).

I'm quite sure of this but would be happy to look into any suspect behaviour you've found.

regards,
Troed

[npomarede]

Well, what I have is what I posted above: http://www.atari-forum.com/viewtopic.ph ... &start=488

Sorry, I didn't notice this

There's no special treatment of "next line after opening border" and the timings for +2 etc are as expected from the existing state machine documentation. I guess the new thing I verified is that the check for top/bottom border is at cycle 502 (STE/WS1/WS3 - cycle 504 in WS2/WS4).

I'm quite sure of this but would be happy to look into any suspect behaviour you've found.

regards,
Troed

In "panic" under Hatari, I sometimes get a "move.w a4,(a4)" at cycle 52 to go back to 50 Hz. With a move at cycle 52, it means the write in ff820a is complete at cycle 56 and in Hatari this creates a 60 Hz line that starts 4 cycles earlier with +2 bytes and mess the rest of the timings (in most cases, switch is made before cycle 56, so line has correct length).
Is 56 a position that is wakeup dependent, and the 60 Hz line should be emulated only for certain WU state ? (Hatari doesn't handle WU state at the moment).

[troed]

In "panic" under Hatari, I sometimes get a "move.w a4,(a4)" at cycle 52 to go back to 50 Hz. With a move at cycle 52, it means the write in ff820a is complete at cycle 56 and in Hatari this creates a 60 Hz line that starts 4 cycles earlier with +2 bytes and mess the rest of the timings (in most cases, switch is made before cycle 56, so line has correct length).
Is 56 a position that is wakeup dependent, and the 60 Hz line should be emulated only for certain WU state ? (Hatari doesn't handle WU state at the moment).

Hmm. I wonder if this is an issue with timing conventions. So, the tables I've created (which match Paulo's timings etc) are for the cycle when the instruction starts - when it comes to move.b d0,(a0) changes and the like. So, a move back to 50Hz at cycle 52 would indeed (for WS1/WS3) mean that the 60Hz check for start of line (+2) does not trigger. In WS2/WS4 the check would be at cycle 54 so it wouldn't trigger either.

It's not really positions that are wakeup dependent, but the fact that the exact cycle when GLUE reads the contents of the RES and FREQ registers that differ between the different wakeups (wakestates). All reads are thus "wakeup dependent" - but in reality it's only an issue when the used timings are at the limit when the GLUE statemachine changes condition.

I've probed the timings described on the wiki extensively and believe they are correct: http://atari-forum.com/wiki/index.php?t ... _Scanlines

If 820a is "60Hz" a switch back to 50Hz must be made (start of move instruction) at the latest cycle 52 (54 in WS2/WS4) for a line to be 50Hz. Example table below:

60/50Hz - WS1/WS3

0/52 = 512 cycle line, 50Hz starting position
0/54 = 512 cycle line, 60Hz starting position (+2)
0/56 = 508 cycle line, 60Hz starting position (+2)

60/50Hz - WS2/WS4

0/54 = 512 cycle line, 50Hz starting position
0/56 = 512 cycle line, 60Hz starting position (+2)
0/58 = 508 cycle line, 60Hz starting position (+2)

I hope it's of any use.

/Troed

[npomarede]

Yes, my timing convention in Hatari is to use the time where the write is complete, because not all demos use a "move dx,(ax)" to change freq/res
For a "move Dx,(ax)", it's 4 cycle later, but depending on free regs demos use sometimes "move dx,$ff820a" and so on. That's why I prefer using the time where the write is complete (it can be complex, depending on the opcode and its prefect strategy), as it's more consistent than when using the time where the instruction starts.

Maybe you should state in the wiki page that timings are relative to start of instruction for a "move.b dx,(ax)" ?

As for Hatari, I think that as I don't have yet a 2 cycle precision, I can't really detect the difference between a switch at cycle 52 or 54 (with your scale), so I can't get "Panic" and "SHFORSTV" (with its special 0 byte line) work at the same time

[troed]

Yes, my timing convention in Hatari is to use the time where the write is complete, because not all demos use a "move dx,(ax)" to change freq/res
For a "move Dx,(ax)", it's 4 cycle later, but depending on free regs demos use sometimes "move dx,$ff820a" and so on. That's why I prefer using the time where the write is complete (it can be complex, depending on the opcode and its prefect strategy), as it's more consistent than when using the time where the instruction starts.

Maybe you should state in the wiki page that timings are relative to start of instruction for a "move.b dx,(ax)" ?

Yes, for the meantime. I agree with you that I should document the exact timing when the registers are fully written to instead.

As for Hatari, I think that as I don't have yet a 2 cycle precision, I can't really detect the difference between a switch at cycle 52 or 54 (with your scale), so I can't get "Panic" and "SHFORSTV" (with its special 0 byte line) work at the same time

Possibly. When I wrote LoSTE I actually modified my wakestate detection code so that the "failure" to support wakestates in Hatari would result in the demo detecting a suitable wakestate (WS2, IIRC, since that's the closest wakestate to the timings used by Hatari) for the rest of the code. Now naturally no code written before 2006 will try to detect wakestates - but it could be that SFORSTV (would need to be verified) tries to detect the current wakestate and modifies its code according to what Hatari manages to do, or not to do. Which might make things worse/more difficult to handle.

2 cycle accurate statemachine video.c for Hatari 1.9? I promise to help out