What is "sync scrolling"?

All about ST/STE demos

Moderators: lotek_style, Mug UK, Moderator Team

Zappy
Retro freak
Retro freak
Posts: 13
Joined: Thu Feb 10, 2005 3:43 pm
Location: Zürich (Switzerland)
Contact:

Postby Zappy » Mon Feb 21, 2005 8:36 am

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 :D

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

User avatar
prog99
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 119
Joined: Thu Jun 19, 2003 8:08 pm
Location: Edinburgh
Contact:

Postby prog99 » Thu Apr 14, 2005 3:33 pm

Gunstick wrote: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?
All my real skills are undervalued

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

A little excursion into DSOTS

Postby Gunstick » Thu Apr 14, 2005 9:16 pm

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

User avatar
ggn
Atari God
Atari God
Posts: 1258
Joined: Sat Dec 28, 2002 4:49 pm

Postby ggn » Fri Apr 15, 2005 6:05 am

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
is 73 Falcon patched atari games enough ? ^^

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Fri Apr 15, 2005 5:36 pm

ggn wrote: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 :lol:

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

User avatar
ggn
Atari God
Atari God
Posts: 1258
Joined: Sat Dec 28, 2002 4:49 pm

Postby ggn » Mon Apr 18, 2005 8:26 am

Gunstick wrote:didn't you know that I had that already :lol:


Damn!

Gunstick wrote: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.

Gunstick wrote: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
is 73 Falcon patched atari games enough ? ^^

User avatar
leonard
Moderator
Moderator
Posts: 660
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Mon Apr 18, 2005 12:21 pm

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.
Leonard/OXYGENE.

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Mon Apr 18, 2005 5:14 pm

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

Georges

User avatar
unseenmenace
Atari God
Atari God
Posts: 1962
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Mon Apr 18, 2005 6:52 pm

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.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
doggyfred
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 144
Joined: Fri Jan 07, 2005 5:59 pm
Location: St John's, Canada

Postby doggyfred » Mon Apr 18, 2005 6:58 pm

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.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Postby ljbk » Tue Apr 19, 2005 9:31 am

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.
Last edited by ljbk on Tue Apr 19, 2005 2:33 pm, edited 2 times in total.

User avatar
leonard
Moderator
Moderator
Posts: 660
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Tue Apr 19, 2005 12:39 pm

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 ?
Leonard/OXYGENE.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Postby ljbk » Tue Apr 19, 2005 2:24 pm

Hi Leonard, you are the 16x16 sprite master :D !

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 ... :wink:

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Tue Apr 19, 2005 6:57 pm

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

User avatar
alien
Atari maniac
Atari maniac
Posts: 97
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Overscan Techniques article

Postby alien » Tue Apr 26, 2005 2:50 am

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...
Alien / ST-Connexion

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Postby ljbk » Tue Apr 26, 2005 10:39 am

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 :cry: . 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 :x . 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)... :cry: 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.
Last edited by ljbk on Tue Apr 26, 2005 6:42 pm, edited 1 time in total.

ijor
Hardware Guru
Hardware Guru
Posts: 3960
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Tue Apr 26, 2005 4:09 pm

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

ljbk wrote:- 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 .

ljbk wrote: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".

User avatar
leonard
Moderator
Moderator
Posts: 660
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Tue Apr 26, 2005 4:19 pm

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 ! :-)
Leonard/OXYGENE.

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Tue Apr 26, 2005 5:54 pm

Gunstick wrote: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
You do not have the required permissions to view the files attached to this post.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Postby ljbk » Tue Apr 26, 2005 6:38 pm

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.

User avatar
leonard
Moderator
Moderator
Posts: 660
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Tue Apr 26, 2005 6:38 pm

cool ! works very well on SainT. anyway the sound is not as good as your final version in the DSOTS. do you know why ?
Leonard/OXYGENE.

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Tue Apr 26, 2005 7:00 pm

leonard wrote:cool ! works very well on SainT. anyway the sound is not as good as your final version in the DSOTS. do you know why ?


Because I worked more on the sound....
Ha ha ha....

Ok. The reason is that some parts of the code did not have yet the replayroutine added. So you hear a 50Hz disturbance. Especially noticeable with this sample. I think in the final demo there are only a handful scanlines without sample replay. I am quite a quality freak in this.

BTW, my best sound demo is in the ULM new year demo. Have a look (or rather an ear).

Georges

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Postby ljbk » Wed Apr 27, 2005 12:29 am

After having read about it a lot, i found the ST magazine articles written by Alien in issues 51, 52 and 55. Scans of these magazines are available in the web at http://didier.letot.club.fr/St%20mag%20page%202.htm .

According to those articles the "power-up states" are related to the MMU deciding which memory cycle(s) is(are) for the 68000 and which is for the Shifter and for the STE which is for the sound DMA out of the 4 base CPU clock cycles. Some combinations are less likely than others.
That looks really possible considering the results i can observe on my STF of these different "waking up states".

Considering the amount of things i have done on my side on this subject, the articles are almost complete except for:
- line disabling sync switch: 60/50 switch per line that disables the display while memory is still read working on STF and STE (used in the Overscan Demos)
- impact of the EXG type of instructions (with number of cycles not multiple of 4)

Gunstick
Captain Atari
Captain Atari
Posts: 289
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Wed Apr 27, 2005 6:07 am

ljbk wrote:- line disabling sync switch: 60/50 switch per line that disables the display while memory is still read working on STF and STE (used in the Overscan Demos)

I never found any use for that switch. What did you use it for?

George

User avatar
alien
Atari maniac
Atari maniac
Posts: 97
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Postby alien » Wed Apr 27, 2005 6:59 am

ljbk wrote:Hello Sengan,

nice to read from you again ! :)

Thanks. Btw my email address has changed. I'll have to find yours and send it to you.
ljbk wrote:It is the first time i ever seen your article.


Thanks

ljbk wrote:- 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.


Yes I screwed up the counts in the article.

ljbk wrote:- 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 :cry: . 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 :x . 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.


I solved the problem in my game (never finished...) by having everything self-time to the computer you were using:
- MFP for top border
- left / right overscan
- lower overscan

Basically the computer searched for the right timings for every border (which was how I originally figured out overscan in the first place). Like that I could check whether the computer supported a form of overscan and only fail if it didn't. The only thing that wasn't done dynamically was the stabiliser. I noticed my shifter had different behaviour when it was a hot day, but this code would cope with that too.

ljbk wrote:- 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)... :cry: 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.


The 6 cycle thing is interesting. On my ST they were always rounded up to the nearest multiple of 4, but mine was from 1987. I did get the odd Spectrum 512 distortion though depending on when I turned it on. Basically it sounds like an MMU problem because the MMU would have to hold the 68000 off from fetching instructions from memory during the non 4x cycles. I started coding a 68000 in verilog just to see, and a simple implementation would need to access memory on cycle 0 for instruction fetch and on cycle 2 for data fetch (16 bits). 32 bit accesses would be on cycles 2 and 6. Therefore if the 68000 accessed data on cycle 6 but not 2, the MMU should delay the response... but perhaps they forgot to do that on early MMU's.
Alien / ST-Connexion


Social Media

     

Return to “Demos - General”

Who is online

Users browsing this forum: No registered users and 10 guests