STE horizontal hardware scroll

jury · Post by **jury** » Fri Jan 12, 2018 2:37 pm

According to:
http://ftp.lip6.fr/pub/atari/Docs/hardware.txt

$FF820F|byte |Width of a scanline (width in words-1)               |R/W  (STe)

register ff820f is of a byte size for STE ( falcon has a different register which is of word size )
So does it mean that on STE there is a limit of a one shot playfield composed of 4 horizontal screens that can be hardware scrolled? ( byte = 256 = 3 * 80 words per scanline which can be skipped by shifter )
Or am I missing something?

Foxie · Post by **Foxie** » Fri Jan 12, 2018 5:01 pm

It's been ages since I looked at STE hardscroll so I may be a little rusty on details. But there is a limit how wide the "virtual" screen can be. 1024 pixels?

What you do, is set the width to 320 pixels. Scroll the screen to the left in hardware. Then, draw new graphics on the right in that space that's exposed by the scroll. You refer to your level map and draw the graphics in tiles. This way you can have an infinite width for scrolling. You basically wrap around horizontally.

There is one caveat to watch for. If you keep scrolling horizontally, you will move later and later in memory. For each 320 pixels you scroll horizontally, your frame buffer advances by one scanline. So, you need to wrap around to the top of the frame buffer when you go off the bottom. Otherwise, the frame buffer will keep moving later and later in memory until it overwrites your program.

This can be achieved by setting a timer interrupt to trigger after drawing the bottom-most scanline of the framebuffer. Then, you reload the video address counter with the top of the frame buffer. So now your screen is split. You see the bottom half of the frame buffer on the top, and the top half of the frame buffer on the bottom. It can roll around vertically like this forever.

Maybe some diagrams would help?

evil · Post by **evil** » Fri Jan 12, 2018 6:23 pm

jury wrote: register ff820f is of a byte size for STE ( falcon has a different register which is of word size )
So does it mean that on STE there is a limit of a one shot playfield composed of 4 horizontal screens that can be hardware scrolled? ( byte = 256 = 3 * 80 words per scanline which can be skipped by shifter )
Or am I missing something?

Without looking at old source code, I think the lw register defines how many extra words the screen width is, eg how much it should skip after each line.

If you have a 160 byte screen, you can add an additional 512 bytes width which is a bit more than you said, but not much.

The way around it is a little CPU-hungry but by setting the screen address counter each line, you can have infinite width (no need to mess with the lw-register at all).

jury · Post by **jury** » Fri Jan 12, 2018 7:06 pm

Thanks guys. I was hoping I was wrong as with vertical hardware scroll it seems like a real hardware scroll, no cpu involved, just the matter of memory. And as horizontally I need a little more width than this allows it looks that cpu must be engaged.

evil wrote: The way around it is a little CPU-hungry but by setting the screen address counter each line, you can have infinite width (no need to mess with the lw-register at all).

Can you please explain it more as I do not get this trick.

Cyprian · Post by **Cyprian** » Fri Jan 12, 2018 7:45 pm

jury wrote:
evil wrote: The way around it is a little CPU-hungry but by setting the screen address counter each line, you can have infinite width (no need to mess with the lw-register at all).
Can you please explain it more as I do not get this trick.

by changing the screen address every line with TimerB or sync code (Evil's demos)

jury · Post by **jury** » Fri Jan 12, 2018 8:00 pm

Thanks, I understand this. What I did not get was, how is this changing the screen address every line can help me expand line width to ( as evil wrote ) infinite width ( and without using lw register ) But I will not be asking more, the magical sync code you mentioned above definitely excludes this technique for me

Frank B · Post by **Frank B** » Fri Jan 12, 2018 8:29 pm

The issue is the maximum number of words that can be skipped on the end of a line.

If you can reset the scroll and address every line it doesn't matter. You can "skip" as many words as you like

jury · Post by **jury** » Fri Jan 12, 2018 8:48 pm

OK, I get the picture! thanks. Worth a try.

Foxie · Post by **Foxie** » Fri Jan 12, 2018 8:55 pm

jury wrote:Thanks, I understand this. What I did not get was, how is this changing the screen address every line can help me expand line width to ( as evil wrote ) infinite width ( and without using lw register ) But I will not be asking more, the magical sync code you mentioned above definitely excludes this technique for me

It's pretty simple really. All you do at the start of each scanline is add a certain amount to the display address. So imagine you wanted a screen with 8192 pixels width (4096 bytes):

Line 0, set address to $0
Line 1, set address to $1000
Line 2, set address to $2000
Line 3, set address to $3000
etc.

If you use interrupts on each scanline, this will suck away about 50% of your CPU time (the 68000 is very slow handling them).

The main problem is memory use. An 8192x200 screen is nearly 1MB! That's why games use a tiling system and draw just the edges as it scrolls.

I wouldn't worry about the CPU use drawing the edges. It's really very tiny. You can even use the blitter to go faster. Even if you scroll 16 pixels a frame (very fast!) then I think the blitter needs 6400 clock cycles to do it. That's only 13 scanlines of raster time (4% CPU/blitter use).

Post by **mikro** » Sat Jan 13, 2018 12:10 am

A fun fact: Atari800's Display List do this "natively", you can really specify each line with its own address. When I switched to ST/Falcon I was shocked that the "better" Atari lacks this feature completely! (I learned only much later that the ST is definitely not a better computer, just a different one).

evil · Post by **evil** » Sat Jan 13, 2018 9:38 am

jury wrote:Thanks, I understand this. What I did not get was, how is this changing the screen address every line can help me expand line width to ( as evil wrote ) infinite width ( and without using lw register ) But I will not be asking more, the magical sync code you mentioned above definitely excludes this technique for me

Hi,

don't be afraid to try this, you don't need to use hardsynced code, MFP interrupts are enough.

Basicly what you do is writing one screen address per scanline with the movep.l instruction, movep requires the source to be dataregister and destination address in an address register, so each scanline look something like this:

Timer_B_HBL:
move.l (a1)+,d0 ;fetch address to set from a display list
movep.l d0,0(a0) ;set screen
rte

It requires A0 and A1 to be set at VBL and D0 will be trashed.

For a 200 line screen, there are 267 scanlines (85.3%) of free CPU. But you're losing out on three CPU registers.

It's easy to slow down and not use registers (tip: unused low memory to temporarily save an address for next scanline). It can also be made faster by aligning graphics data to 64k. But that limits how large image you can show (even more so than using $ffff820f).

But enough babble, here's the source:
http://files.dhs.nu/files_source/jury.zip

Frank B · Post by **Frank B** » Sat Jan 13, 2018 9:55 am

What's the CPU cost of saving/restoring registers too? What's the CPU cost of 200 timer b interrupts that just RTE? I did a dister with timer b and hardscroll but it must have been 20 years or so ago

I have a figure in mind of around 20% CPU for that.

jury · Post by **jury** » Sat Jan 13, 2018 1:54 pm

@evil
Thanks for the source! Will check it this weekend.

Foxie · Post by **Foxie** » Sat Jan 13, 2018 4:20 pm

Frank B wrote:What's the CPU cost of saving/restoring registers too? What's the CPU cost of 200 timer b interrupts that just RTE? I did a dister with timer b and hardscroll but it must have been 20 years or so ago I have a figure in mind of around 20% CPU for that.

If I recall correctly, the main overhead is just handling the interrupts. I had an interrupt handler running on hsync, doing very little. It seemed to suck about 50% of the CPU time. Of course that also interrupts during blanking.

Saving and restoring a couple of registers should take about 48 clock cycles, out of 512 per scanline. You might be able to abuse the usp as a temporary store.

Cyprian · Post by **Cyprian** » Sat Jan 13, 2018 5:32 pm

Frank B wrote:What's the CPU cost of saving/restoring registers too? What's the CPU cost of 200 timer b interrupts that just RTE? I did a dister with timer b and hardscroll but it must have been 20 years or so ago I have a figure in mind of around 20% CPU for that.

Evil's example takes 12%:

evil wrote:Timer_B_HBL:
move.l (a1)+,d0 ;fetch address to set from a display list
movep.l d0,0(a0) ;set screen
rte

Cyprian · Post by **Cyprian** » Sat Jan 13, 2018 5:34 pm

Cyprian wrote:
Frank B wrote:What's the CPU cost of saving/restoring registers too? What's the CPU cost of 200 timer b interrupts that just RTE? I did a dister with timer b and hardscroll but it must have been 20 years or so ago I have a figure in mind of around 20% CPU for that.
Evil's example takes 12%:
evil wrote:Timer_B_HBL:
move.l (a1)+,d0 ;fetch address to set from a display list
movep.l d0,0(a0) ;set screen
rte

TimerB intterupt with only RTE takes 8%

Foxie · Post by **Foxie** » Sat Jan 13, 2018 6:35 pm

I just wrote a benchmark, and I must have misremembered. Just running an hsync interrupt with rte takes 20% of the CPU time, not 50%.

Note: this is hsync, not timer B. So interrupting every scanline, even in blanking.

Code for benchmarking here:

Code: Select all

	SECTION TEXT
	COMMENT HEAD=1


	; Go into supervisor mode
	clr.l	-(sp)
	move.w	#$20,-(sp)
	trap	#1
	addq.l	#6,sp


	lea	withoutstr(pc),a0
	bsr.w	debugprint
	bsr.w	benchmark
	bsr.w	debugprinthex


	move.l	$68.w,d7
	lea	hblrout(pc),a0
	move.l	a0,$68.w
	move.w	sr,d6
	move.w	#$2100,sr

	lea	withstr(pc),a0
	bsr.w	debugprint
	bsr.w	benchmark
	bsr.w	debugprinthex

	move.w	d6,sr
	move.l	d7,$68.w

	lea	keystr(pc),a0
	bsr.w	debugprint
	bsr.w	debugwaitkey

	; Exit
	clr.w	-(sp)
	move.w	#$4c,-(sp)
	trap	#1



hblrout:
	rte


benchmark:
	move.l	d1,-(sp)
	clr.l	d0
	move.l	$462.w,d1
	add.l	#100,d1

.loop:	addq.l	#1,d0
	cmp.l	$462.w,d1
	bgt.b	.loop

	move.l	(sp)+,d1
	rts




; Print a string in a0
debugprint:
	movem.l	a0-a2/d0-d2,-(sp)
	move.l	a0,-(sp)
	move.w	#9,-(sp)		; c_conws
	trap	#1
	addq.l	#6,sp
	movem.l	(sp)+,a0-a2/d0-d2
	rts



; Print all 32 bits of d0 as hex followed by a space
debugprinthex:
	movem.l	a0/d0-d2,-(sp)
	move.l	sp,a0
	lea	-10(sp),sp

	move.b	#0,-(a0)
	move.b	#32,-(a0)

	move.w	#8-1,d2
.loop:
	move.b	d0,d1
	and.b	#$0f,d1
	lsr.l	#4,d0

	add.b	#48,d1
	cmp.b	#58,d1
	blt.b	.skipalpha
	add.b	#7,d1
.skipalpha:

	move.b	d1,-(a0)

	dbf	d2,.loop

	bsr.w	debugprint

	lea	10(sp),sp
	movem.l	(sp)+,a0/d0-d2
	rts



; Wait for keypress
debugwaitkey:
	movem.l	a0-a2/d0-d2,-(sp)
	move.w	#1,-(sp)		; c_conin
	trap	#1			; Wait for keypress
	addq.l	#2,sp
	movem.l	(sp)+,a0-a2/d0-d2
	rts


	SECTION DATA
	CNOP	0,4
withoutstr	dc.b	10,13,"Iterations with no HBL: ",0
withstr		dc.b	10,13,"Iterations with HBL: ",0
keystr		dc.b	10,13,"Press any key",10,13,0

Cyprian · Post by **Cyprian** » Sat Jan 13, 2018 6:47 pm

Foxie wrote:Just running an hsync interrupt with rte takes 20% of the CPU time,

Are you sure about that 20%?
Entering an interrupt takes 44 cycles, RTE 20 cycles, it is 64 cycles per scanline (512 cycles).

64 / 512 = 12,5%

Foxie · Post by **Foxie** » Sat Jan 13, 2018 6:59 pm

Another interesting point from some tests:

Interrupt latency is almost exactly the same as the left border. If you change a colour on the hsync interrupt, it will take effect right where the picture begins.

Hsync interrupt is triggered near the hsync pulse, not the rightmost edge of the picture (which is a shame). So, however wide the left border is in pixels is the approximate interrupt latency.

I'll adapt the benchmark routine to also test timer B ^.^

Foxie · Post by **Foxie** » Sat Jan 13, 2018 7:02 pm

Cyprian wrote:
Foxie wrote:Just running an hsync interrupt with rte takes 20% of the CPU time,
Are you sure about that 20%?
Entering an interrupt takes 44 cycles, RTE 20 cycles, it is 64 cycles per scanline (512 cycles).

64 / 512 = 12,5%

Interesting, the output of the benchmark seemed to suggest it was 15-20%.

Here's the output from a run I just did:

431k iterations with hsync disabled
363k iterations with hsync enabled

That's about 84% CPU free, unless I did my maths wrong

Interestingly, under an emulated Falcon it only takes 5% CPU time. Despite more context being pushed to the stack. I don't know how accurate Hatari's Falcon emulation is however.

Cyprian · Post by **Cyprian** » Sat Jan 13, 2018 7:05 pm

have you deactivated other interrupts?

Foxie · Post by **Foxie** » Sat Jan 13, 2018 7:16 pm

Cyprian wrote:have you deactivated other interrupts?

I haven't, but then they're also running during the control benchmark. So whatever effect they have, should also affect both readings. I think the only other interrupts going on are timer C and VBL.

Foxie · Post by **Foxie** » Sun Jan 14, 2018 2:40 am

I just benchmarked timer B triggering on every line, and 87% CPU is free. On one paw, it's quicker because it only runs during 200 out of 313 scanlines. On the other paw, it's slower because bclr.b #0,$fffffa0f.w to clear the interrupt (necessary on timer B, not necessary on hsync interrupt).

Code: Select all

	SECTION TEXT
	COMMENT HEAD=1


	; Go into supervisor mode
	clr.l	-(sp)
	move.w	#$20,-(sp)
	trap	#1
	addq.l	#6,sp


	lea	withoutstr(pc),a0
	bsr.w	debugprint
	bsr.w	benchmark
	bsr.w	debugprintdecu


	lea	withstr(pc),a0
	bsr.w	debugprint

	move.l	$68.w,d7		; Save old ISR
	lea	hblrout(pc),a0		; Set new ISR
	move.l	a0,$68.w
	move.w	sr,d6			; Save old SR
	move.w	#$2100,sr		; Enable hsync

	bsr.w	benchmark

	move.w	d6,sr			; Restore old SR
	move.l	d7,$68.w		; Restore old ISR

	bsr.w	debugprintdecu

	lea	timerstr(pc),a0
	bsr.w	debugprint


	move.l	$120.w,d7		; Save old ISR
	move.b	$fffffa07.w,d6		; Save timerB int enable
	move.b	$fffffa13.w,d5		; Save timerB int mask
	move.b	$fffffa1b.w,d4		; Save timerB control
	move.b	$fffffa21.w,d3		; Save timerB data
	clr.b	$fffffa1b.w		; Stop/reset timer
	lea	timerbrout(pc),a0	; Set new ISR
	move.l	a0,$120.w
	move.b	#1,$fffffa21.w		; Set timerB data
	bset.b	#0,$fffffa07.w		; Enable interrupt
	bset.b	#0,$fffffa13.w		; Unmask interrupt
	move.b	#8,$fffffa1b.w		; Start timer

	bsr.w	benchmark

	clr.b	$fffffa1b.w		; Stop/reset timer
	move.l	d7,$120.w		; Restore old ISR
	move.b	d6,$fffffa07.w		; Restore timerB int enable
	move.b	d5,$fffffa13.w		; Restore timerB int mask
	move.b	d3,$fffffa21.w		; Restore timerB data
	move.b	d4,$fffffa1b.w		; Restore timerB control


	bsr.w	debugprintdecu

	lea	keystr(pc),a0
	bsr.w	debugprint
	bsr.w	debugwaitkey


	; Exit
	clr.w	-(sp)
	move.w	#$4c,-(sp)
	trap	#1



hblrout:
	rte


timerbrout:
	bclr.b	#0,$fffffa0f.w			; Clear int
	rte



; Returns iterations in d0.l
benchmark:
	move.l	d1,-(sp)
	clr.l	d0
	move.l	$462.w,d1
	add.l	#100,d1

.loop:	addq.l	#1,d0
	cmp.l	$462.w,d1
	bgt.b	.loop

	move.l	(sp)+,d1
	rts




; Divide d0.l by d1.l. Quotient stored in d1.l, remainder in d0.l.
; Warning: slow when dealing with large quotient outputs.
ldivide:
	move.l	d2,-(sp)
	move.l	d3,-(sp)
	clr.l	d2
	move.l	d0,d3
.loop:	sub.l	d1,d3
	bcs.b	.break
	addq.l	#1,d2
	move.l	d3,d0
	bra.b	.loop
.break:	move.l	d2,d1
	move.l	(sp)+,d3
	move.l	(sp)+,d2
	rts



; Print a string in a0
debugprint:
	movem.l	a0-a2/d0-d2,-(sp)
	move.l	a0,-(sp)
	move.w	#9,-(sp)		; c_conws
	trap	#1
	addq.l	#6,sp
	movem.l	(sp)+,a0-a2/d0-d2
	rts



; Write unsigned value as decimal (11 chars) to string, no terminator
; All 11 chars are written, padded with spaces.
; a0=string buffer, d0.l=value, d1.b=prefix char
; Returns with a0 pointing to first non-space char
debugprintdecstr:
	movem.l	d0-d3/a1-a2,-(sp)
	move.l	a0,a1
	move.b	d1,d2
	lea	.debugprintdectable(pc),a2

	; Write all 10 chars
	moveq.l	#9-1,d3
.loop:	move.l	(a2)+,d1
	bsr.w	ldivide
	add.b	#'0',d1
	move.b	d1,(a1)+
	dbf	d3,.loop
	add.b	#'0',d0
	move.b	d0,(a1)+

	; Strip leading 0s
	move.l	a0,a1
	moveq.l	#9-1,d3
.loop2:	cmp.b	#'0',(a0)
	bne.b	.break
	move.b	#' ',(a0)+
	dbf	d3,.loop2
.break:

	; Prepend prefix if not space
	cmp.b	#' ',d2
	beq.b	.skip
	move.b	d2,-(a0)
.skip:

	movem.l	(sp)+,d0-d3/a1-a2
	rts

.debugprintdectable:
	dc.l	1000000000, 100000000, 10000000, 1000000
	dc.l	100000, 10000, 1000, 100, 10



; Print all 32 bits of d0 as decimal unsigned followed by a space
debugprintdecu:
	move.l	a0,-(sp)
	move.w	d1,-(sp)
	move.w	#$2000,-(sp)
	lea	-12(sp),sp
	lea	1(sp),a0
	move.b	#$20,d1
	bsr.w	debugprintdecstr
	bsr.w	debugprint
	lea	14(sp),sp
	move.w	(sp)+,d1
	move.l	(sp)+,a0
	rts



; Wait for keypress
debugwaitkey:
	movem.l	a0-a2/d0-d2,-(sp)
	move.w	#1,-(sp)		; c_conin
	trap	#1			; Wait for keypress
	addq.l	#2,sp
	movem.l	(sp)+,a0-a2/d0-d2
	rts


	SECTION DATA
	CNOP	0,4
withoutstr	dc.b	10,13,"Iterations with no HBL: ",0
withstr		dc.b	10,13,"Iterations with HBL: ",0
timerstr	dc.b	10,13,"Iterations with Timer B: ",0
keystr		dc.b	10,13,"Press any key",10,13,0

Cyprian · Post by **Cyprian** » Sun Jan 14, 2018 11:32 am

actually bclr.b #0,$fffffa0f.w is not needed. Switch MFP into "Automatic End-interrupt mode", and you can skip that bclr.b.

Code: Select all

-------+-----+-----------------------------------------------------+----------
$FFFA17|byte |Vector Register                   BIT 7 6 5 4 3 . . .|R/W
       |     |Vector Base Offset -------------------+-+-+-' |      |
       |     |1 - *Software End-interrupt mode -------------+      |
       |     |0 - Automatic End-interrupt mode -------------'      |
       |     |* - Default operating mode                           |

TOS needs "Software End-interrupt mode", therefore first turn off all other MFP interrupts.

Foxie · Post by **Foxie** » Sun Jan 14, 2018 2:12 pm

Cyprian wrote:actually bclr.b #0,$fffffa0f.w is not needed. Switch MFP into "Automatic End-interrupt mode", and you can skip that bclr.b.

Tested that, and it's now at 90%. Noticeably faster. ^.^

Cyprian wrote: TOS needs "Software End-interrupt mode", therefore first turn off all other MFP interrupts.

I was lazy and left the MFP interrupts on for this test. It actually seems to work without crashing. The mouse can even be moved while it's in automatic mode. Are there any corner cases where it could crash? I'm wondering about stacked interrupt behaviour.

It seems odd that they didn't use automatic mode in TOS. Almost as if they had a reason not to?

Atari-Forum

STE horizontal hardware scroll

STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll

Re: STE horizontal hardware scroll