horizontal scrolling on ST

[npomarede]

Hi everybody,

This thread caught my attention

we need more threads like this to lure Ijor back into atari-forum

[ijor]

The trouble is the RESET circuit only resets the CPU and GLUE. There is no RESET line going to the MMU or the SHIFTER.

It is possible that it could be synthesised from other signals. Even in the Glue, there's also no guarantee that RESET is actually seen by every flip-flop. A resettable flip-flop is larger and more expensive.

Yes. SHIFTER and MMU do have hardware reset, even without a reset pin. I don't remember the details, but MMU is reset by detecting GLUE reset state, and IIRC (sorry, it was years ago since I looked into this) SHIFTER does it by the way of MMU.

And yes, of course, not every gate is reset on hardware reset. It is not just an issue of saving transistors. Some logic persists hardware reset by design. For starters, DRAM refresh must keep working while you press the hardware button. Video sync, although probably not as critical as dram refresh, is performed during reset as well.

Note that the chipset has some power up detection logic.

[troed]

So, a lot of the content from this thread (and some epic threads before it) has just gone into the presentation I held at STNICCC 2015. You can watch a recording of that talk here: https://www.youtube.com/watch?v=FJvcfjuXQVg

caveat: Yes, there are errors in the talk. Since I had to scramble with our demo release I didn't have time to verify that my recollection was correct in all cases. I might say -12 instead of -4, I might (but hopefully not) miscredit a finding.

Enjoy. And I'm truly grateful for all the information you've all contributed with - making it possible for me to have held a presentation like this in front of the people who started it all.

/Troed

[npomarede]

Hi
I had a look at the video, but it's pretty long to watch in one go , do you consider doing a summary or maybe updating the wiki with some of things you added in this presentation ? (and maybe releasing the demo Sync showed at STNICCC ? )

Nicolas

[troed]

I had a look at the video, but it's pretty long to watch in one go , do you consider doing a summary or maybe updating the wiki with some of things you added in this presentation ? (and maybe releasing the demo Sync showed at STNICCC ? )

It's one hour of pure ST awesomeness! I expecially liked when Gunstick explained that the only reason for him doing a different stabilizer was that he liked color instead of black - and that the only reason it's four cycles earlier is due to him using immediate addressing instead of registers.

Yes, I did stop updating the wiki due to not wanting to spoil some of the tricks I would use myself in Closure. It will be updated. And Closure will be released when it's ready There are a few bugfixes to make (found at the party) but since I've neglected my family due to working on the demo intensively for the last few weeks I will be doing no Atari work over Christmas.

For those of you reading this thread but weren't at the party and haven't seen the demo we're referencing, you can find a shaky recording here: https://www.youtube.com/watch?v=u8NWDJyKQ9U&t=1h40m20s

/Troed

[npomarede]

I'm planning to watch the whole presentation, just need to find some time (and volume seems a little bit too low in the recording).
I saw the party version on YT, as the binary was not released yet, I suspected you had some things to fix first (BTW, does it works with current emulator, or did you use some not yet emulated tricks ? If so, I would be interested to add support to Hatari before you release it)

Nicolas

[troed]

I'm planning to watch the whole presentation, just need to find some time (and volume seems a little bit too low in the recording).
I saw the party version on YT, as the binary was not released yet, I suspected you had some things to fix first (BTW, does it works with current emulator, or did you use some not yet emulated tricks ? If so, I would be interested to add support to Hatari before you release it)

Nicolas

The volume was really low in the original recording. My cleaned up and amplified version above is as good as it gets

I don't believe any emulator will support Closure once it's released. It'll be a fun exercise I think I've done some of the development in Hatari but then with an alternative code path while testing.

/Troed

[tin]

Here's another recording with some of the people answering and asking questions in frame. Would be probably nice to annotate who's who.

http://www.youtube.com/watch?v=xMij99FVDtA

[leonard]

Here's another recording with some of the people answering and asking questions in frame. Would be probably nice to annotate who's who.

http://www.youtube.com/watch?v=xMij99FVDtA

At 1:01:00 in the video above, Erik Simon ( famous "ES of TEX" ) made an intervention full of historical information about how TEX found some border related tricks. Really funny, priceless!

[alien]

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.

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.

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!

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).

Just for historical accuracy, I'd like to mention that the Glue state machines I published in my articles were a simplification of those I had developed. In fact I called them "pseudo-programs", rather than state-machines, and used "si ... alors" (if/then) instead of nand gates. But I mentioned equality comparison was used because it is simpler (a xor) than comparison (a subtraction). There were two reasons: first the articles were already very technical for a mainstream magazine, and I am still amazed that they agreed to publish them. The editors deserve a lot of credit! Secondly, I skipped some details that would allow others to develop a faster hardscroller for instance as I was hoping to use that knowledge in commercial software, as I had with my 6301 keyboard/joystick/mouse routines, and my fast soundtracker routines.

The relevant articles are still available at http://www.abandonware-magazines.org/ (St mag 51, 52, 55 and 70). The only issue... they're in French. You'll see an amusing cartoon on page 64 of ST Mag 51: what the editor felt like after reading my article!

I'd like to mention that I find your new Overscan routine quite intriguing... if I ever dig my ST back out of the cupboard, I'll have a play with it. Finally a question: why do you have LINE = PAL at cycle 54 in your state machines? What's it for?

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!

[alien]

(Ah, I just found your wiki. FWIW, there were 4 articles, not two)

[alien]

Gee there's a lot more in this thread since I last looked at it...

[npomarede]

I'd like to mention that I find your new Overscan routine quite intriguing... if I ever dig my ST back out of the cupboard, I'll have a play with it. Finally a question: why do you have LINE = PAL at cycle 54 in your state machines? What's it for?

Hi

"LINE=PAL at cycle 54" is the decision point where a line will be NTSC (HBL at cycle 508) or PAL (HBL at cycle 512). Changing to 60/50 Hz after this point won't affect the number of cycles in the line.
This can be an important point and lead to some problem when removing top border for example, often some demos stayed in 60 Hz for too much time between end of line 33 and start of line 34, changing back to 50 Hz when displayed already started. So the line 34 would then have only 508 cycles instead of 512.
Demos often compensate this by just adding/removing a NOP, but I can confirm it's a real nightmare to handle in emulators, because this position at cycle 54 is one of the few that requires 2 cycle precision in cpu emulation

PS : I still have the ST Magazines with your articles, I even scanned/printed them to have them handy instead of keeping a pile of magazines. That was really great articles

Nicolas

[alien]

"LINE=PAL at cycle 54" is the decision point where a line will be NTSC (HBL at cycle 508) or PAL (HBL at cycle 512). Changing to 60/50 Hz after this point won't affect the number of cycles in the line.
This can be an important point and lead to some problem when removing top border for example, often some demos stayed in 60 Hz for too much time between end of line 33 and start of line 34, changing back to 50 Hz when displayed already started. So the line 34 would then have only 508 cycles instead of 512.
Demos often compensate this by just adding/removing a NOP, but I can confirm it's a real nightmare to handle in emulators, because this position at cycle 54 is one of the few that requires 2 cycle precision in cpu emulation

Ah! That's something new to me. Thanks!

PS : I still have the ST Magazines with your articles, I even scanned/printed them to have them handy instead of keeping a pile of magazines. That was really great articles

Nicolas

Merci! Ca fait vraiment plaisir!

[calimero]

little bit a offtopic but I just stumble on this: Apple II GS compiled like sprite technique

http://www.brutaldeluxe.fr/products/cro ... pritetech/

I do not think that we can use anything similar on ST bitplanes though...

[prog99]

little bit a offtopic but I just stumble on this: Apple II GS compiled like sprite technique

http://www.brutaldeluxe.fr/products/cro ... pritetech/

I do not think that we can use anything similar on ST bitplanes though...

Nice article. Generated sprite code is used a lot on the st already.

[calimero]

^
I know that Laurent use these generated sprites in recent Falcon games (but in word-wise, chunk TC graphics mode) but how they can be used on ST with interleaved bitplanes? Is there any article about it on ST?

[prog99]

Drifting off topic but here you go(falcon) - http://www.atari-forum.com/viewtopic.php?t=24462 but if you hunt hard enough you'll find st specific.

[calimero]

^
yes, I know that thread but I can not see how you can implement anything like that on ST; on ST where you have to shifting, multiple word writing for one pixel... - there would be zilion combinations for one animation!
on Falcon it is much easier: you have one word for one pixel and you have long word inside CPU registers, it is easy to understand but ST with interleaved bit planes...

[prog99]

You've sort of guessed it. You need a separate routine for each sprite rotation. Its quite interesting to code it all up, well at least it was 20+ years ago .

[fenarinarsa]

PS : I still have the ST Magazines with your articles, I even scanned/printed them to have them handy instead of keeping a pile of magazines. That was really great articles

So did I. I kept those magazines at hand during YEARS. At the time I was hanging with the folks of NGC, and when I showed them my first screen ever they were like "how did you achieve overscan for your first screen ?" I replied that I only read ST Mag

They were actually working on an STE-compatible version of the 4-bit scroller with your help I think. It was eventually released but I can't remember in which demo...
I didn't see the point in doing that since the STE handled scrolling in hardware, it was clearly losing time in my opinion (I remember saying "just do it with hardscroll when you detect an STE" ). I was actually trying to do a lot of STE-specific effects but I felt quite alone back then.

[ijor]

"LINE=PAL at cycle 54" is the decision point where a line will be NTSC (HBL at cycle 508) or PAL (HBL at cycle 512). Changing to 60/50 Hz after this point won't affect the number of cycles in the line...
because this position at cycle 54 is one of the few that requires 2 cycle precision in cpu emulation

Just in case anybody wonders, this is why ...

As I said. GLUE’s internal logic is a bit more complex than you would think.

There is not just a single horizontal counter, but two. One controls sync, the other controls video output (DE and BLANK). The two processes are clocked by opposite edges of the 2 MHz clock.

There is one DE switch, potentially used for sync scrolling, that is too close to the HSYNC switch. You need two cycles precision (which means, btw, detecting the current wake up) to implement one switch without affecting the other.

And the reason that the 508 or 512 CPU cycles per line (PAL vs NTSC) decision is taken so early, is because this is implemented when the counter is restarted. When the counter overwraps, it's simply initialized to zero or one (the counter is clocked at 2 MHz), or another value if mono.

[AtariZoll]

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 ?

[EvilFranky]

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 ?

Yes this is very interesting!

[calimero]

Am I only one who thinks that this thread went in wrong direction. We are at some wake up states, cycles. overscan and similar.

I start to read thread from beginning recently and it definitively drifted away from original topic long time ago

Thank you for brining back thread on topic

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.

I could not agree more! I hate Enchanted Land "jumped" scrolling of screen when you are close to screen edge!

For instance Potsworth and Co.

(you never stop to amaze me with games that I never before see on ST )

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)?

What I would like here is talk about SW techniques used in it and some other games - like Prophecy, Stario Land ...

little offtopic: Prophecy is very interesting regarding quality of youtube video!
Look at this https://www.youtube.com/watch?v=tfWetomfCfE - it has really smooth scroll
and if you look at this video https://www.youtube.com/watch?v=tfWetomfCfE - it is very jerky scroll!

but real thing would be fine (1px) scroll on ST without blitter.
Maybe to start special thread for it ?

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