More vertical scrolling questions

[darklight]

Hi,

I read the other thread about a vertically scrolling shootemup. I'm particularly interested in how to do the hardware scrolling, but I have more constraints. I want my code to:

- Work on all STs (no STE, no blitter)
- 'Hardware' scroll between two screens stacked on top of each other

I think I get the logic behind this - reserve two screens right next to each other in memory, and I guess I can inc/dec the position of the screen pointer by multiples of 320 pixels to scroll up or down. I'm very confused on how to actually do this though. Its been far too long since I played with STOS, looking a the manual again I dont really understand the different screens (logic, physic etc). And someone recommended double buffering - how would this work?

If anyone can give me some pointers to figure this out I'd appreciate it.

[seedy1812]

I think you have forgotten that the STE has hardware scrolling and the previous ST's did not.

[darklight]

Ok perhaps hardware scrolling is not the exact phrase, hence I used the quotes. I believe that this simple scrolling trick I outlined above works on all STs. Nothing is actually being scrolled, the screen memory pointer is just being moved - a much less processor intensive operation.

[prog99]

Screen pointer has to be on a 256 byte boundary so your cunning plan wont work.

[darklight]

Yikes have I had a wrong assumption all this time?

A google session tells me SyncScroll could set the screen address to finer values than 256 byte boundaries, but obviously that is out of reach of STOS. Unless... extensions? Are there any STfm compatible extensions that allow this sort of thing?

Or am I just barking up the wrong tree here, maybe even just plain barking mad? Maybe I need to forget the poor STfm and go STe only?

[thomas3]

Hey.
Look down on the forum. I made a sync scroll module for STOS which does exactly what you want

[joska]

Screen pointer has to be on a 256 byte boundary so your cunning plan wont work.

Unless you scroll 5 lines. With 5 buffers you can have smooth vertical scrolling on a plain ST by simply changing the screenpointer. This will of course eat RAM. On an STE you'll need 256Kb for double-buffering a double-height screen. On an ST you would need 640Kb just for the screenbuffers to do the same.

[thomas3]

Screen pointer has to be on a 256 byte boundary so your cunning plan wont work.

Unless you scroll 5 lines. With 5 buffers you can have smooth vertical scrolling on a plain ST by simply changing the screenpointer. This will of course eat RAM. On an STE you'll need 256Kb for double-buffering a double-height screen. On an ST you would need 640Kb just for the screenbuffers to do the same.

This only works with 8 lines - 1280 is the first meaningful multiple of 256...

[joska]

You are of course right. So single line scrolling would be too memory-consuming in most cases. But two lines would not be so bad.

[darklight]

Hey.
Look down on the forum. I made a sync scroll module for STOS which does exactly what you want

Hi thomas3 - woah that is exactly what I'm talking about At first I couldnt get it to work, I was getting weird "extension #Q" keywords in the code, but I think this is because I didnt have the missing link extension installed (I see you say you were using it). I commented them out / changed them to use jup / jdown, and it worked after that.

Now another question - I see sprites dont work with this method. Are syncscroll and sprites possible?

[calimero]

Why there is 256 byte boundaries in ST for video address?

Some register for setting/holding value of screen address is only 8bit?

[thomas3]

The video address counter (which updates as the electron beam moves) is three bytes (high/medium/low). This takes its value each vbl from the video address pointer, but this is only two bytes (corresponding to high/medium of the video address counter). The low byte of the counter just starts from zero each vbl - i.e., the video address pointer has no low byte, hence is a 256b multiple.

Someone smarter than me can probably tell you why it was implemented this way...

[simonsunnyboy]

Probably saved some gates in the shifter and not to mention that the original ST design didn't want to be a game machine but a Macintosh competitor (which it did with bravo).