horizontal scrolling on ST

[Dio]

Yes, you can't write the low byte in the ST, only the STE. Put a bunch of us beardies in a room and we will fight about whether that, bitplanes or the crappy sound chip was Atari's most facepalm-worthy failing... although, as I noted, it gets very expensive in video memory if you don't also have a writable screen current pointer or hardware address wrap.

[mc6809e]

That's the way I did it. Just threw bytes at the screen. As mc6809e says, works fine at 25fps but it's very hard to do 50fps unless you cut the window size down a lot.

and "256 bytes" boundary limit for video address is because low/or high part of video register is not writable ? right?

A video base address register for the bottom eight bits of the base address simply doesn't exist on the ST. Those bottom eight bits exist in a counter, but there is no way to directly reload them with an arbitrary value at the top of a frame. The hardware resets them to all zeros.

The infuriating thing is that it probably would have taken very little extra logic to make an extra register for this byte. They wouldn't have even needed to store eight bits. Four bits would have been enough for most things that might use a vertical scroll -- a fast Marble Madness, for example.

There is sync scroll, though, which is a neat trick for vertical scrolling in hardware.

[calimero]

and "256 bytes" boundary limit for video address is because low/or high part of video register is not writable ? right?

A video base address register for the bottom eight bits of the base address simply doesn't exist on the ST. Those bottom eight bits exist in a counter, but there is no way to directly reload them with an arbitrary value at the top of a frame. The hardware resets them to all zeros.

The infuriating thing is that it probably would have taken very little extra logic to make an extra register for this byte. They wouldn't have even needed to store eight bits. Four bits would have been enough for most things that might use a vertical scroll -- a fast Marble Madness, for example.

There is sync scroll, though, which is a neat trick for vertical scrolling in hardware.

so this is unintentional omission in hardware design??

it is quite odd since they (Shiraz Shivji ) made very good design with ST!

(second omission, I would say, is ROM port: it could be easy an MC68000 bus expander slot (something like Amiga "trapdoor")?
- P. Putnik manage to achieve almost 3.5MB/s with CF card over ROM port: it is almost TWICE faster than ASCI port!!)

[mc6809e]

so this is unintentional omission in hardware design??

I don't think so. I just don't think hardware assisted graphics was a design goal, so they did what was minimally required.

The ST came into existence to provide a low cost 68000 alternative to the Amiga and Macintosh. It was meant to be a simple and inexpensive and computationally faster computer. The Amiga was in part designed by one of the designers of the Atari 2600, so his goals were different and the design reflects that. The Amiga actually started out as a gaming console and was later converted to a personal computer. That's why the hardware has so many game friendly features. It came at a price, though.

[calimero]

so this is unintentional omission in hardware design??

I don't think so. I just don't think hardware assisted graphics was a design goal, so they did what was minimally required.

The ST came into existence to provide a low cost 68000 alternative to the Amiga and Macintosh. It was meant to be a simple and inexpensive and computationally faster computer. The Amiga was in part designed by one of the designers of the Atari 2600, so his goals were different and the design reflects that. The Amiga actually started out as a gaming console and was later converted to a personal computer. That's why the hardware has so many game friendly features. It came at a price, though.

yes, I know, but it is quite strange not to include 4 bits for fine vertical scrolling at least - especial that Shiraz/Tramiel previous computer had it (C64)!


btw best picture regarding Amiga / Atari is (by Gunstick):

Screen Shot 2013-04-03 at 01.24.35.png

Amiga was in development for several years!; Atari ST was design/debug/built in less than a 12 months (and manage to beat Amiga to the market arrival!) it is quite IMPRESSIVE*!
Amiga really had bad, bad, bad luck...
beside, it was not so popular until they (Dave Hayne & co) manage to cut cost down with Amiga 500 model... only then developers start to push Amiga hardware.

[Zamuel_a]

The ST came out just alittle before the Amiga and was much cheaper

Amiga 1000
July 23, 1985
$1,295

Amiga 500
October 1987
$699

Atari ST
June 1985
US$ 799.99 (monochrome)
US$ 999.99 (with color monitor)

Couldn't find what the Atari costed without any monitor but it must have been $100 less or something.

The history between Atari and Amiga is quite funny because it started then one guy who was the original designer for Atari 2600 wanted to create some game chips to use in future computer models, but Atari didn't want that so he left Atari and started his own company instead, Amiga.

[Dio]

The other thing to remember is that given all the features they did have in common - CPU, keyboard, disk drive only, RAM, WIMP OS, etc. there was much less obviously to pick between the Amiga and ST. Spending between half again and twice as much money for 'slightly better graphics and sound' was strictly for people with more money than sense, particularly in Europe where there weren't many disk-drive upgraded 8-bit machines so the leap in capability offered by either was huge.

[calimero]

Spending between half again and twice as much money for 'slightly better graphics and sound' was strictly for people with more money than sense, particularly in Europe where there weren't many disk-drive upgraded 8-bit machines so the leap in capability offered by either was huge.

this was exact situation when my father and I went to Germany / München (1986) to buy new computer to replace Spectrum ZX. Choice was easy: Atari ST with monitor for less DM than Amiga 1000 alone. And for me, graphics on game boxes looks same ...so we pick ST with SM124 (father loves it for everyday job) and Commodore 9pin printer!

[DarkLord]

Atari ST
June 1985
US$ 799.99 (monochrome)
US$ 999.99 (with color monitor)

Couldn't find what the Atari costed without any monitor but it must have been $100 less or something.

Hmm, can't speak for anyone else but I got my first 520ST just as soon as it was available here (US).

I paid:

520ST - $399.00
SF 354 - $199.00
SC1224 - $299.00

Before shipping and handling.

from CDW Computers. It also came with some software, but I can't remember what it was.

[danorf]

It's tIme to speak about code !

I confirm that.
And the problem is if you want to scroll more than 1 pixel at a time.
Shifting 1 pixel will always look smooth, may be slow but smooth.
Shifting 2 pixels via SW without any preshift trick leads to at least 3 frames to move the 4 bit planes screen: this will look bad. Solution => memory for each possible shift / 8 or 9 video screens => not applicable to games that have to run with 512KB.

I still have a source that is more than 25 years old where i tried to do the no-trick 4 planes scroll with shifts > 1.
Probably it is not the best, and surely could be improved (for example: generated code would remove the swap D6 because no dbf counter would be needed anymore => but more memory needs), but it can be used as an example.
It looks like this for 16 dots :
...
This takes 112 cycles + 2 rol.l => around 136 cycles for 16 dots and 2 pixels shift !!!
As we have 64000 pixels, we would need around 544000 cycles for the whole screen => 3.4 frames !!!
The worst case happens with a 4 pixel shift but the result should still be under 4 frames.
Anyone managed this under 4 frames ?
This means less than 120 cycles for each block of 16 dots !


Enjoy,
Paulo.

Here are three pieces of code I've got on my HD :

for each source code, a0 is a pointer on an line of the screen to scroll (at start or at end of the line depending of the souce code) and a1 is a pointer of the next "tile" to print on the screen when scrolling.

- roxmscroll was the piece of code I mentioned on a previous post. It's the fastest possible (as far as I know) code to make 1 pixel horizontal scrolling (left to right or right to left, by switching between roxl and roxr instruction and the order each word in memory wil be modified).
- addxscroll32 is the fastest (as far as I know) code to make n pixels horizontal scrolling, but only from left to right.
- roxrscroll32 is a modification of the previous one to permit left to right and right to left scrolling (by changing roxl instruction by roxr, and order of some instrucitons in the code).

At the end of the source codes, you'll find the cost in term of cycle of each source code.

roxmscroll :

Code: Select all

cut:
	roxl.w	(a1)+		;12
	roxl.w	152(a0)		;16
	roxl.w	144(a0)		;16
	roxl.w	136(a0)		;16
	roxl.w	128(a0)		;16
	roxl.w	120(a0)		;16
	roxl.w	112(a0)		;16
	roxl.w	104(a0)		;16
	roxl.w	96(a0)		;16
	roxl.w	88(a0)		;16
	roxl.w	80(a0)		;16
	roxl.w	72(a0)		;16
	roxl.w	64(a0)		;16
	roxl.w	56(a0)		;16
	roxl.w	48(a0)		;16
	roxl.w	40(a0)		;16
	roxl.w	32(a0)		;16
	roxl.w	24(a0)		;16
	roxl.w	16(a0)		;16
	roxl.w	8(a0)		;16
	roxl.w	(a0)		;12
	
	roxl.w	(a1)+		;12
	roxl.w	154(a0)		;16
	roxl.w	146(a0)		;16
	roxl.w	138(a0)		;16
	roxl.w	130(a0)		;16
	roxl.w	122(a0)		;16
	roxl.w	114(a0)		;16
	roxl.w	106(a0)		;16
	roxl.w	98(a0)		;16
	roxl.w	90(a0)		;16
	roxl.w	82(a0)		;16
	roxl.w	74(a0)		;16
	roxl.w	66(a0)		;16
	roxl.w	58(a0)		;16
	roxl.w	50(a0)		;16
	roxl.w	42(a0)		;16
	roxl.w	34(a0)		;16
	roxl.w	26(a0)		;16
	roxl.w	18(a0)		;16
	roxl.w	10(a0)		;16
	roxl.w	2(a0)		;16

	roxl.w	(a1)+		;12
	roxl.w	156(a0)		;16
	roxl.w	148(a0)		;16
	roxl.w	140(a0)		;16
	roxl.w	132(a0)		;16
	roxl.w	124(a0)		;16
	roxl.w	116(a0)		;16
	roxl.w	108(a0)		;16
	roxl.w	100(a0)		;16
	roxl.w	92(a0)		;16
	roxl.w	84(a0)		;16
	roxl.w	76(a0)		;16
	roxl.w	68(a0)		;16
	roxl.w	60(a0)		;16
	roxl.w	52(a0)		;16
	roxl.w	44(a0)		;16
	roxl.w	36(a0)		;16
	roxl.w	28(a0)		;16
	roxl.w	20(a0)		;16
	roxl.w	12(a0)		;16
	roxl.w	4(a0)		;16

	roxl.w	(a1)+		;12
	roxl.w	158(a0)		;16
	roxl.w	150(a0)		;16
	roxl.w	142(a0)		;16
	roxl.w	134(a0)		;16
	roxl.w	126(a0)		;16
	roxl.w	118(a0)		;16
	roxl.w	110(a0)		;16
	roxl.w	102(a0)		;16
	roxl.w	94(a0)		;16
	roxl.w	86(a0)		;16
	roxl.w	78(a0)		;16
	roxl.w	70(a0)		;16
	roxl.w	62(a0)		;16
	roxl.w	54(a0)		;16
	roxl.w	46(a0)		;16
	roxl.w	38(a0)		;16
	roxl.w	30(a0)		;16
	roxl.w	22(a0)		;16
	roxl.w	14(a0)		;16
	roxl.w	6(a0)		;16

	lea.l	160(a0),a0	;8
	;copy/paste lines between "cut" label and this line for scrolling more screen lines

addxscroll32:

Code: Select all

	movem.w	(a1)+,d4-d7	; 12+4*4=28

	lea	-16(a0),a0      ;  8

	movem.w	(a0)+,d0-d3	; 12+16=28

	movea.w	d0,a2		;  4
	movea.w	d1,a3		;  4
	movea.w	d2,a4		;  4
	movea.w	d3,a5		;  4 --> 16

	swap.w	d0		;  4
	swap.w	d1		;  4
	swap.w	d2		;  4
	swap.w	d3		;  4 --> 16

	movem.w	(a0)+,d0-d3	; 12+16=28

	addx.w   d4,d4      ;4
	addx.l   d0,d0      ;8
	;copy/paste the last 2 lines n times for n bits scroll

	addx.w   d5,d5      ;4
	addx.l   d1,d1      ;8
	;copy/paste the last 2 lines n times for n bits scroll
       
	addx.w   d6,d6      ;4
	addx.l   d2,d2      ;8
	;copy/paste the last 2 lines n times for n bits scroll

	addx.w   d7,d7      ;4
	addx.l   d3,d3      ;8
	;copy/paste the last 2 lines n times for n bits scroll

	movem.w   d4-d7,-(a1)   ;8+16=24   

	movem.w   d0-d3,-(a0)   ;8+16=24

	swap.w   d0      ;4
	swap.w   d1      ;4
	swap.w   d2      ;4
	swap.w   d3      ;4 --> 16

	movem.w   d0-d3,-(a0)   ;8+16=24

cut:
	move.w	a2,d4		;  4
	move.w	a3,d5		;  4
	move.w	a4,d6		;  4
	move.w	a5,d7		;  4 -->4*4

	lea	-16(a0),a0	;  8
       
	movem.w	(a0)+,d0-d3	; 12+16=28

	movea.w	d0,a2		;  4
	movea.w	d1,a3		;  4
	movea.w	d2,a4		;  4
	movea.w	d3,a5		;  4 --> 16

	swap.w	d0		;  4
	swap.w	d1		;  4
	swap.w	d2		;  4
	swap.w	d3		;  4 --> 16

	movem.w	(a0)+,d0-d3	; 12+16=28

	addx.w   d4,d4      ;4
	addx.l   d0,d0      ;8
	;copy/paste the last 2 lines n times for n bits scroll

	addx.w   d5,d5      ;4
	addx.l   d1,d1      ;8
	;copy/paste the last 2 lines n times for n bits scroll
       
	addx.w   d6,d6      ;4
	addx.l   d2,d2      ;8
	;copy/paste the last 2 lines n times for n bits scroll

	addx.w   d7,d7      ;4
	addx.l   d3,d3      ;8
	;copy/paste the last 2 lines n times for n bits scroll

	movem.w   d0-d3,-(a0)   ;8+16=24

	swap.w   d0      ;4
	swap.w   d1      ;4
	swap.w   d2      ;4
	swap.w   d3      ;4 --> 16

	movem.w   d0-d3,-(a0)   ;8+16=24
	;copy/paste lines between "cut" label and this line for scrolling more blocks of 32 pixels

roxrscroll32:

Code: Select all

	movem.w	(a1)+,d4-d7	;12+4*4=28

	lea -16(a0),a0		;8
	
	movem.w	(a0)+,d0-d3	; 12+16=28

	movea.w	d0,a2		;  4
	movea.w	d1,a3		;  4
	movea.w	d2,a4		;  4
	movea.w	d3,a5		;  4 --> 16

	swap.w	d0		;  4
	swap.w	d1		;  4
	swap.w	d2		;  4
	swap.w	d3		;  4 --> 16

	movem.w	(a0)+,d0-d3	; 12+16=28

	roxl.w	#1,d4		;8
	roxl.l	#1,d0		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll

	roxl.w	#1,d5		;8
	roxl.l	#1,d1		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll
	
	roxl.w	#1,d6		;8
	roxl.l	#1,d2		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll

	roxl.w	#1,d7		;8
	roxl.l	#1,d3		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll

	movem.w   d4-d7,-(a1)   ;8+16=24   

	movem.w   d0-d3,-(a0)   ;8+16=24

	swap.w   d0      ;4
	swap.w   d1      ;4
	swap.w   d2      ;4
	swap.w   d3      ;4 --> 16

	movem.w   d0-d3,-(a0)   ;8+16=24

cut:
	move.w	a2,d4		;4
	move.w	a3,d5		;4
	move.w	a4,d6		;4
	move.w	a5,d7		;4 -->4*4

	lea -16(a0),a0		;8
	
	movem.w	(a0)+,d0-d3	; 12+16=28

	movea.w	d0,a2		;  4
	movea.w	d1,a3		;  4
	movea.w	d2,a4		;  4
	movea.w	d3,a5		;  4 --> 16

	swap.w	d0		;  4
	swap.w	d1		;  4
	swap.w	d2		;  4
	swap.w	d3		;  4 --> 16

	movem.w	(a0)+,d0-d3	; 12+16=28

	roxl.w	#1,d4		;8
	roxl.l	#1,d0		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll

	roxl.w	#1,d5		;8
	roxl.l	#1,d1		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll
	
	roxl.w	#1,d6		;8
	roxl.l	#1,d2		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll

	roxl.w	#1,d7		;8
	roxl.l	#1,d3		;10 --> 12
	;copy/paste the last 2 lines n times for n bits scroll

	movem.w   d0-d3,-(a0)   ;8+16=24

	swap.w   d0      ;4
	swap.w   d1      ;4
	swap.w   d2      ;4
	swap.w   d3      ;4 --> 16

	movem.w   d0-d3,-(a0)   ;8+16=24
	;copy/paste lines between "cut" label and this line for scrolling more blocks of 32 pixels

about timing :

Code: Select all

nb of               16 pixels block                         320 pixels line			
shift   addxscroll32  roxrscroll32  roxmscroll  addxscroll32	roxrscroll32	roxmscroll
1	          105,8	        109,8        63,6          2116        2196	       1272
2	          111,8	        119,8                      2236        2396	
3           117,8         129,8                       2356        2596	
4	          123,8         139,8                       2476        2796	
5	          129,8         149,8                       2596        2996	
6	          135,8         159,8                       2716        3196	
7           141,8         169,8                       2836        3396	
8           147,8         179,8                       2956        3596	
9	          153,8         189,8                       3076        3796	
10          159,8         199,8                       3196        3996	
11          165,8         209,8                       3316        4196	
12          171,8         219,8                       3436        4396	
13          177,8         229,8                       3556        4596	
14          183,8         239,8                       3676        4796	
15          189,8         249,8                       3796        4996	

[ljbk]

Hi !


Yes, the roxl xx(an) is the obvious choice for 1 pixel scrolling.
I used this so many times.
One example is the YM50K text scroller while replaying the mods at 50 KHz and vertical sync-scroll.
The advantage of this is that you can do a one plane scroll off-video and include it on a pic on a specific logical color with a serie of AND and/or OR to the pic planes. In that case you can do roxl (an)+.

As for the rest, i see that you have everything calculated unlike me. At the time i wrote that rout, i was not worried about synchro code.
I do not agree with you for scrolls close to 8 pixels because you can take advantage of the BYTE acess to speed up things.
And on top of that, scrolling 4 to the left is the same as scrolling 12 to the right and vice versa, so i think that only values up to 8 matter.
So as i said, if i remember right, the worst case should be between 4 and 6 pixels scroll.

Anyway, we should also consider the real speed that one gets.
If we have:
1 pixel scrolling -> 2 frames: real speed is 25 pixels per second;
any other -> 4 frames: real speed is N x 12.5 pixels per second;
=> then it makes no sense to use speed scrolls of 2, it is smoother to do 2 times a 1 pixel scroll.

Of course, all this is considering 1 video frame buffer.
For X video frame buffers the calcs change.
The calcs also change depending if you do a save background for the sprites or you redraw the complete background every time.


Cheers,
Paulo.

[danorf]

I do not agree with you for scrolls close to 8 pixels because you can take advantage of the BYTE acess to speed up things.

and

So as i said, if i remember right, the worst case should be between 4 and 6 pixels scroll.

For 7, 8 and 9 pixels scroll, I agree with you, I've forgotten the 8 pixels peculiar case. Here is a (very simple) code that take 1984 cycles per line (~99,2 cycles per 16 pixels block) to make a 8 pixels right to left scroll (it can be rearranged to make a left to right scroll).
movpscroll :

Code: Select all

cut:
	movep.l	-159(a0),d0	;24
	movep.l	d0,-160(a0)	;24
	movep.l	-152(a0),d0	;24
	movep.l	d0,-159(a0)	;24
	movep.l	-151(a0),d0	;24
	movep.l	d0,-152(a0)	;24
	movep.l	-144(a0),d0	;24
	movep.l	d0,-151(a0)	;24
	movep.l	-143(a0),d0	;24
	movep.l	d0,-144(a0)	;24
	movep.l	-136(a0),d0	;24
	movep.l	d0,-143(a0)	;24
	movep.l	-135(a0),d0	;24
	movep.l	d0,-136(a0)	;24
	movep.l	-128(a0),d0	;24
	movep.l	d0,-135(a0)	;24
	movep.l	-127(a0),d0	;24
	movep.l	d0,-128(a0)	;24
	movep.l	-120(a0),d0	;24
	movep.l	d0,-127(a0)	;24
	movep.l	-119(a0),d0	;24
	movep.l	d0,-120(a0)	;24
	movep.l	-112(a0),d0	;24
	movep.l	d0,-119(a0)	;24
	movep.l	-111(a0),d0	;24
	movep.l	d0,-112(a0)	;24
	movep.l	-104(a0),d0	;24
	movep.l	d0,-111(a0)	;24
	movep.l	-103(a0),d0	;24
	movep.l	d0,-104(a0)	;24
	movep.l	-96(a0),d0	;24
	movep.l	d0,-103(a0)	;24
	movep.l	-95(a0),d0	;24
	movep.l	d0,-96(a0)	;24
	movep.l	-88(a0),d0	;24
	movep.l	d0,-95(a0)	;24
	movep.l	-87(a0),d0	;24
	movep.l	d0,-88(a0)	;24
	movep.l	-80(a0),d0	;24
	movep.l	d0,-87(a0)	;24
	movep.l	-79(a0),d0	;24
	movep.l	d0,-80(a0)	;24
	movep.l	-72(a0),d0	;24
	movep.l	d0,-79(a0)	;24
	movep.l	-71(a0),d0	;24
	movep.l	d0,-72(a0)	;24
	movep.l	-64(a0),d0	;24
	movep.l	d0,-71(a0)	;24
	movep.l	-63(a0),d0	;24
	movep.l	d0,-64(a0)	;24
	movep.l	-56(a0),d0	;24
	movep.l	d0,-63(a0)	;24
	movep.l	-55(a0),d0	;24
	movep.l	d0,-56(a0)	;24
	movep.l	-48(a0),d0	;24
	movep.l	d0,-55(a0)	;24
	movep.l	-47(a0),d0	;24
	movep.l	d0,-48(a0)	;24
	movep.l	-40(a0),d0	;24
	movep.l	d0,-47(a0)	;24
	movep.l	-39(a0),d0	;24
	movep.l	d0,-40(a0)	;24
	movep.l	-32(a0),d0	;24
	movep.l	d0,-39(a0)	;24
	movep.l	-31(a0),d0	;24
	movep.l	d0,-32(a0)	;24
	movep.l	-24(a0),d0	;24
	movep.l	d0,-31(a0)	;24
	movep.l	-23(a0),d0	;24
	movep.l	d0,-24(a0)	;24
	movep.l	-16(a0),d0	;24
	movep.l	d0,-23(a0)	;24
	movep.l	-15(a0),d0	;24
	movep.l	d0,-16(a0)	;24
	movep.l	-8(a0),d0	;24
	movep.l	d0,-15(a0)	;24
	movep.l	-7(a0),d0	;24
	movep.l	d0,-8(a0)	;24
	movep.l	(a1),d0		;24
	movep.l	d0,-7(a0)	;24
	movep.l	1(a1),d0	;24
	movep.l	d0,(a1)		;24

	lea.l	160(a0),a0	;8
	lea.l	8(a1),a1	;8

	;copy/paste lines between "cut" label and this line for scrolling more screen lines
	;(or do a loop)

Combining this code with roxwscroll of my previous post, it's theorically possible to make 7 and 9 pixels scrollings that take 3256 cycles per line (~162,8 cycles per 16 pixels block). Note that the resulting code will be very extra large and in the case of 7 pixels scroll the speed gain (against roxrscroll32 as addxscroll32 is still faster) is not very impressive : 3256 cycles vs 3396 cycles --> around 4,1% faster.

And on top of that, scrolling 4 to the left is the same as scrolling 12 to the right and vice versa, so i think that only values up to 8 matter.

Yes and no.
I agree your statement if speaking of shifting and/or rotating values, but in a scrolling you must add pixels from previous/next 16 pixel block depending of the direction of the scrolling (unless your background is painted with always the same 16 x .. pixels tile, but that's cheating). "Calculating" and moving these pixels take times and I think that sometimes it's faster to rox (l or r) more than 8 times and not having to care of these pixels.
In addition, I must admit I never really saw the real interest in making scroll > to 8 pixels wide --> too fast or jerky to me. I only put the value >8 in the table of the previous post to be complete.

[mc6809e]

I agree your statement if speaking of shifting and/or rotating values, but in a scrolling you must add pixels from previous/next 16 pixel block depending of the direction of the scrolling (unless your background is painted with always the same 16 x .. pixels tile, but that's cheating). "Calculating" and moving these pixels take times and I think that sometimes it's faster to rox (l or r) more than 8 times and not having to care of these pixels.

Yep. If the 68000 had an instruction that would just write the high word of a data register, the code could be much faster. Bits could simply be streamed through the register.

[ljbk]

Hi !

Maybe there is some misunderstanding here.
Are we talking about:
- option 1: scrolling by n pixels what is already in a 32000 bytes video buffer and add something to the left or right;
OR
- option2: building a complete video frame where you can select the starting n pixel like the STE does by HW;

From the code point of view this is quite different.

Paulo.

[calimero]

Hi !

Maybe there is some misunderstanding here.
Are we talking about:
- option 1: scrolling by n pixels what is already in a 32000 bytes video buffer and add something to the left or right;
OR
- option2: building a complete video frame where you can select the starting n pixel like the STE does by HW;

From the code point of view this is quite different.

I refer to option 2.

[ljbk]

Hi !

Maybe there is some misunderstanding here.
Are we talking about:
- option 1: scrolling by n pixels what is already in a 32000 bytes video buffer and add something to the left or right;
OR
- option 2: building a complete video frame where you can select the starting n pixel like the STE does by HW;

From the code point of view this is quite different.

I refer to option 2.

Ok, then forget a great part of what i wrote.
Sorry for the misunderstanding.

The choice between the two options depends on the number of sprites and if your background is animated or not.
Option 1 can be cheaper in clock cycles compared to option 2 or not.

Paulo.

[mc6809e]

It's tIme to speak about code !

about timing :

Code: Select all

nb of               16 pixels block                         320 pixels line			
shift   addxscroll32  roxrscroll32  roxmscroll  addxscroll32	roxrscroll32	roxmscroll
1	          105,8	        109,8        63,6          2116        2196	       1272
2	          111,8	        119,8                      2236        2396	

From the source code it looks like addxscroll32 takes 120 extra cycles per 32 pixels, but your table suggests that it's 120 extra cycles per scanline. Which is it? Maybe I'm missing something.

[danorf]

From the source code it looks like addxscroll32 takes 120 extra cycles per 32 pixels, but your table suggests that it's 120 extra cycles per scanline. Which is it? Maybe I'm missing something.

The formula to calculate the nb of cycles taken for a complete scanline scrolling with addxscroll32 code is : 212+12n+9*(176+12n).
n is the number of bits/pixels you want to scroll in 1 time (number of times you have copied/pasted addx.w/addx.l lines).
You have 20 "16 pixels blocks" in a scanline <--> 10 "32 pixels blocks" (addxscroll32 works on 32 pixels blocks).
9 of the 10 "32 pixels blocks" are "fast" to scroll as the remaining bits of the previous "32 pixels block" scrolling are still in registers so it takes "only" 176+12n.
The 10th "32 pixels block" is slower as you have to get the bits to add at the right of the block in the data pointed by a1, so it will takes 212+12n.

With this formula you get the values of the right column ("320 pixels line"):

Code: Select all

1 pixel  : 2116 cycles
2  pixels : 2236 cycles
3  pixels : 2356 cycles
4  pixels : 2476 cycles
5  pixels : 2596 cycles
6  pixels : 2716 cycles
...

These are values for one line so you have to multiply it by the number of lines you want to scroll.

The values of the left column ("16 pixels block") are average values for a 16 pixels block (as it's easyier to compare with other codes as ljbk one) calculated by dividing the previous values by 20 (number of 16 pixels blocks in a complete line). So you've got :

Code: Select all

1 pixel  : 105,8 cycles
2 pixels : 111,8 cycles
3 pixels : 117,8 cycles
4 pixels : 123,8 cycles
5 pixels : 129,8 cycles
6 pixels : 135,8 cycles
...

the ",8" is explained by the difference of time taken to scroll the 9th first blocks and the last one (232-196)/20=1,8.

I hope these explainations will help to understand.

EDIT : at least, it had helped to make me realize that I was wrong in my formula for some of the codes (addxscroll32 and roxscroll32) and that I totally f...ed up my table ! I miss a "4*" for taking in count all the bitplans (for exemple the correct formula for addxscroll32 is (212+4*(12n)+9*(176+4*(12n))) ! A new accurate table will come but the results will be a lot slower.

2nd edit : here is the correct (I hope so) table !

Code: Select all

nb of   16 pixels block                                       320 pixels line						
shift   addxscroll32  roxrscroll32  roxm/movp   addxscroll32  roxrscroll32	roxm/movp
 1      113,8         129,8         66,8        2276           2596         1336			
 2      137,8         169,8                     2756           3396				
 3      161,8         209,8                     3236           4196				
 4      185,8         249,8                     3716           4996				
 5      209,8         289,8                     4196           5796				
 6      233,8         329,8                     4676           6596				
 7      257,8         369,8                     5156           7396
 8      281,8         409,8         99,2        5636           8196         1984	
 9      305,8         449,8                     6116           8996
10      329,8         489,8                     6596           9796				
11      353,8         529,8                     7076          10596				
12      377,8         569,8                     7556          11396				
13      401,8         609,8                     8036          12196				
14      425,8         649,8                     8516          12996				
15      449,8         689,8                     8996          13796

[danorf]

It looks like this for 16 dots :
...
move.l (a1)+,d0
move.l (a1)+,d1
rol.l d7,d0
rol.l d7,d1
move.l d0,d4
and.l d5,d4
and d6,d0
swap d0
and d6,d0
or.l d2,d0
move.l d1,d2
and.l d5,d2
and d6,d1
swap d1
and d6,d1
or.l d3,d1
move.l d0,(a0)+
move.l d1,(a0)+
...

Can you, please, explain one or two things on your code ?
If I understand it well :
your code should make a left to right scrolling of n pixels ('16-n' is the value in d7).
d5 and d6 are loaded, once, with masks corresponding to the rotated bits number in d7, for exemple : F000F000-->d5, 0FFF-->d6, C-->d7 or FF00FF00-->d5, 00FF-->d6 and 8-->d7.
d2 and d3 must initially be loaded with the masked result of the rotated 21th 16 bits block (the one that "is before the left border of the screen").
a0 & a1 must be equal at the beginning.

Don't You have to add "move.l d2,d3 / move.l d4,d2" after the last two moves ?

[ljbk]

Hi !

The code pattern is not repeated 100% equal. The registers, ORed to D0 and D1, before storing the result, change.
Attached you will find a zip with the program and a 32K pic.
This code is as it was done in the late 80s, so it is far from perfect.
Press '+' and '-' from the keypad for pixel jumps from 1 to 8. Starting value is 2. Any other key exits to TOS.
No roxl xx(An)/move.b/movep optimization is used.

Paulo.

[flashjazzcat]

*EDIT* And yes, the C64 and Atari 8Bits have a similar hardware support too, main difference is they smoothscroll a character based screen map, not a pixel addressable.

Ahem... not sure about the C64, but the A8 will hardware smooth-scroll bitmapped and character graphics.

[Zamuel_a]

Ahem... not sure about the C64, but the A8 will hardware smooth-scroll bitmapped and character graphics.

The C64 hardware scroller is very good. The screen is character based and you scroll 8 pixels in X or Y so you can very easily scroll in any direction. You scroll 8 pixels, then copy the screen one character to the side, scroll again, copy and continue like that. Since it's character based the amount of data to copy is very small (1k I think) so it's very fast to do. On an STE you would have to copy 32k of data for each 16 pixels to do the same, and that's not possible so you must solve it in a more difficult way.

[Dio]

1K in character modes, in bit-mapped modes it's about 8K, as I understand it. Given that an 8MHz 68000 has about 16x the blit-ability of a 1MHz 6502 (peak rate of about 2M 16-bit transfers/s vs. about 0.25M 8-bit transfers/s), but only 4x the video RAM, I would expect the STE to be superior if using such a mode, although it's more likely that the STE would use a double width screen and never do a copy at all. Not sure if that's possible on the C64.

What really makes scrolling fast and simple is a small amount of line padding combined with a wrap register, so you never need to copy at all. The BBC's ability to do that during program listings was one of the major things that gave it its reputation for speed .

[dml]

1K in character modes, in bit-mapped modes it's about 8K, as I understand it. Given that an 8MHz 68000 has about 16x the blit-ability of a 1MHz 6502 (peak rate of about 2M 16-bit transfers/s vs. about 0.25M 8-bit transfers/s), but only 4x the video RAM, I would expect the STE to be superior if using such a mode, although it's more likely that the STE would use a double width screen and never do a copy at all. Not sure if that's possible on the C64.

What really makes scrolling fast and simple is a small amount of line padding combined with a wrap register, so you never need to copy at all. The BBC's ability to do that during program listings was one of the major things that gave it its reputation for speed .

Reading this thread, I've been itching to ask (since I never tried it on a plain ST, was mainly getting into my shiny new STE at the time...)

Has sync-scroll been used to assist low-CPU-load horizontal scrolling on an ST?

I do understand the vertical sync-scroll principle, eating display words in different permutations to offset the starting line. But what granularity of offset can be achieved that way? Does it allow permutation down to every 4 or 8 word offset from the base address?

What sort of offset patterns are possible in a single scanline? This is the key limiting factor since the rest will be a matter of consuming more lines to build the required offset.

I'm just curious. I'm aware it has probably been used at least partly to offset *every* scanline in some fullscreen demos to assist scroll, but I'm not sure if it has been used to just offset the screen base at fine intervals, while avoiding a complete display rebuild and leaving the CPU free for useful work?

[Zamuel_a]

1K in character modes, in bit-mapped modes it's about 8K, as I understand it.

You never use the bitmap mode for games so you never handle 8k. Character mode is what most 8 bit computers and 8/16 bit video games used and for a tile based application like a game, this is perfect. You only need a bitmapped mode then you handle individual pixels, like in 3D, but the bitmappmode on the c64 is even more difficult (slow to use) than the bitplane format on the ST so it's rarely used at all.

Has sync-scroll been used to assist low-CPU-load horizontal scrolling on an ST?

It must be possible since many demo screens has perfect scroll in all direction and 50fps and often in fullscreen to.