Horizontal Scrolling with 4x Fetch and all sprites

mcgeezer · 04 December 2018, 22:14

Hi All,

I've been reading up on a few threads today regarding the Amiga AGA's ability to scroll horizontally (256 pixels undisturbed).

It seems though that the only way to scroll with 4x bitplane fetch is to start DDFSTRT at $18 and lose most of the HW sprites.

Has the experienced coders here ever managed to achieve this?

Geezer

roondar · 04 December 2018, 22:53

I've been mucking about with AGA scrolling & sprites with 4x fetch but so far haven't managed something useful. Mainly due to the alignment restrictions of the bitplanes.

So far, my best result for 256 pixels wide @ 4x fetch + scrolling is basically the standard X position of the screen + 64 pixels. It may be possible to make this into a DDFSTRT at $34 (using the same trick to do so as would be used on the A500), but that would not change much.

I originally thought you might be able to do much better, but I forgot the bitplanes need to be aligned to 64 bits at all times in 4x fetch mode

ross · 04 December 2018, 22:56

Quote:

Originally Posted by mcgeezer

I've been reading up on a few threads today regarding the Amiga AGA's ability to scroll horizontally (256 pixels undisturbed).

256 quarter pixels, 64 low-res pixels.

Quote:

It seems though that the only way to scroll with 4x bitplane fetch is to start DDFSTRT at $18 and lose most of the HW sprites.

Unfortunately yes if you want the standard 320x screen with DIWSTART=xx81 and full 64px wide scroll.

mcgeezer · 04 December 2018, 22:57

Quote:

Originally Posted by roondar

I've been mucking about with AGA scrolling & sprites with 4x fetch but so far haven't managed something useful. Mainly due to the alignment restrictions of the bitplanes.

So far, my best result for 256 pixels wide @ 4x fetch + scrolling is basically the standard X position of the screen + 64 pixels. It may be possible to make this into a DDFSTRT at $34 (using the same trick to do so as would be used on the A500), but that would not change much.

I originally thought you might be able to do much better, but I forgot the bitplanes need to be aligned to 64 bits at all times in 4x fetch mode

Thanks Roondar - I know we discussed this over pm, but I just wanted to canvas opinion for the other devs.

I'm actually looking at Aladdin now and it it running in 4x fetch mode, I can't tell yet though if it has all the sprites available (doesn't look like it).

Geezer

roondar · 04 December 2018, 23:03

One thing I have considered, but not programmed/tried yet is a 'partial' approach where you use the standard $38 ddfstrt and use a display window that is shifted by 16 or 32 pixels to the right.

Then, using 4x fetch it should be possible to scroll by either 16 or 32 pixels using the hardware without odd effects (using a delay of the right values to only shift this many pixels without showing empty space). This then gives you 16 or 32 frames to create a 16 or 32 pixel shifted version of the screen in a new bitmap buffer.

This might work. It will take a whole bunch of memory though (2 additional full screen buffers) and I've not calculated to see if the extra Blitter/CPU cost of drawing the screens this way is actually smaller than the gains for 4x fetch mode.

Edit: did a bit of back-of-the-envelope calculation and it seems that this method probably does not gain you any time. It probably won't lose you any either, but meh - not super useful.

mcgeezer · 04 December 2018, 23:05

Quote:

Originally Posted by ross

256 quarter pixels, 64 low-res pixels.

Unfortunately yes if you want the standard 320x screen with DIWSTART=xx81 and full 64px wide scroll.

Cheers Ross.

Considering my Rygar implementation though it is running in 2x fetch mode. The challenge is to know if it's technically possible to get it running in 4x fetch mode.

When I played around with this initially I couldn't get it to work so settled on 2x mode... but the playfield is only 256px wide so I'm unsure if it is achievable or not.

ross · 04 December 2018, 23:21

Quote:

Originally Posted by mcgeezer

Cheers Ross.

Considering my Rygar implementation though it is running in 2x fetch mode. The challenge is to know if it's technically possible to get it running in 4x fetch mode.

When I played around with this initially I couldn't get it to work so settled on 2x mode... but the playfield is only 256px wide so I'm unsure if it is achievable or not.

Not if you want a centered screen.
1x -> DDFSTART=$38 -> DIWSTART=$91, DIWSTOP=$1b1 -> 288px
2x -> DDFSTART=$38 -> DIWSTART=$a1, DIWSTOP=$1a1 -> 256px
4x -> DDFSTART=$38 -> DIWSTART=$c1, DIWSTOP=$181 -> 192px

Sure you can have a screen in 4x with a 64px left screen part covered by sprites, and a full 256px right part, but for another game

Cheers

mcgeezer · 04 December 2018, 23:33

Quote:

Originally Posted by ross

Not if you want a centered screen.
1x -> DDFSTART=$38 -> DIWSTART=$91, DIWSTOP=$1b1 -> 288px
2x -> DDFSTART=$38 -> DIWSTART=$a1, DIWSTOP=$1a1 -> 256px
4x -> DDFSTART=$38 -> DIWSTART=$c1, DIWSTOP=$181 -> 192px

Sure you can have a screen in 4x with a 64px left screen part covered by sprites, and a full 256px right part, but for another game

Cheers

Thanks Ross, that's pretty much what I calculated as well.

Here's my copper init routine... Just slightly different i guess.

Code:

;
; INIT_COPPER
; 
; Initialize the Copper list
;
INIT_COPPER1:
	move.l	MEMCHK2_COPPER1,a1
	move.l	a1,d4

	move.w	#BPLCON4,(a1)+
	move.w	#$0011,(a1)+

	move.w	#FMODE,(a1)+
	move.w	#5,(a1)+

	move.w	#DIWSTRT,(a1)+	; 
	move.w	#$2cbe,(a1)+	; 	; 
	move.w	#DIWSTOP,(a1)+	; 
	IFNE	DEBUG_BORDER_ENABLE
	move.w	#$ffd2,(a1)+	;  	; 1b2 - be = f4 (244) pixels (debpt =$ec)
	ELSE
	move.w	#$ffb2,(a1)+	;  	; 1b2 - be = f4 (244) pixels (debpt =$ec)
	ENDC

	move.w	#DDFSTRT,(a1)+	; 
	move.w	#$0038,(a1)+	; 3c
	move.w	#DDFSTOP,(a1)+  ; 
	move.w	#$00d0,(a1)+	; a4

; Initialise Normal Sprite DMA
	bsr	INIT_COPPER_SPRITES

ross · 04 December 2018, 23:42

Quote:

Originally Posted by mcgeezer

Thanks Ross, that's pretty much what I calculated as well.

Here's my copper init routine... Just slightly different i guess.

Code:

;
; INIT_COPPER
; 
; Initialize the Copper list
;
INIT_COPPER1:
	move.l	MEMCHK2_COPPER1,a1
	move.l	a1,d4

	move.w	#BPLCON4,(a1)+
	move.w	#$0011,(a1)+

	move.w	#FMODE,(a1)+
	move.w	#5,(a1)+

	move.w	#DIWSTRT,(a1)+	; 
	move.w	#$2cbe,(a1)+	; 	; 
	move.w	#DIWSTOP,(a1)+	; 
	IFNE	DEBUG_BORDER_ENABLE
	move.w	#$ffd2,(a1)+	;  	; 1b2 - be = f4 (244) pixels (debpt =$ec)
	ELSE
	move.w	#$ffb2,(a1)+	;  	; 1b2 - be = f4 (244) pixels (debpt =$ec)
	ENDC

	move.w	#DDFSTRT,(a1)+	; 
	move.w	#$0038,(a1)+	; 3c
	move.w	#DDFSTOP,(a1)+  ; 
	move.w	#$00d0,(a1)+	; a4

; Initialise Normal Sprite DMA
	bsr	INIT_COPPER_SPRITES

Yes, your values are a bit 'strange', but I can be wrong, I make some test and report.

mcgeezer · 04 December 2018, 23:48

Quote:

Originally Posted by ross

Yes, your values are a bit 'strange', but I can be wrong, I make some test and report.

Probably wise I drop in the whole list then.

(or most of it)

Code:

; Initialise Normal Sprite DMA
	bsr	INIT_COPPER_SPRITES

; Wait for line 26
	move.l	#$1a01ff00,(a1)+
	;bsr	RESET_COPPER_SPRITES

; Upper sprite zone
	lea	COPPTR_HARDWARE_UPPER_SPRITE_0-data(a4),a3
	bsr	CREATE_COPPER_SPRITE_POINTERS

; Set display properties, modulo, bitplanes...
	move.l	a1,COPPTR_BPLCON-data(a4)
	move.w	#BPLCON0,(a1)+ 	; 0		; This is play area
	move.w	#$0000,(a1)+   	; 2		; 8 PLanes here
	move.w	#BPLCON1,(a1)+ 	; 4
	move.w	#0,(a1)+  	; 6
	move.w	#BPLCON2,(a1)+	; 8
	move.w	#$30,(a1)+	; 10
	move.w	#BPL1MOD,(a1)+	;
	move.w	#$9c,(a1)+	; a0
	move.w	#BPL2MOD,(a1)+	;
	move.w	#$9c,(a1)+	; a0

; Load Main Palette
	lea	PAL_RYGAR_FG,a0
	move.l	#$180,d2
	moveq	#32-1,d7
	
.main_pal:
	move.l	#$01060c00,(a1)+
	move.w	d2,(a1)+
	move.w	(a0)+,(a1)+
	move.l	#$01060e00,(a1)+
	move.w	d2,(a1)+
	move.w	(a0)+,(a1)+
	addq.w	#2,d2
	dbf	d7,.main_pal

ross · 04 December 2018, 23:58

My values are correct, test the attach (total garbage test

).

9x 32bit fetch, DDFSTRT=$38, DIWSTRT=$2ca1
Shift screen with left/right mouse buttons.
Both to exit.

EDIT: I do not know what I've uploaded before, this is the right test

EDIT2: you've a DMA surplus fetch (11x!), you cut to much DIW and video is too much to right
but better rethink at it tomorrow

MORNING EDIT: the best you can do with FMODE=7 is in tgt_x5
5x 64bit fetch, DDFSTRT=$30, DIWSTRT=$2cb1 to $1b1 (much similar as yours)
1 sprite missing in action.. but massive bandwidth gain [5x vs 11x(or better 9x)]

04 December 2018, 22:14	#1
mcgeezer Registered User Join Date: Oct 2017 Location: Sunderland, England Posts: 2,702	Horizontal Scrolling with 4x Fetch and all sprites Hi All, I've been reading up on a few threads today regarding the Amiga AGA's ability to scroll horizontally (256 pixels undisturbed). It seems though that the only way to scroll with 4x bitplane fetch is to start DDFSTRT at $18 and lose most of the HW sprites. Has the experienced coders here ever managed to achieve this? Geezer

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
AGA Fetch mode testing	earok	Coders. Blitz Basic	1	29 September 2017 01:25
Horizontal vs vertical scrolling	Amiga1992	Coders. General	20	26 October 2015 11:15
Parallax scrolling layer with sprites possible?	phx	Coders. Asm / Hardware	21	12 July 2015 18:15
Details of the AGA double CAS fetch mode?	Leffmann	Coders. General	3	29 July 2008 11:26
Watchtower - jumpy horizontal scrolling	Tim Janssen	support.Games	0	14 December 2004 22:16

04 December 2018, 22:53	#2
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,420	I've been mucking about with AGA scrolling & sprites with 4x fetch but so far haven't managed something useful. Mainly due to the alignment restrictions of the bitplanes. So far, my best result for 256 pixels wide @ 4x fetch + scrolling is basically the standard X position of the screen + 64 pixels. It may be possible to make this into a DDFSTRT at $34 (using the same trick to do so as would be used on the A500), but that would not change much. I originally thought you might be able to do much better, but I forgot the bitplanes need to be aligned to 64 bits at all times in 4x fetch mode

04 December 2018, 23:03	#5
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,420	One thing I have considered, but not programmed/tried yet is a 'partial' approach where you use the standard $38 ddfstrt and use a display window that is shifted by 16 or 32 pixels to the right. Then, using 4x fetch it should be possible to scroll by either 16 or 32 pixels using the hardware without odd effects (using a delay of the right values to only shift this many pixels without showing empty space). This then gives you 16 or 32 frames to create a 16 or 32 pixel shifted version of the screen in a new bitmap buffer. This might work. It will take a whole bunch of memory though (2 additional full screen buffers) and I've not calculated to see if the extra Blitter/CPU cost of drawing the screens this way is actually smaller than the gains for 4x fetch mode. Edit: did a bit of back-of-the-envelope calculation and it seems that this method probably does not gain you any time. It probably won't lose you any either, but meh - not super useful. Last edited by roondar; 04 December 2018 at 23:14.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)