STE horizontal hardware scroll

[jury]

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

Code: Select all

$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]

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]

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]

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.

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]

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]

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]

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]

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

[Foxie]

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

[mikro]

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]

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]

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]

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

[Foxie]

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]

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%:

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

[Cyprian]

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%:

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]

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]

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]

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]

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]

have you deactivated other interrupts?

[Foxie]

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]

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]

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]

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

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?