Bippys assembler thread

BippyM · 11 March 2021, 11:33

Edit: merged my threads into one. Don't want to flood eab with my many questions that are inbound. Will keep them all here

I have been learning asm and have been trying to create an attached 32px, 16 colour sprite.

Sprite is 32px wide, by 63px tall. I have generated the sprite data using ArtPro1.20. It generates 4 sprites (1a, 1b, 2a, 2b). Any ideas why this might be?

I changed the settings to 4 colour, and then was able to attach the sprites, but naturally it loses colour info and the attached sprite looks very wrong.

The sprite is the owl from agony as a test subject

sprite from artpro below

Code:

Sprite1a:
		dc.w	$2C40,$6A00,
		dc.w	$0000,$FFFF,$0000,$FFFF,$0000,$FFFF,$0000,$FFFF
		dc.w	$0000,$FFFF,$0000,$FFFF,$0000,$FFFF,$0018,$FFFF
		dc.w	$0010,$FFFD,$0000,$FFF9,$0103,$FFF0,$0306,$FFF1
		dc.w	$0202,$FF91,$0031,$FF08,$0021,$FE1E,$0810,$FD8F
		dc.w	$1888,$FC67,$01C6,$F839,$0180,$FC7F,$20C0,$FF3F
		dc.w	$2300,$F0FF,$0600,$F1FF,$01C0,$F03F,$0060,$FF1F
		dc.w	$1100,$F8FF,$1180,$F87F,$00E0,$FC1F,$0000,$FFFF
		dc.w	$0840,$FE3F,$0018,$FFE7,$0100,$FFCF,$0040,$FFFC
		dc.w	$0002,$FFFF,$0000,$FFFF,$0008,$FFFE,$0018,$FFFE
		dc.w	$0008,$FFFC,$0000,$FFFF,$0000,$FFF8,$0030,$FFFC
		dc.w	$0010,$FFFF,$0000,$FFFC,$0010,$FFFC,$0030,$FFFF
		dc.w	$0000,$FFFC,$0010,$FFFC,$0008,$FFFE,$001F,$FFE7
		dc.w	$007C,$FFB5,$07E8,$FFA7,$FEC0,$FABF,$6600,$E5FF
		dc.w	$0D9C,$F263,$0003,$FCC0,$0120,$FEF8,$000F,$FFFF
		dc.w	$0001,$FFFF,$0000,$FFFF,$0000,$FFFF,$0000,$FFFF
		dc.w	$0000,$FFFF,$0000,$FFFF
		dc.w	$0000,$0000

Sprite1b:
		dc.w	$2C40,$6A80,
		dc.w	$FFFF,$0000,$FFFF,$0000,$FFFF,$0000,$FFFF,$0000
		dc.w	$FFFF,$0000,$FFFF,$0000,$FFFF,$0000,$FFE3,$001C
		dc.w	$FFE1,$001E,$FFE1,$001E,$FEE3,$011C,$FC76,$0388
		dc.w	$FC12,$03EC,$FE39,$01C6,$FE27,$01C0,$F191,$0E60
		dc.w	$E0E8,$1F10,$F1DE,$0E00,$FD80,$0200,$CFC0,$3000
		dc.w	$C3E0,$3C00,$E604,$1804,$F1C3,$0E03,$FF60,$0080
		dc.w	$E1EF,$1E0F,$E180,$1E00,$F0E0,$0F00,$FFCF,$000F
		dc.w	$F047,$0F87,$FF98,$0000,$FE03,$01F3,$FF80,$0043
		dc.w	$FFFC,$0003,$FFFF,$0000,$FFF0,$000F,$FFE0,$001F
		dc.w	$FFF0,$000F,$FFFE,$0000,$FFF0,$000F,$FFC0,$003F
		dc.w	$FFE3,$001C,$FFFC,$0003,$FFE0,$001F,$FFC2,$003C
		dc.w	$FFFC,$0003,$FFE0,$001F,$FFF0,$000F,$FFE3,$001C
		dc.w	$FF86,$0079,$F838,$07C8,$0340,$FC40,$FA00,$0200
		dc.w	$FD9C,$0000,$FC43,$037C,$FF80,$00FF,$FEE0,$009F
		dc.w	$FFF8,$0107,$FFFF,$0300,$FFFF,$0600,$FFFF,$0E00
		dc.w	$FFFF,$0600,$FFFF,$0C00
		dc.w	$0000,$0080

Sprite2a:
		dc.w	$2C48,$6A00,
		dc.w	$0003,$FFFF,$0007,$FFFF,$018C,$FFFF,$0300,$FFFF
		dc.w	$6000,$FFFC,$4001,$FF30,$C007,$F820,$00C6,$C421
		dc.w	$18CE,$0421,$3C8C,$8263,$1488,$8A67,$1088,$CE77
		dc.w	$0088,$EF77,$0888,$F777,$8800,$77FF,$8000,$7FFF
		dc.w	$0000,$FFFF,$0000,$FFFF,$0000,$FFFF,$0000,$FFFF
		dc.w	$0000,$FFFF,$0000,$FFFF,$0000,$FFFF,$0004,$FFFB
		dc.w	$0004,$FFFB,$0004,$FFFB,$0004,$FFFB,$0000,$FFFB
		dc.w	$0008,$FFF3,$000C,$FFF3,$0034,$FFC3,$78F4,$0703
		dc.w	$2010,$1FEF,$01F0,$FE0F,$73E0,$0C0F,$20E0,$1F0F
		dc.w	$0040,$7FAF,$67C0,$982F,$E3C0,$1C37,$40C8,$3F37
		dc.w	$07E8,$F817,$61A8,$1E57,$E388,$1C57,$070C,$F8D4
		dc.w	$C10D,$3EE8,$0246,$3DA0,$0E5C,$F1A3,$3C88,$8352
		dc.w	$7D88,$8252,$FF28,$0017,$0600,$F85A,$3E14,$C049
		dc.w	$1C14,$E0CB,$F830,$008F,$0000,$03BF,$0000,$FFFF
		dc.w	$F800,$FDFF,$0000,$6FFF,$0000,$FFFF,$0000,$FFFF
		dc.w	$0000,$FFFF,$0000,$FFFF
		dc.w	$0000,$0000

Sprite2b:
		dc.w	$2C48,$6A80,
		dc.w	$FFFC,$0003,$FFF8,$0007,$FE70,$018F,$FC70,$038F
		dc.w	$9C70,$638F,$8C21,$73DE,$0827,$F7D8,$04E7,$FB18
		dc.w	$1CEF,$E310,$BEAD,$4110,$96A9,$6110,$5289,$2100
		dc.w	$2089,$1000,$0899,$0010,$8891,$0090,$8091,$0090
		dc.w	$0451,$0450,$2249,$2248,$1129,$1128,$8929,$8928
		dc.w	$64AB,$64A8,$1B5B,$1B58,$C6BB,$C6B8,$39DF,$39D8
		dc.w	$8777,$8770,$7FF7,$7FF0,$FFF7,$FFF0,$1FF3,$1FF4
		dc.w	$EF0B,$EF04,$F00F,$F000,$07B7,$0788,$78F7,$8008
		dc.w	$2F97,$CF88,$01F7,$0008,$73E7,$8018,$20E7,$C018
		dc.w	$0F47,$8F18,$67C7,$0018,$E3C7,$0018,$4ECF,$8E10
		dc.w	$17EF,$1010,$61AF,$8010,$EF8F,$0C30,$070F,$0030
		dc.w	$CD0D,$0C32,$124E,$D031,$0E5C,$0021,$3C8A,$C067
		dc.w	$7D88,$8065,$FF38,$00D7,$0600,$01E7,$3E15,$01E2
		dc.w	$1C17,$03E0,$F83F,$07C0,$003F,$FFC0,$00FF,$FF00
		dc.w	$01FF,$FE00,$0FFF,$F000,$FFFF,$0000,$FFFF,$0000
		dc.w	$FFFF,$0000,$FFFF,$0000
		dc.w	$0000,$0080

roondar · 11 March 2021, 11:48

Quote:

Originally Posted by BippyM

Sprite is 32px wide, by 63px tall. I have generated the sprite data using ArtPro1.20. It generates 4 sprites (1a, 1b, 2a, 2b). Any ideas why this might be?

Wouldn't you expect 4 Sprites? Two Sprites combine to form one attached Sprite and Sprites are 16 pixels wide. So displaying 32 pixels wide requires 4 Sprites.

I'd personally not worry about the palette too much yet. Just set 16 different colours to make sure you have all the 16 colours available and then have 16 colours in the Sprite Data as well. If the owl is giving you problems, you could just make a self-made test sprite that just shows blocks of all 16 colours. Not as nice looking, but easier to debug for sure.

BippyM · 11 March 2021, 12:10

Quote:

Originally Posted by roondar

Wouldn't you expect 4 Sprites? Two Sprites combine to form one attached Sprite and Sprites are 16 pixels wide. So displaying 32 pixels wide requires 4 Sprites.

I think I may have misunderstood sprites and attaching. Does attaching only give more colours? I thought it allowed you to have 32px wide sprites too

DanScott · 11 March 2021, 12:16

Can't see any instances of $0000,$0000 in the sprite data too, so it appears that I won't be using and transparent pixels

roondar · 11 March 2021, 12:18

Quote:

Originally Posted by BippyM

I think I may have misunderstood sprites and attaching. Does attaching only give more colours? I thought it allowed you to have 32px wide sprites too

Ahh, now I understand the issue...

In short:

Amiga Sprites have 2 bitplanes (i.e. 4 colours, one of which is transparent)
Attached Sprites up that limit to 4 bitplanes (i.e. 16 colours, one of which is transparent)
This is achieved by displaying both Sprites that are to be attached directly on top of each other and setting the attach bit, after which the hardware does the rest
Attaching Sprites does not double the width
Only colour selection is changed when attaching
Attached Sprites do not have to be displayed on top of each other, but doing so reverts them to 4 colours (albeit with a different selection of which palette entries are used than normal)

The reason attached Sprites can't be 32 pixels wide for OCS/ECS is that the Hardware only has enough time to fetch 16 pixels of data per sprite channel/scanline. So attaching them can't increase the width as there is no time to get the extra data in the first place.

BippyM · 11 March 2021, 12:26

Quote:

Originally Posted by DanScott

Can't see any instances of $0000,$0000 in the sprite data too, so it appears that I won't be using and transparent pixels

Yeah, I have fixed that

Quote:

Originally Posted by roondar

Ahh, now I understand the issue...

In short:

Amiga Sprites have 2 bitplanes (i.e. 4 colours, one of which is transparent)
Attached Sprites up that limit to 4 bitplanes (i.e. 16 colours, one of which is transparent)
This is achieved by displaying both Sprites that are to be attached directly on top of each other and setting the attach bit, after which the hardware does the rest
Attaching Sprites does not double the width
Only colour selection is changed when attaching
Attached Sprites do not have to be displayed on top of each other, but doing so reverts them to 4 colours (albeit with a different selection of which palette entries are used than normal)

The reason attached Sprites can't be 32 pixels wide for OCS/ECS is that the Hardware only has enough time to fetch 16 pixels of data per sprite channel/scanline. So attaching them can't increase the width as there is no time to get the extra data in the first place.

Yeah, this was my confusion. I now have an owl displayed, just in the wrong colours

BippyM · 11 March 2021, 14:50

Is there any reason the transparent colour is erm... black?

roondar · 11 March 2021, 14:53

The only way this is possible is if the black pixels are not 0 in the Sprite data. I'm guessing Art-Pro kept the magenta colour as a 'real' colour rather than as transparent when converting.

Edit: I'd either try recreating the source IFF with the purple set to colour 0 or colour 16. Either should work, but colour 0 is probably the safest choice.

BippyM · 14 March 2021, 22:41

Hi Guys,

I have been messing with asm, and with the help of various sources (mcgeezer, roondar, photons tutorials) I have managed to get an iff loaded, and then the agony main character as 4x hardware sprites to animate.

I do have an issue with the animation of the sprite. It starts of glitchy, and then it rights itself. It does this exactly the same everytime so it is consistent, does anyone have any advice on where I need to look to rectify and understand why the sprites are glitchy.

Here is a video showing the corruption

[ Show youtube player ]

and here is a link to my code
https://github.com/Bippym/Amiga_Asm_Learning

The bulk of the code is in Main.asm with the sprites in owl.src.

I am not looking for feedback on my actual source etc, but I am open to constructive advice

Remember I am learning here, and besides a copperbar this is more than I have done in the past. Also note there is some unused/old code that I haven't removed yet. (Sprite movement is going to be removed as it was used on a single sprite).

Also with the sprite offsets I will be moving over to a table stored just before the sprite data, as there wont be any need to have the math in the loop.

Cheers

Galahad/FLT · 14 March 2021, 22:59

Quote:

Originally Posted by BippyM

Hi Guys,

I have been messing with asm, and with the help of various sources (mcgeezer, roondar, photons tutorials) I have managed to get an iff loaded, and then the agony main character as 4x hardware sprites to animate.

I do have an issue with the animation of the sprite. It starts of glitchy, and then it rights itself. It does this exactly the same everytime so it is consistent, does anyone have any advice on where I need to look to rectify and understand why the sprites are glitchy.

Here is a video showing the corruption

[ Show youtube player ]

and here is a link to my code
https://github.com/Bippym/Amiga_Asm_Learning

The bulk of the code is in Main.asm with the sprites in owl.src.

I am not looking for feedback on my actual source etc, but I am open to constructive advice

Remember I am learning here, and besides a copperbar this is more than I have done in the past. Also note there is some unused/old code that I haven't removed yet. (Sprite movement is going to be removed as it was used on a single sprite).

Also with the sprite offsets I will be moving over to a table stored just before the sprite data, as there wont be any need to have the math in the loop.

Cheers

It looks to me you've got an ordering problem.

So, your code does the following:

1). setup screen DMA and sprites $87e0,DMACON
2). then you're activating interrupts where you $c010,INTENA
3). Then you're pointing to your copperlist and then strobing it to activate it

move.l copperlist,cop1lch(a5)
move.w #0,cop1jmp(a5)

Your next routine is to animate your sprites.

The problem is, you've already setup screen DMA (i.e. telling the Amiga lets display stuff!) and activated your copperlist, so the Amiga is now going to try and display what its being told, and at that point, you haven't actually done your sprite pointers, so the copperlist is going to be displaying whatever is in the copperlist before you edit it, and whilst your sprite pointers all say $0 at this point, that also equates to address 0, where it might interpret data from there.

So, before you strobe the copper (0,cop1jmp), you need to animate your first sprite so your copperlist is correctly setup from the word go, then strobe your copperlist, then continue animated sprites.

BippyM · 14 March 2021, 23:06

Quote:

Originally Posted by Galahad/FLT

It looks to me you've got an ordering problem.

So, your code does the following:

1). setup screen DMA and sprites $87e0,DMACON
2). then you're activating interrupts where you $c010,INTENA
3). Then you're pointing to your copperlist and then strobing it to activate it

move.l copperlist,cop1lch(a5)
move.w #0,cop1jmp(a5)

Your next routine is to animate your sprites.

The problem is, you've already setup screen DMA (i.e. telling the Amiga lets display stuff!) and activated your copperlist, so the Amiga is now going to try and display what its being told, and at that point, you haven't actually done your sprite pointers, so the copperlist is going to be displaying whatever is in the copperlist before you edit it, and whilst your sprite pointers all say $0 at this point, that also equates to address 0, where it might interpret data from there.

So, before you strobe the copper (0,cop1jmp), you need to animate your first sprite so your copperlist is correctly setup from the word go, then strobe your copperlist, then continue animated sprites.

Thanks for the quick reply Galahad,

Even though I jump to setup my copperlist before I close the system and before the animation routine, it isn't setup? (excuse my ignorance, just trying to follow what is happening internally)

Is it okay to animate the sprite without displaying it?

Galahad/FLT · 14 March 2021, 23:08

Quote:

Originally Posted by BippyM

Thanks for the quick reply Galahad,

Even though I jump to setup my copperlist before I close the system and before the animation routine, it isn't setup? (excuse my ignorance, just trying to follow what is happening internally)

Is it okay to animate the sprite without displaying it?

OK, so your copperlist is 99.99% setup, the only thing its missing is the changes in the sprite pointers which you're doing every frame.

The problem is, you're activating the copperlist before you've put in your first set of sprite pointers.

You of course can animate the sprite before you display it, obviously you won't see it until you strobe the copperlist, but at least when you do, the sprite pointers in your copperlist when it activates will all be pointing to correct data.

roondar · 14 March 2021, 23:12

Sprite pointer 7 isn't being set in the Copperlist. This will probably cause issues.

BippyM · 14 March 2021, 23:13

Thanks pal,

I believe it is fixed. I wasn't setting the sprite pointer for sprite 7 (roondar spotted this on mcgeezers discord channel)

Code:

SetSprite:
; left half of the owl. Sprite 0
move.la0,spr0copaddr                                     ; Offset to the sprite copper address
move.l     #8-5,d7; Number of sprites (8 - the attached sprites 0/1 and 2/3)

lea        Sprite1a,a1; Sprite address
move.l     #(SPR0PTH<<16),d0; Sprite high pointer $01020000
move.la1,d1; Address of sprite copied
swapd1; swap the address round so the high word is moveable
move.wd1,d0; and move it into d0 (d0 = $0102xxxx)
move.ld0,(a0)+                                           ; Pop it into the copperlist
swapd1; Swap the address back
add.l      #$20000,d0; move to the SPR0PTL
move.wd1,d0; Low part of the address in
move.ld0,(a0)+                                           ; And pop the address into the copper

; Sprite 1, attached
move.la0,spr1copaddr                                     ; Save attached sprite address
lea        Sprite1b,a1; Attach sprite location
move.l     #(SPR1PTH<<16),d0; Sprite 1 high pointer
move.la1,d1; Address of sprite copied
swapd1; swap the address round so the high word is moveable
move.wd1,d0; and move it into d0 (d0 = $0102xxxx)
move.ld0,(a0)+                                           ; Pop it into the copperlist
swapd1; Swap the address back
add.l      #$20000,d0; move to the SPRxPTL
move.wd1,d0; Low part of the address in
move.ld0,(a0)+                                           ; And pop the address into the copper

; Right half of the owl Sprite 2
move.la0,spr2copaddr                                     ; Save attached sprite address
lea        Sprite2a,a1; Attach sprite location
move.l     #(SPR2PTH<<16),d0; Sprite 1 high pointer
move.la1,d1; Address of sprite copied
swapd1; swap the address round so the high word is moveable
move.wd1,d0; and move it into d0 (d0 = $0102xxxx)
move.ld0,(a0)+                                           ; Pop it into the copperlist
swapd1; Swap the address back
add.l      #$20000,d0; move to the SPRxPTL
move.wd1,d0; Low part of the address in
move.ld0,(a0)+                                           ; And pop the address into the copper

; Sprite 2, attached
move.la0,spr3copaddr                                     ; Save attached sprite address
lea        Sprite2b,a1; Attach sprite location
move.l     #(SPR3PTH<<16),d0; Sprite 1 high pointer
.3move.la1,d1; Address of sprite copied
swapd1; swap the address round so the high word is moveable
move.wd1,d0; and move it into d0 (d0 = $0102xxxx)
move.ld0,(a0)+                                           ; Pop it into the copperlist
swapd1; Swap the address back
add.l      #$20000,d0; move to the SPRxPTL
move.wd1,d0; Low part of the address in
move.ld0,(a0)+                                           ; And pop the address into the copper

move.b     #1,spr_cur_frame                                   ; Set the initial animation frame


; Set the null sprites for the remaining 6 sprites
add.l      #$20000,d0; next SPRxPTH
lea        NullSpr,a1; pointer to the null sprite data
 dbfd7,.3

Fixed it by changing the loop counter to #8-4

Quote:

Originally Posted by Galahad/FLT

OK, so your copperlist is 99.99% setup, the only thing its missing is the changes in the sprite pointers which you're doing every frame.

The problem is, you're activating the copperlist before you've put in your first set of sprite pointers.

You of course can animate the sprite before you display it, obviously you won't see it until you strobe the copperlist, but at least when you do, the sprite pointers in your copperlist when it activates will all be pointing to correct data.

11 March 2021, 14:50	#7
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	Is there any reason the transparent colour is erm... black? Attached Thumbnails

14 March 2021, 22:41	#9
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	Sprite corruption Hi Guys, I have been messing with asm, and with the help of various sources (mcgeezer, roondar, photons tutorials) I have managed to get an iff loaded, and then the agony main character as 4x hardware sprites to animate. I do have an issue with the animation of the sprite. It starts of glitchy, and then it rights itself. It does this exactly the same everytime so it is consistent, does anyone have any advice on where I need to look to rectify and understand why the sprites are glitchy. Here is a video showing the corruption [ Show youtube player ] and here is a link to my code https://github.com/Bippym/Amiga_Asm_Learning The bulk of the code is in Main.asm with the sprites in owl.src. I am not looking for feedback on my actual source etc, but I am open to constructive advice Remember I am learning here, and besides a copperbar this is more than I have done in the past. Also note there is some unused/old code that I haven't removed yet. (Sprite movement is going to be removed as it was used on a single sprite). Also with the sprite offsets I will be moving over to a table stored just before the sprite data, as there wont be any need to have the math in the loop. Cheers

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Which assembler to use	BanisterDK	Coders. General	4	10 January 2012 15:13
C to assembler	Jherek Carnelia	Coders. General	5	23 July 2011 20:22
Bippys WHDLoad Project	BippyM	project.WHDLoad	23	27 March 2007 00:05
How do i get to bippys ftp ????	synchro	Amiga scene	9	14 March 2004 23:12

11 March 2021, 12:16	#4
DanScott Lemon. / Core Design Join Date: Mar 2016 Location: Tier 5 Posts: 1,212	Can't see any instances of $0000,$0000 in the sprite data too, so it appears that I won't be using and transparent pixels

11 March 2021, 14:53	#8
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,411	The only way this is possible is if the black pixels are not 0 in the Sprite data. I'm guessing Art-Pro kept the magenta colour as a 'real' colour rather than as transparent when converting. Edit: I'd either try recreating the source IFF with the purple set to colour 0 or colour 16. Either should work, but colour 0 is probably the safest choice.

14 March 2021, 23:12	#13
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,411	Sprite pointer 7 isn't being set in the Copperlist. This will probably cause issues.

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