horizontal scrolling on ST

[christos]

I wouldn't worry about these videos. They are captured so badly that you can't really understand performance. This is much better

https://www.youtube.com/watch?v=omvWvM3svv8

[AtariZoll]

Usually, when it is recorded on PC with emulator video is jerky. Sometimes capturing from real Atari is not done properly.

[AtariZoll]

in Potsworth screen is scrolled by 4 pixels so all tiles are preshifted two times (right?) and game area is small enough so entire screen can be build from scratch every frame (blited all tiles, than sprites to screen memory from preshifted tiles in memory)? Is it 25fps (I would say so from youtube video)?

Yes, it works that way, as I seen some code segments. Actually, 4px scroll means 4 phases, since Atari ST low res is 16px based - 8 bytes for 16px in 4 bitplanes, 2-2-2-2 bytes. But some have 1px scroll if I saw it properly - like Terry's Big Adventure .
If there is no much different object/tile on map, all it can be preshifted in 16 phases, and can fit in 512KB.

1px scroll - you can not use preshifting technique since there will be no enough memory, right?

See above. With 4MB RAM you can store complete level bitmaps in 16 phases in RAM. I did it with Hard 'n' Heavy.

[troed]

Hi Troed,

I enjoyed your presentation. I wish I could have come to STNICCC... You mentioned you wanted people to jump in with details, so here are the first to come to mind.

Hi Alien! Awesome to have your presence here. I'm very sorry it has taken me a while to respond - I simply used up all available retro time finishing Closure and work & family has needed my full attention until ... well, now.

I believe I mentioned wake states in my articles. I thought it was to do with a "desynchonization of the MMU, the Glue and the Shifter", although some machines never displayed identical problems, suggesting a difference of silicon revisions. But, Paulo & Ijor have certainly deepened our understanding of it since.

I've only ever read the two articles that were translated in the Alive magazine, so anything you wrote in the other two I don't know anything about And yes, your descriptions are what made it obvious to me that we were talking about state machines and so everything that had ever been written about "switches" was likely to be wrong. If you look at discussions on emulator development mailing lists it's often posed as "can a right border be opened at cycle X? All demos do it at Y" or "Hmm this demo doesn't switch back to 50Hz and yet expects the lower border to open as well" (SYNC SNYD2 screen btw) etc. All those questions were simply answered by documenting the state machine(s) in more detail.

Also, I did notice the shifted bitplane problem. In fact it was understanding that that lead me to 4bit hardscrolling: I tried it first with non-full-screen images but I couldn't get to work stably for all wake-states and all offsets. That failure lead me to try to recreate the effect in overscan, which took quite a bit of lateral thinking!

Aha! Thanks - and well done for getting the technique into a demo. Redhead/SYNC was on the same track but as with (almost) everything SYNC ever made, "if it wasn't released it doesn't exist"

You have "res == lo" in some of your the state machines, but it would be better res != hi (since the state machine is the same in both low and medium resolution).

You're right, of course. I'm sure there are many such updates that should be made (and anyone is free to make them - I used the wiki for precisely that purpose)

Thanks again, for your presentation. It's wonderful this problem is still interesting to people. And thanks to tin for the other recording. I haven't "seen" Gunstick or ES in a long time. I always wondered why Gunstick used a medium resolution stabilizer!

... and now we know Amazing, actually. Both the Ilja and Gunstick stabilizers managed to do the job in all (GLUE)-wakestates and (Shifter)-substates without actually being tested on the number of machines I would've guess would be needed.

My "new & optimized" fullscreen scanline has its fair share of issues (one I knew about when releasing it, see separate post I'm going to make after this one) and some I didn't know about but others have seen. And I tested it on _many_ machines and in all states I could get them into. But maybe, in another ten years or so, the state of the art when it comes to fullscreens have advanced yet again

/Troed

[troed]

"every other 16 pixels black" (actually, border color, but let's refer to it as black)

The famous instable Shifter mode, as seen as in the Omega fullscreen, TNT Crew DOTLB, Closure (sometimes .. ) etc. While researching for my optimized fullscreen scanline the big difference between the naïve version;

0: HI
8: 50Hz
16: LO
376: 60Hz

... and the version that is (with wakestate-dependent modification) in Closure:

0: HI
8: MED
16: LO
24: 50Hz
376: 60Hz

... is that the naïve version (while GLUE statemachine compliant) displays "bands" (every other 16 pixels black) in some wakestates or "sub-wakestates" (Shifter being cold, warm or just moody) but the released version doesn't. (Well .. sometimes it does. When releasing the demo I thought it was fully stable on STE and fully stable in 3 out of 4 ST wakestates, and sometimes in the 4th, but now I've heard that isn't always the case .. but I digress).

So. Shifter. The cause for this banded mode - which is what caused Paulo to have to have a key press in his non-fullscreen 4 pixels syncscroll routines to switch between two different unstabilizers - is what I've been looking at doing something about. It obviously is something related to the Shifter (IMHO) and it's something that's very very borderline. Sometimes it really looks to be stable, "every other", but sometimes - as you can see in the videos I showed at the end of my STNICCC talk - it depends on chip temperatures, memory addresses being displayed (!) etc. I fully believe this is the ST equivalent of something like the C64 VSP issues.

We know about (GLUE) wakestates thanks to Ijor and Paulo, and the fact that we can detect different line lengths when manipulating the GLUE. Detecting what the Shifter does is however something completely different. GLUE outputs signals to other chips, Shifter outputs ... data, on the RGB or Mono lines. IMHO the two hypotheses for why "every other .. " happens are:

1) The Shifter fails copying the IR registers to RR
2) The Shifter fails reading memory data into IR registers

When thinking about this I've had in mind that the equivalent for "every other .. " in Mono (yes it exists) is that every _fifth_ word is black.

It's been my hope that #2 would be detectable, by "snooping the bus", to see if it contains image data or not. "Snooping the bus" can be done in various ways, and I've been able to do it on ST (no matter the amount of memory) and STE (unless fully RAM populated). Unfortunately, no matter which method I've used all my tests have come back with the supposed image data even though black has been displayed.

So, I'm reporting the failure in the hope that someone much smarter than me can come with additional insights Maybe it's possible to detect in software, maybe it isn't. Being able to detect when it happens would open up the door to more advanced sync tricks.

The following is a link to a video with a run of the test program I've used. It fills the screen with a bitmap consisting of all 1s (with color white) and then forces the banded state by opening the left border, going to medium res for a certain amount of cycles and then back to low. At the end of the scanline is a regular right border with a Level 16 stabilizer. Everything the program does fits on one scanline - nothing is done at all for the rest of the screen. The ST is in wakestate 2, and was warm when I shot the video.

Total mayhem As you can see, there's a pattern to the madness though. Which I find quite fascinating.

https://www.dropbox.com/s/b87xsoh9hgwm6 ... s.mp4?dl=0

/Troed

[TheNameOfTheGame]

Am I only one who thinks that this thread went in wrong direction. We are at some wake up states, cycles. overscan and similar.
All it may be interesting for some demo, but for real SW horizontal scroll is something else.
Example: Enchanted Land is considered as game with very good scroll on ST, but that's total wrong. Only init animation is with good scroll, while gameplay scroll is poor, and we have many better examples. For instance Potsworth and Co.
What I would like here is talk about SW techniques used in it and some other games - like Prophecy, Stario Land ...
So, no STE HW scroll, no blitter, just 68000 code.
I working currently on improving Uridium - with better scroll, and more important faster ship turn and acceleration. it has some interesting solutions for scroll - and is from 1986 . Will first make blitter scroll version, but real thing would be fine (1px) scroll on ST without blitter.
Maybe to start special thread for it ?

Wow I love the scrolling in Potsworth. Never knew about that game before so thanks.

Question: If it is using 4-bit sync scrolling, does that means all WUS can be deterministically dealt with? Or is it using 4-bit non-sync scrolling?

[AtariZoll]

Wow I love the scrolling in Potsworth. Never knew about that game before so thanks.
Question: If it is using 4-bit sync scrolling, does that means all WUS can be deterministically dealt with? Or is it using 4-bit non-sync scrolling?

There are bigger gamers than me, who pulled out this later ST game from dust And I liked it.
No 4-bit sync scrolling. Game has relative big levels, so BMP of it would not fit in RAM. There is clean way, without tricks to achieve good scrolling, and not only horizontal, but vertical too. Calimero described it briefly. Code practically draws background at every scroll from "scratch" - all objects and walls, etc. Called tiles usually. There is not so much of it on 1 level (walls consist of repeating bmps), so you can hold all it in RAM in 4 preshift phases + map description data, what says what tile to draw on which pos. With good code - what is longer for speed it works pretty fast, so may get 25 fps with scroll of 60-70% of screen.

[calimero]

Here is another game with nice scroll: Pegasus

https://www.youtube.com/watch?v=w7z0qB5P1OU

[troed]

Since some of the technical discussions on GLUE/Shifter manipulation aren't of the horizontal scrolling kind I've started a new thread dedicated to such topics instead: http://www.atari-forum.com/viewtopic.php?f=16&t=29578

(Please help me in moving over the "every-other-16-pixles-blank" topic there as well - no replies since I posted about it above. It's, iMHO, the current cutting edge of research and I'd love to hear the opinions of others on it)

/Troed

[EvilFranky]

Just come across another game that could have been better scrolling wise. Midnight Resistance, it scrolls like Giana Sisters, player moves to the edge of the screen and it shifts the whole screen to reveal the next area. Horrible. Good game otherwise.

[larsbrinkhoff]

Thanks to NoCrew's 4 pixels raster-trick (ADD/MOVE*) it's indeed possible in special cases to switch back'n'forth in four cycles.

I must put an end to this rumour that NoCrew ever did something useful. The technique was discovered by TOS-Crew.

[troed]

Thanks to NoCrew's 4 pixels raster-trick (ADD/MOVE*) it's indeed possible in special cases to switch back'n'forth in four cycles.

I must put an end to this rumour that NoCrew ever did something useful. The technique was discovered by TOS-Crew.

Oh I have fond memories of a NoCrew party ... But thanks for the correction, will update my writings from now on.

(And I regularly use it while sync-trick-probing. addq.b #2 and clr.b respectively followed by a move)

/Troed

[AtariCrypt]

I working currently on improving Uridium - with better scroll, and more important faster ship turn and acceleration. it has some interesting solutions for scroll - and is from 1986 . Will first make blitter scroll version, but real thing would be fine (1px) scroll on ST without blitter.
Maybe to start special thread for it ?

How's Uridium coming along mate?

[AtariZoll]

Not much time last months. Hopefully will be better in colder days.

[AtariCrypt]

Not much time last months. Hopefully will be better in colder days.

Willing you on mate. Beta tester awaits also....
Steve

[fenarinarsa]

I just found a very old screen completely by chance (I knew it existed but couldn't remember where and when it was released) : the New Generation Crew screen in Delirious Demo 4.

I remember that Biggles (the coder) tried very hard to make the 4-bit syncscroll technique to work on STE because it wasn't the case in Punish Your Machine. It seems that it's the case for this screen.
The source code can be found in the Delirious Demo 4 archive here https://github.com/ggnkua/Atari_ST_Sour ... src/NGC.D4

I don't really know if it's a 4-bits synscroll, as I don't know the actual technique.

I just know that he got some help from a member of ST Connexion at the time and that I asked him what was the point in losing his time over a technique that's completely useless on STE. Didn't make him happy. :p

[AtariZoll]

I just found a very old screen completely by chance (I knew it existed but couldn't remember where and when it was released) : the New Generation Crew screen in Delirious Demo 4.
I remember that Biggles (the coder) tried very hard to make the 4-bit syncscroll technique to work on STE because it wasn't the case in Punish Your Machine. It seems that it's the case for this screen.
The source code can be found in the Delirious Demo 4 archive here http://freddo.chez.com/Sources/Sources.html (MCS part)
I don't really know if it's a 4-bits synscroll, as I don't know the actual technique.
I just know that he got some help from a member of ST Connexion at the time and that I asked him what was the point in losing his time over a technique that's completely useless on STE. Didn't make him happy. :p

Interesting . I guess that he just wanted that it work on STE. Instead using/doing STE HW scroll based one. But, since video chip is different in STE, that syncscroll just wont work. That would be case of having fun instead thinking

[fenarinarsa]

Interesting . I guess that he just wanted that it work on STE. Instead using/doing STE HW scroll based one. But, since video chip is different in STE, that syncscroll just wont work. That would be case of having fun instead thinking

Well, if my memory's right it really works, that's why I pointed to the source code for the specialists to check if it's a real 4-bit scrolling. I just had a quick look and didn't see any STE HW scroll register used.

But I know they had issues with the STE of another member, the timings didn't work on this specific STE and it they went crazy about it. At one point I told them "just use the STE hardware scrolling when you're on STE"

Back then I was a beginner in asm and I tried to use STE extended capacities but I was surrounded by STF coders that didn't care. I didn't get a lot of support from them and it was my little payback

[troed]

(There's no problem making an STE compatible 4 bit sync scroll that I know of)

[Steven Seagal]

It is the "4bit" technique, with some different timings maybe. Tends to produce Shifter bands on my STE.

[slingshot]

Hi!

Reading through some of the explanations in this thread about STe pre-fetching made me wonder about some things. As I'm writing a Verilog implementation of the GST MCU from the supposed to be original schematic, I discovered that the pre-fetching only happens when the horizontal scroll register != 0. If it's 0, then DE activated later, and no LOAD to the shifter issued before the "real" first word is fetched. Then I read that pre-fetching made the left border removing tricks fail, but studying this part of the STe schematics, I have no idea why.
Even this wiki: http://www.atari-wiki.com/index.php/ST_STE_Scanlines
says, H=1 at cycle = 4 on ST, and at 0+4 (after prefetch) on STe. But if hscroll=0, there's no prefetch, and DE (H) is delayed (by one 2MHz cycle in 71).

What I'm suspecting that the ST uses the other edge of the m2clock for deciding to turn on/off HDE, the CPU just sets back to PAL mode a bit earlier than the check on the STe happens (STe uses 2 counters, and they're using different edges of the m2clock). That makes the two counters phase differing in 2.5 8MHz cycles.

Or another (more plausible) theory: the DE is delayed by one cycle, however the check about the syncmode happens when the prefetch supposed to happen. So even the display starts at cycle 4, the mode must be switched at cycle 0. Mode switch at cycle 4 won't have the desired effect.

[slingshot]

Attached a simulation capture, when I triggered mono mode change. I almost missed the appropriate slot here (the check happens when hdec=2, however DE is delayed until reaches 4 - with prefetch, it would activated at hdec=3, and the first LOAD (dcyc_n) would happen at 4 instead of 3)

gstmcu1.png

[Cyprian]

just to let you know, Smonson has similar project.
You can read more there "Project: HDMI/DVI out for STFM": https://www.exxoshost.co.uk/forum/viewt ... f=29&t=330

[slingshot]

I read about it, my project is not really about replacing the chips in the original machine, but to put the whole machine into one FPGA. Actually I also have a Shifter implementation, too (based on ijor's description and schematics), hope it will run Closure one day

[Cyprian]

cool