What is "sync scrolling"?

[Gunstick]

well I can continue on that...

How ULM "invented" the hardscroll. Well that's due to my quite old ST512+ and a Thomson color monitor. I copied the code from the CRT

Watching the Cuddly's main menu I noticed slight changes in the background color on the top border of the screen. The black shades changed when the screen scrolls. Fiddeling a bit with the setting of the monitor, those changes seemed to be affecting even outside of the physical possible screen (the 70Hz switch). Easy to conclude what was going on.

I used that monitor to check the height of various demo crew's routines. TCB's was very large, later scrolls using 8 or even 5 lines appeared.

I consider the invention of syncscroll the most important discovery of ST demo coding. There have been other tricks, but the syncscroll is ST specific. Modplayers or sprites can be used on other computers as well.

What is the most interesting use of hardware scrolling in a demo screen?
Has there been a "big sprite" demo, where one sprite is moved by hardware?

Georges

[ParaPete]

Right... I understand that the sync scrolling technique allows you to set the screen address with more accuracy than 256 bytes, allowing finer vertical scrolling, but how does this help with horizontal scrolling? (Sorry if that's a bit off topic)

Thanks,
Pete

[p01]

[edit] /!\ Ooops, what I said in this post is wrong. Shit happens. [/edit]

If my understanding of the technique is correct, the pixel precise horizontal scrolling can be achieved by increasing the frequency of the beam for a given number of cycles.

Check this table from the "Atari ST Internals":

Code: Select all

Clock cycles per line (50Hz)      : 512
NOPs per scan line (50Hz)         : 128
Scan lines per VBL (50Hz)         : 313

Clock cycles per line (60Hz)      : 508
NOPs per scan line (60Hz)         : 127
Scan lines per VBL (60Hz)         : 315

Clock cycles per VBL              : 160256
NOPs per VBL                      : 40064

Pixels per clock cycle (low res)  : 1
Pixels per clock cycle (med res)  : 2
Pixels per clock cycle (high res) : 4
Pixels per NOP (low res)          : 4
Pixels per NOP (med res)          : 8
Pixels per NOP (high res)         : 16

If we stay @ 60Hz during one scanline, we "gain" 1 NOP, which represent 4 pixels in low res @ 50Hz. Therefore we should have shifted the display by 4 pixels to the left. Staying @ 60Hz during ~32 NOPs should "gain" 1 cycle, and shift the display by 1 pixel to the left.

One thing I don't know, is how to work with some padding, that is how to have an image wider than the screen, like in the intro of BLOOD.

Can anybody correct me ? and explain how to have some padding ?

[Gunstick]

If we stay @ 60Hz during one scanline, we "gain" 1 NOP, which represent 4 pixels in low res @ 50Hz. Therefore we should have shifted the display by 4 pixels to the left. Staying @ 60Hz during ~32 NOPs should "gain" 1 cycle, and shift the display by 1 pixel to the left.

if I haven't got something wrong all those years, hardware scrolling does not at all work like this.

You can't move the screen around by 1 pixel. Only in increments of 16 pixels.
This is done by using the simple inner working of the GLUE chip.

There seem to be 2 internal clocks. One is for the display signal and the other is for sending out data to the shifter.
Depending on the frequency (50 or 60) the relative speeds differ.
E.g. if we are on 50 Hz, then at a certain point in time there is a comparison if enough time is passed to send out all data for that line to the shifter. If time's up the display enable signal is put down and the shifter only gets zeroes (we get a right border).
What happens if just in the moment where that test "are we 50Hz AND is time for line reached" is done we switch to 60Hz. Oops, the test is no more true, and the display enable is not put to zero and the shifter continues to get data... it draws a border full of grafics.

There are several other places where a fast switch 50->60->50 makes a test not work and either send out more data or stop sending data too early.

Now what happens if in a normal 320x200 screen, in one line you send more data to the shifter than should be done? The screen counter gets incremented by that amount and all the rest of the screen is in the wrong place: it moved to the left (and what was at the left reentered on the right side one scan line higher).

And that's what hardscrolling is: switching overscan on for a certain number of lines eats away data (increments the screencounter) and so you get a displacement of the screen. And that displacement is NOT a multiple of 256. In fact it can be done in increments of 2 bytes because there is a 50-60 switch which makes a difference of 1 word on the screencounter.

For more details: I guess someone else can elaborate further on this
Goerges

[p01]

Gunstick: It does not make the shade of a doubt that you are more qualified than me to talk about such advanced technique.

The message were you gave the shell script generating the table of your 5 scanlines hardscroll gives a lot of infos.

Shame on me, I thought the hardscroll technique had been pushed one step further and could offer a pixel precise control. I really had the intro of BLOOD in mind, with the veeery long ( ~1164x181 from some screenshots I just made ) HOLOCAUST logo scrolling in overscan with a precision of 1 pixel. But watching the VIDEO address in SAINT, revealled they used 16 screens of 46080 bytes each for each shift of 1 pixel. 11 years later, another mistery surrounding this demo fall apart

[Zappy]

Yeah, the 1-pixel scroller in the Blood intro just uses many screens. Nothing special in this one, sorry p01. I'm afraid we had the same hardscroll code as everybody else

We had a few fullscreen-related techniques in Japtro (like completely skipping all clipping with just an appropriate palette - i.e. something that only works in fullscreen), but I don't remember our hardscroll routine to be anything special. It was around 7 or 8 scanlines I think, I don't remember, but nothing out of the ordinary.

- Pierre

[xerud]

What is the most interesting use of hardware scrolling in a demo screen?
Has there been a "big sprite" demo, where one sprite is moved by hardware?

Georges

Paulo Simoes overscan demos shifted around a big digi pic of the earth that I can only assume was done via this technique?

[Gunstick]

So, well, as this thread resubmerged and I have no time or motivation to update my website, here are some inner workings of the Dark Side of the Spoon's Fullscreens.

Boot Intro: Moving Back
Well it's obvious that the background is scrolling with hardscroll. There are 16 screens for the shift... ermm... 16? That's not possible when it has to run in half a meg and plays a modfile and shows logos. Pause the demo and watch the background closely. It not only repeats, but every repeat is displaced by 1 pixel. Bingo, much less memory usage.
One important thing to know about fullscreen is: if you scroll out on the right, the grafics enter on the left, but on the wrong planes. So the colors don't match!
So you have to copy everything at the border by 8 bytes.
If you watch closely the right border you will notics some imperfections, it's the copyroutine. It's just not copying 100% correctly for CPU time reasons. The logos in the middle could be considered as sprites: need to restore background before drawing the next logo on a different place.


Losta scrollers: Playfield screen
well we could have added even more scollers but finally it's just 8 pixel grafics in the background.
Now this fullscreen is the "fullest" screen you can get. Good observers will notice that the top scroller is a background color scroller. So there can't be grafics in there. This means: the top border is NOT opened! Other consequence of this: we can't use the VBL and have some sync for the bgcolor scroller. How to get that stabilized: well the whole VBL is synced. There's one sync at the start and that's it.
Between the top scroller and the start of grafics is just 5 scanlines where the hardscroller (at beginning of normal screen) does his job to move the girl around.
And the music? During the short wait before the screen starts up, the music is precalculated just by playing very fast the complete song.
I don't know anymore if the left-right movement copy routine is better done than in the fullmove screen before.
I guess you all know how the repeating background is done.
The girl's strange movement is another "optimization". She sometimes moves by steps of 16 to the right and after that exactly the same distance again to the left at speed 16. That's just to avoid grafics errors if moving a different speed in one direction than into the other.
Why do we use that playfield stuff so much? Well it's perfect to fit between the left and right border switches

Mainmenu:
well nothing special. The bottom scroller was left out on purpose. More CPU left and bigger scrolling area. The lion can be moved with joystick wich needs reading the Keyboard 4 times per VBL. But the keyboard introduces random waitstates (on a real ST) so there are 4 resynchronizations.

overscan 3D
do the logo distorter while overscan and 3D while not. And silently switcht to 2 VBL for the Gunstick logo without telling.

Unlimited sprites:
5 screens in a loop. ermm... yes. it has a scroller

So that's it.





what?




ah one missing?








ok ok.

Parallax distorter
Cheat code:
push key B
push key U
release key B
push key S
release key U
push key return
release key S
release key return

Now the hardware scroller is disabled, means the screen adress is not changing anymore.
The display area is about 5 screens high.
You can check this by moving around in memory: use the keypad.
scroll up: 8
scroll down: 2
speed up: push gain
stop scrolling: 5

The scroller is displayed at the bottom of the next visible screen. If you pushed 5, you see the scroller moving down. But it only draws a small part. Needs 4 VBLs to draw one scroll line.
Unfortunately I don't remember why I draw the scroller in 4 times.
But what happens, there are 3 other scrollers drawn in parallel on the non visible screens. The whole trick is that the scrolls are 20 pixels high and that I move the screen up by 5 pixels. Just try it. Push 5 times on 8
If you don't pay attention to the grafics, you see a moving wave.
But no readable scroller.
Push 15 more times on 8 (that makes 20) now the screen rushes by at the speed of the scroller's height. The scrolls are aligned but the wave is much too fast.
How to get this correct? it's like TV tuning. Just push more and more on 8. About 13*20 times in total (there are 13 scrollers on screen, or the screen is 260 pixels high). Now the 5 screenfulls rush by in some tenth of a second. But you see then a glimpse of correctly moving scrollers.
Ermm... not really. The wave is going from top to bottom. Wasn't it bottom to top in the original screen? Let's have a look: press ESC. Yeah. Bottom up. That's because it would have been better to keep hammering 260 times the 2 key instead of 8
Oh and now for the bounce... the digisound routine is syncing the bounce so it never gets out of rythm. At the end of the gigit the bounce table is reset to beginning.
The background's bounce is twice the speed but it's distorting is half the speed of the foreground. I did that because half speed background bounce is jerky (the foreground only moves by 1 pixel, so the background would have been moving only every 2 VBLs)
There is so few memory (half meg) left that:
* the font is not preshifted and all CPU time is spend for shifting
* the scroller is 20 pixels high instead of usual 32 because there is not enough CPU. I checked first how much CPU it takes, then asked to get a font of that height. And anyway, a 32 pixel font would have used too much RAM.
* the sound sample is compressed and has 2 parts: part1, part1, part2, part2. The sample is decompressed in realtime from 4 bit to 8 bit. It is played on 2 instead of 3 volume registers. It uses a custome volume conversion table to give the sound the best boom, bang and hiss
From the comments I think it's the table from 68000 ST-Magazin or at least it's based on it.
* the rest of the CPU is burned with lots of NOPs

Any questions?
Georges

[ggn]

Questions? Well, do you want the nobel prize now or when is it comfortable for you?

Makes me grateful I didn't study the sources of DSOTS I have, otherwise, I'd be in a hell of trouble trying to figure it out

Main menu:

So what you're saying is that you use a background of (for example) 33x32?? If that's the case, it's a very clever idea BTW I've noticed those copy imperfections a long time ago, but I just thought that my old TV was at fault

Parallax dist:

Ummmm.... yeah.... eeerrr..... how much time did it take you to develop this screen? Most of the stuff you describe there are SO advanced and radical! I don't know if I ever would think half of these

(otherewise speechless) George

[Gunstick]

Questions? Well, do you want the nobel prize now or when is it comfortable for you?

didn't you know that I had that already

Mainmenu:

So what you're saying is that you use a background of (for example) 33x32?? If that's the case, it's a very clever idea BTW I've noticed those copy imperfections a long time ago, but I just thought that my old TV was at fault

You mean the intro scren, not the mainmenu.
The background is in fact 32*32, but the grafics is drawn in such a fashion that the left and right sides match but the bottom half does not match the top half exactly. It matches by 1 pixel off. So to plaster the screen full of tiles you have to adjust each row by 1 pixel.
I think that's a "classic" trick. I'm shure many other people used it as it's quite obvious thing to do.

Parallax dist:

Ummmm.... yeah.... eeerrr..... how much time did it take you to develop this screen? Most of the stuff you describe there are SO advanced and radical! I don't know if I ever would think half of these

I think it took half a year (fulltime job: I would guess 200 hours). During that time Christian coded most of the spoon demo and I just had one screen. I was more the behind the scene worker doing hardscroll, overscan, sound compression and so on. In fact I just crammed everything I could do into one screen.

I still remember when I demoed a preview of the parallax dist at a party in Marseille. There was no clear screen before the scroll came in so one could very easily see the trick. What I did is I jumped in front of the TV to cover it up until all the scrollers were on screen. Funny.

Unfortunately I could not find the version I demoed at the party.

But I luckily recovered the first ever source code of the screen (version 001). Cool. It's just an empty screen with a hardware scroller. The code to move the screen around is already there and it made it into the final version as you have noticed.


Georges

[ggn]

didn't you know that I had that already

Damn!

You mean the intro scren, not the mainmenu.
The background is in fact 32*32, but the grafics is drawn in such a fashion that the left and right sides match but the bottom half does not match the top half exactly. It matches by 1 pixel off. So to plaster the screen full of tiles you have to adjust each row by 1 pixel.
I think that's a "classic" trick. I'm shure many other people used it as it's quite obvious thing to do.

Sorry, but work & reading heavy technical atari stuff at the same time don't mix, hence referencing the wrong screen

Ok, I think I got it now.

I still remember when I demoed a preview of the parallax dist at a party in Marseille. There was no clear screen before the scroll came in so one could very easily see the trick. What I did is I jumped in front of the TV to cover it up until all the scrollers were on screen. Funny.

Unfortunately I could not find the version I demoed at the party.

But I luckily recovered the first ever source code of the screen (version 001). Cool. It's just an empty screen with a hardware scroller. The code to move the screen around is already there and it made it into the final version as you have noticed.


Georges

Goes to show, showing previews is a bad thing

George

[leonard]

You can't move the screen around by 1 pixel. Only in increments of 16 pixels.

Gunstick is right, hardscroller is 16 pixels only.
Anyway if you're a technic fanatic, Alien/STCnx did a real 4 pixels hardscroller (using strange shifter behavior). The technic only works on STF ( but who needs trick to do pixel scroller on STE ? ) and you can watch the ONLY demo featuring 4bit scroller in the ST-Cnx screen of the "Punish your Machine" demo by Delta Force.
Please note that 4pixels hardscroller is emulated on SainT and you can watch the great Alien demo.

[Gunstick]

wasn't the 4 pixel scroller just an 8 pixel scroller in medium resolution? At least at the time I concluded on that.

Georges

[unseenmenace]

Alien describes how it works in the scroller. If I read correctly you switch to medres for a while after opening the left border to slightly delay the shifter from starting drawing then back to lowres. Its all a bit beyond me but the screen itself can't be in medium res cos there's 8 colors in the sprites.

[doggyfred]

Alien describes how it works in the scroller.

For anyone who can read French, the technique is also explained in the series of articles entitled "Les techniques de l'overscan" written by Alien for the French magazine ST-Mag, starting around issue #51, if I remember correctly. I am not aware of any translation available online anywhere. It is definetly a low-res effect.

[ljbk]

The idea of the 4 bit scroller is to confuse the shifter in order to let us decide which word of the screen data shall be used as bitplane 0 to draw the next 16 pixels.
The shifter reads 1 word while drawing 4 pixels, but the word will be used to draw some other pixels later.
If you have ever tried the several combinations to reach a minimum number of lines to do a sync scrolling, you have probably noticed that sometimes the resulting "normal" screen starts 8 pixels earlier or 4 pixels earlier or at normal time or you get a big flicker. This was what i did find already in 1990 as you have plenty of time spots to try to confuse the shifter. The problem is that there are a lot of ST different shifters/MMUs.
For example i can have a 0 bytes line (no data is read from memory)working on my STF, but this does not work on all STs.
This was the reason why for the Overscan demos i only used the normal sync switches for left and right border do do the hard scroll, so i needed 15 lines because i was afraid that the demo would not work on other STs. In fact you can do it with 5 lines + the sync line or even one line less like in YM50K ...
But regarding the 4 bit scrolling, the problem is that there is 1 combination missing to get the 4 bit scrolling and that is to have the screen start 12 pixels earlier or 4 pixels later.
Alien found a way to do it nicely that is the following:
- when going back from high res for the left border removal, do not go to low res but to medium res
- now depending on the time (number of nops) you wait to go back to low
res, the screen will be shifted 0, 4, 8 or 12 pixels (you can use different timings from the ones used by Alien)
But this does not work on STE, as Leonard told me when he tested a few test programs i sent to him and it only works with a fullscreen line (no left and no right border).

I have a nice screen working on STF that would be impossible for the same amount of memory without that trick.
If i have time i will try to do a STE code path for it using the STE HW using Steem as STE as i only have an STF so that anyone can have a look at it and so that there is at least a second screen using this trick.

[leonard]

Hi Paulo, you are a fullscreen specialist

In fact you can do it with 5 lines + the sync line or even one line less like in YM50K ...

I'm interested by that. Here are my conclusion ( I rewrite my syncscroller table finder recently). When you said 5 + 1 sync, you have to read the syncscroll table for the sync line, right ? ( I mean, in the sync line, you have to do something or nothing, depending of the table). That's how is done ULM syncscroller. In a way, this is a 6 lines scroller (not 5). But anyway every other group never count the synchro line so other people are lying on the number of line too

But my question: when you say "even less in YM50K", does that mean you are using less than 6 (5+1) line just because it's a vertical scroller or is there some new tricks ?

[ljbk]

Hi Leonard, you are the 16x16 sprite master !

That's right, for vertical scrolling of a non fullscreen pic, one needs only half of the sync line + 4 complete lines as in YM50K because you need only 8 word offsets out of the 128.
If the scroll speed is bigger you may need less lines (0 in case the speed is 8: i used this in my first ever demo that almost no-one has seen except may be TEX or TLB (you can check the reference in Maggie2) back in 1989. Then i noticed that TCB did the same in the Union Demo screen TCB 1).
You can also use less lines if you use several screen buffers like for the horizontal hardware scrolling.
For all other cases, you should need the complete 128 word offsets, so you need 1 line more: half of the sync line + 5 complete lines.
The less word offsets you need, the more screen buffers you use and the more sync switches points you use, the less lines you need for sync.

But don't forget that the resulting image has to be stable for the dozen of MMU/Shifter versions used by the millions of Atari STs ...

[Gunstick]

I read in the comment of the ULM routine this:

; 6 lines hardscroll 24 sep 1990
and that's using also some switches in the sync line.

and in another source this:

; 5 lines hardscroll 11 feb 1991

But that is obviously for a scroller of a non-fullscreen. There's a comment indicating that it needs a 6th line in overscan for sync reasons. In result: no effectively 5 lines scoller from ULM.

George

[alien]

Frost of Sector 1 and I translated the first of the 3 "Overscan Techniques" articles for the last revision of "Alive!" magazine. It's online here:

http://alive.atari.org/alive9/menutext.php

I haven't yet translated the other ones...

[ljbk]

Hello Sengan,

nice to read from you again !
It is the first time i ever seen your article.
I have 3 comments:

- my STF, from 1985, only displays 46 lines for the lower border: this was checked with the reached video counter address. It displays 29 lines for the upper border.

- MFP handling also has another problem: it has a separate clock from the CPU and the 68000 does NOT have the same frequency for every ST: 8007100 for mine but 8021247 for most: this is most probably the reason why the ULM fullscreens in the Dark Side Of The Spoon flicker on my STF . I discovered this clocks problem back in 1990 as i tested my Earth screen on a friends ST before the launch of the Overscan Demos: it was not working . So i built a rudimentary sync method between the CPU and the MFP timer (started at a specific time in the lower border) to manage to have the upper border removal to work on more STs for the Overscan Demos. I never thought about the HBL interrupt at that time.

- 68000 instructions resulting in a number of cycles not multiple of 4, like EXG, can have impact on the following sync switches like the right border one: that is why the NOSTALGIC main menu does NOT work most of the times on my STF (in some lines the instructions preceding the right border sync switch have an execution time that is not multiple of 4 cycles)... But other fullscreens do. It depends on how my STF "wakes up". There are several states for my STF "waking up" leading to perfect overscan and SPECTRUM 512 pics or defect overscan or defect dots with SPECTRUM 512 or both: i assume that this is a synchronization problem between the several HW elements of the ST: MMU/GLUE and Shifter.

Have fun,
Paulo.

[ijor]

Very interesting comments from the fullscreen hard-sync experts. I think I never learned so much about this topics.!

- MFP handling also has another problem: it has a separate clock from the CPU

Hmm, the MFP has the same clock source as the CPU. Might be you mean the MFP timers clock? MFP timers use a separate crystal, but only used in delay mode, not in Timer B count mode .

There are several states for my STF "waking up" ... i assume that this is a synchronization problem between the several HW elements of the ST: MMU/GLUE and Shifter.

Very interesting. Indeed could be that some components have a non-deterministic power-up state.

Note that an ST has several well known non-deterministic aspects. Separate crystal for the MFP timers. Separate crystal for the IKBD HD6301. Plus, obviouslly, mechanical variations of disks (both hard and floppy disks). But none of these would explain different "power-up states".

[leonard]

that is why the NOSTALGIC main menu does NOT work most of the times on my STF (in some lines the instructions preceding the right border sync switch have an execution time that is not multiple of 4 cycles)...

yep I remember how you helped me to find why that *damned* fullscreen code does not work on your ST ( and all my other fullscreen worked !!). It's from a strange combination of 6 cycles multiple instructions, and the effect produce only on very few STF.

Fullscreen is really a black art !

[Gunstick]

I still remember when I demoed a preview of the parallax dist at a party in Marseille. There was no clear screen before the scroll came in so one could very easily see the trick. What I did is I jumped in front of the TV to cover it up until all the scrollers were on screen. Funny.

Unfortunately I could not find the version I demoed at the party.

eureka! I found a box labeled ULM and in there were tonns of floppy disks. One of them said: megadistorter v35 (marseille)
So here it is, the exact thing appearing on the TV screens at the NeXT convention in Marseilles. Have fun.

Georges

[ljbk]

Hmm, the MFP has the same clock source as the CPU. Might be you mean the MFP timers clock? MFP timers use a separate crystal, but only used in delay mode, not in Timer B count mode .

Yes, i mean a separate crystal to have the correct Baud rates.
When using the MFP to remove the upper border you have to use it in delay mode.
As the CPU clocks are not identical from ST to ST, the small difference can lead to have the timer delay interrupt to occur around 32/36 cycles too early or too late. On top of that you have the natural interrupt jitter. You will most probably then have flickering as you will not open always the top border unless you do something against this due to the minimum time frame you have to open the top border.
In the Overscan Demos i did a timer test before setting up the fullscreen to have a variable (dbf loop count) that will control some waiting time that will be dependent on the HW. And before that i sync with the MFP by reading the delay counter to reduce the interrupt jitter to a minimum before stoping the timer.