horizontal scrolling on ST

[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

[npomarede]

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

I don't think SHFORSTV was specifically tailored to match Hatari by using a specific wakestate, it was more Hatari that was modified to match this demo and happens to be detected as one of the possible/compatible wakestate

As for Hatari 1.9, video and cpu are indeed next on my personnal list of things to get as close as possible as a real STF/STE No doubt your timing synthesis will be useful to compare with what is already used in Hatari.

[Steven Seagal]

About Panic.tos, I mentioned it here:
http://www.atari-forum.com/viewtopic.ph ... 75#p241882

I see that it hits at cycle 56 in Hatari too, I wondered if maybe there was a timing problem in Steem.
Steem has 2 cycles accuracy and handles WU states (of course), and it can run Forest aka SHFORSTV in WU1 or WU2, but it doesn't help in this case. 56 is too late in all states.
My current explanation is CPU speed, because the routine bringing us to y-30 is a CPU-based delay loop, and in some thread Paolo states his ST is slower than our emulated PAL ST.
There's a new option 8,0Mhz in Steem just for that.

[troed]

My current explanation is CPU speed, because the routine bringing us to y-30 is a CPU-based delay loop, and in some thread Paolo states his ST is slower than our emulated PAL ST.

That's of course easy to verify- just run it on a normal 8.02MHz STF and see if it's stable. I've just moved house (and am additionally abroad atm) but if I remember to I can do that when I have my Ataris back up and running.

(I'm actually looking to acquire a "slow ST" for my own curiosity's sake)

[npomarede]

In pouet.net comments, paulo mentions "If you have problems in running this on your ST hardware, try the 1 byte updated version, you can find at Atari-Legend. This is caused by the different ST MMUs that control the top border openning. Both versions work fine on my 1985 ST."
Unfortunately, I couldn't find this version on atari-legend.

But from this comment, I think it's more MMU / wakeup state related (I know Paulo's ST had some problem with Leonard's fullscreen in Nostalgic-o-demo).
Maybe Paulo will read this and could tell us what was modified in the other version of Panic.

[Steven Seagal]

In pouet.net comments, paulo mentions "If you have problems in running this on your ST hardware, try the 1 byte updated version, you can find at Atari-Legend. This is caused by the different ST MMUs that control the top border openning. Both versions work fine on my 1985 ST."
Unfortunately, I couldn't find this version on atari-legend.

Based on Alien's article the different MMUs changed the lines of top/bottom border removal by something like 16, but it could have other differences.
Now that troed mentions it, it seems improbable that this demo would only run on slower STF.
We definitely should have the other version to compare.

[Steven Seagal]

I found the fixed version at atari-legend.
It hits at emulator cycle 24 so there's no chance to trigger a spurious +2 line.
I also saw that comment at pouet:

But for some weird reason it flickered like hell on my 1040 - I can't imagine what went wrong.

which may justify my approach (older, slower STF OK).

[troed]

My current explanation is CPU speed, because the routine bringing us to y-30 is a CPU-based delay loop, and in some thread Paolo states his ST is slower than our emulated PAL ST.

That's of course easy to verify- just run it on a normal 8.02MHz STF and see if it's stable. I've just moved house (and am additionally abroad atm) but if I remember to I can do that when I have my Ataris back up and running.

(I'm actually looking to acquire a "slow ST" for my own curiosity's sake)

I forgot to check, right?

"Normal" STF and all (PAL) STE: 8.02MHz
Some STF: 8.010MHz
Paulo STF: 8.007MHz

(Besides the posts in the hwtest04 thread here I'm asking anyone who sells an Atari in a popular Swedish retro group to test their hardware as well - since I want to buy a non-8.02 machine)

I specified PAL since at least one NTSC (Mega) STE is 8.05MHz but I haven't seen others post theirs to know whether it's a general difference.

"SYNC lore" knew about the different speeds. Our top and bottom border code (triggered by MFP timers) had two separate switches to accommodate real hardware we'd stumbled upon.

/Troed

[Dio]

The master clock crystal and derived CPU clock table is:

Code: Select all

PAL (all variants)	    32.084988	8.021247
NTSC (pre-STE)	        32.0424	  8.0106
NTSC (STE)	            32.215905	8.053976
Peritel (STE) (as PAL)	32.084988	8.021247
Some STFs	             32.02480	 8.0071

There aren't a lot of the 32.02480 ones around; the two I have data on are both 1040STFs manufactured at around Q2 86, probably on the rev C board, and the 1040STFs from late 86 on rev D seem to be on 32.0424. One hypothesis is that it was the standard crystal in early STF machines; the reason behind it I have no idea, since earlier modulator-less STs seem to be on the NTSC standard crystal. That's inferred from only about a dozen motherboards, mind.

STF can be seen with either PAL or NTSC crystal too.

It shouldn't (famous last words) affect the (digital) part of the video timing in the slightest; the main effects are:
- video timing in the analogue domain (the actual output frame rates and line times)
- pitch of the PSG, on non-STEs, since it's fed by a divider
- timing with the 2.4576MHz MFP clock.

I also have no indications that the clock nudger present to align the main clock with the chroma clock in ST(F)Ms and PAL STEs affects video timing at all, although I haven't been able to show on a scope the actual effect of the clock nudger yet.

[troed]

There aren't a lot of the 32.02480 ones around; the two I have data on are both 1040STFs manufactured at around Q2 86, probably on the rev C board, and the 1040STFs from late 86 on rev D seem to be on 32.0424. One hypothesis is that it was the standard crystal in early STF machines; the reason behind it I have no idea, since earlier modulator-less STs seem to be on the NTSC standard crystal. That's inferred from only about a dozen motherboards, mind.

STF can be seen with either PAL or NTSC crystal too.

Many thanks Dio - that'll help me a lot in trying to acquire one of the "slow" machines

[Dio]

I'd definitely focus on the C070523 rev C 1040STFs then.

Actually I do have a couple of theories as to why: the simplest is that Atari saw some cheap crystals that were slightly out, and plumped for 'em; another is that someone misread / miswrote the number and they ended up with a batch of the wrong crystal. 32.0424 vs. 32.0248 is pretty close after all, wouldn't have taken much for a transposition error to occur.

[troed]

Right, so, I've now acquired a "slow" (8.01MHz) ST It's a Mega ST4 - without blitter - making it an early one.

Observations so far: It seems to like WS2. Really really like. I've actually not been able to boot it into any other wakestate yet It also seems to favour a (speculation) Shifter mode that is "banded" compared to the WS2 my other 1040STFM gets into easily.

... and this is what I'm currently researching as well. Speculation:

WS2, being the wakestate with the longest DE-to-LOAD, requires an additional cycle to clear the Shifter when doing sync line tricks. This might also be influenced by the current Shifter state - and the Shifter might additionally migrate between cold/warm.

/Troed

[Steven Seagal]

Right, so, I've now acquired a "slow" (8.01MHz) ST It's a Mega ST4 - without blitter - making it an early one.

It would be cool if you could test panic.tos v1 on your slow Mega.
http://www.pouet.net/prod.php?which=14827

In this thread I mentioned various programs that caused an unwanted "+2" line on STE if we used timings of 36-40.
After some changes in Steem CPU/MFP emulation, that problem disappeared so sorry for those false alerts.

I also ran some tests on a real STE.
Conclusions:
On the STE, prefetch starts 16 cycles earlier only if HSCROLL is non null.
But the Glue makes its starting decision (threshold for +2) 16 cycles before it does on the STF anyway.
So there must be some internal registers to hold the result of this decision, as strange as it may seem.
Why not? We've already seen the same thing for # line cycles.

[troed]

I also ran some tests on a real STE.
Conclusions:
On the STE, prefetch starts 16 cycles earlier only if HSCROLL is non null.
But the Glue makes its starting decision (threshold for +2) 16 cycles before it does on the STF anyway.
So there must be some internal registers to hold the result of this decision, as strange as it may seem.
Why not? We've already seen the same thing for # line cycles.

I'm not sure I understand. The writeup I did on the STE "GLUE" and the impact of pre-fetch is "complete", I think*. What type of register would you mean is needed?

Cycle Action
0 IF(RES == HI) PRELOAD = TRUE
28 IF(RES == LO) BLANK = FALSE
36 IF(FREQ == 60) && (RES == LO) PRELOAD = TRUE
40 IF(FREQ == 50) && (RES == LO) PRELOAD = TRUE
56 IF(FREQ == 50) LINE = PAL
58 Also related to line length similar to above for 50/60Hz. Unknown cause.
164 IF(RES == HI) H = FALSE
184 IF(RES == HI) BLANK = TRUE
372 IF(FREQ == 60) && (RES == LO) H = FALSE
376 IF(FREQ == 50) && (RES == LO) H = FALSE
448 IF(RES == LO) BLANK = TRUE
460 IF(RES == LO) HSYNC = TRUE && H = FALSE
500 IF(RES == LO) HSYNC = FALSE

The following pseudo code describes how PRELOAD gets handled:

WORDS_READ=0
WHILE(PRELOAD == TRUE) {
LOAD
WORDS_READ++
IF(RES == HIGH AND WORDS_READ=>1) PRELOAD = FALSE
IF(RES == LO AND WORDS_READ=>4) PRELOAD = FALSE
}
H = TRUE

In regular HI resolution the routine will exit after four cycles (one word) and in LO resolution it will take 16 cycles (four words). This is what makes the STE timings for raised DE match up with ST.

http://www.atari-wiki.com/?title=ST_STE ... ine.2C_STE

*) "Complete" in that as in science I first formed the hypothesis, then predicted that it should be possible to create +4 and +6 lines on STE - and after that went ahead and tested those line lengths successfully based on my pseudo-code.