AGA Palette... how to implement

[Steve]

So I managed to get a 32 colour RAW image loaded successfully and now I want to try a 256 colour image. I am using the classic Tutankhamen image from DPaint IV AGA. So I exported that image as a 256 colour binary (Raw?) image (non-interleaved) using PicCon.

Now I know the palette has to be done seperately which is pretty damn annoying and a lot more complicated for 256 colour images. Just to be clear I am setting the correct screenmodes for AGA ($0210) so that is all good I think. What I am not setting yet is bplcon3 bit 9 (LOCT) as mentioned here in this old thread:

http://ada.untergrund.net/?p=boardthread&id=37

The image I get is scrambled though because I haven't a clue how to implement this damn palette. Any hints would be appreciated. I have exported the palette from PicCon as a binary palette and also an Asm source which is posted below. Which one is the easiest to use and how do I implement this damn palette with regards to setting this bit 9 in bplcon3??

Surely I don't have to do this by hand?? Would take me hours!

Any help is much appreciated!

[NorthWay]

The easy way is to save palette as 24-bit copperlist. Just lightly edit it (no sections or labels) and include(not incbin) it as part of your copperlist (which is mostly redundant if you don't keep changing the colours - set them just the once).
Alternatively, just include the same copperlist somewhere and loop over it as a "customoffset,value" pair? You'd do the same job the copper does, only just once.

[Steve]

I only just found these palette setting in PicCon. Which do you suggest I use? The 32bit setting?

[ross]

Originally Posted by Steve

I only just found these palette setting in PicCon. Which do you suggest I use? The 32bit setting?

These settings are right.

PicCon also make the BPLCON3 settings for you.
You simply need to incbin in your copper list.

[Steve]

Originally Posted by ross

These settings are right.

PicCon also make the BPLCON3 settings for you.
You simply need to incbin in your copper list.

Thanks, I seem to have got a bit closer to the correct colours. Looking a bit strange though and it's glitching-out a lot.

I wonder what I'm doing wrong.

[Steve]

Right I think I've found the 'source' of the problem (sorry)

; Work out the bitplane sizes and addresses and pass to the copperlist.
; Bitplane info: 320*256*8. 40 words per line, 256 lines. 320x356/8bits = 10240bytes
; 10240*5=50kb : 2560 longs per bitplane
;
	lea	bp1h,a0			; first bitplane address in the copper
	moveq	#BITPLANES-1,d0		; Number of bitplanes (BTIPLANES EQU 8)
	move.l	#image,d1		; Address of the picture into d1

	setbpl:
		move.w	d1,6(a0)							; bitplane low address pointer
		swap	d1
		move.w	d1,2(a0)							; bitplane high address
		addq.w	#8,a0								; Point to next bitplane
		swap d1
		add.l 	#10240,d1							; 10240 added for next plane
		dbf d0,setbpl								; branch until all bitplanes are copied

I've not updated these calculations yet! Doh! Scratching my head about the formula for 8 bitplanes. Hmmm.

I've tried increasing the value added to $81920 but that makes it look worse. I bet the solution is obvious to someone.

[robinsonb5]

Probably a silly question, but have you added instructions to set all eight bitplanes to the copperlist? It looks from your screenshot as though at least one bitplane is showing non-image data.

[Steve]

Originally Posted by robinsonb5

Probably a silly question, but have you added instructions to set all eight bitplanes to the copperlist? It looks from your screenshot as though at least one bitplane is showing non-image data.

Not a silly question at all. It's a very valid question. Probably what I'm missing. Bugger. lol.

I'm only doing 6 bitplanes. I need to look at this. Not too sure about this part. Still learning this stuff.

mycopper:			
;	dc.w	BPLCON0,$3200					; %0011001000000000 (3 bitplanes - 8 colours)
;	dc.w	BPLCON0,$5200					; %0101001000000000 (5 bitplanes - 32 colours)
	dc.w	BPLCON0,$0210					; %0101001000000000 (8 bitplanes - 256 colours)
	dc.w	BPLCON1,$0000
	dc.w	BPL1MOD,$0000,BPL2MOD,$0000
	dc.w	DIWSTRT,$2C81,DIWSTOP,$2CC1
	dc.w	DDFSTRT,$0038,DDFSTOP,$00D0
bp1h:	dc.w	BPL1PTH,$0000					; Bitplane 1 high bytes register, use offset
bp1l:	dc.w	BPL1PTL,$0000					; Bitplane 1 high value, Bitplane 1 low register
bp2h:	dc.w	BPL2PTH,$0000					; Bitplane 2 high bytes register, use offset
bp2l:	dc.w	BPL2PTL,$0000					; Bitplane 2 high value, Bitplane 1 low register
bp3h:	dc.w	BPL3PTH,$0000					; Bitplane 3 high bytes register, use offset
bp3l:	dc.w	BPL3PTL,$0000					; Bitplane 3 high value, Bitplane 1 low register
bp4h:	dc.w	BPL4PTH,$0000					; Bitplane 4 high bytes register, use offset
bp4l:	dc.w	BPL4PTL,$0000					; Bitplane 4 high value, Bitplane 1 low register
bp5h:	dc.w	BPL5PTH,$0000					; Bitplane 5 high bytes register, use offset
bp5l:	dc.w	BPL5PTL,$0000					; Bitplane 5 high value, Bitplane 1 low register
bp6h:	dc.w	BPL6PTH,$0000					; Bitplane 6 high bytes register, use offset
bp6l:	dc.w	BPL6PTL,$0000					; Bitplane 6 high value, Bitplane 1 low register

[ross]

Originally Posted by Steve

Right I think I've found the 'source' of the problem (sorry)

I've not updated these calculations yet! Doh! Scratching my head about the formula for 8 bitplanes. Hmmm.

I've tried increasing the value added to $81920 but that makes it look worse. I bet the solution is obvious to someone.

No , the calculation is correct. A bitplane is a bitplane, only the numbers of is changed.
But the real question is: have you inserted in copper list the extra bitplane pointers required to update the extra planes?


EDIT: ok posted before I've seen your post above and as guessed the extra bitplane pointers are missing

Insert:

bp7h:	dc.w	BPL7PTH,$0000
bp7l:	dc.w	BPL7PTL,$0000
bp8h:	dc.w	BPL8PTH,$0000
bp8l:	dc.w	BPL8PTL,$0000

You are lucky the machine have not crashed, overwriting unwanted memory locations with your code.

[Steve]

Thanks for the help Ross. I'm close I think.

I had to manually add in the new registers to my registers.i file and odd things are happening!

If I add the code like this:

BPL1PT          equ     bplpt+$00
BPL1PTH         equ     bplpt+$00
BPL1PTL         equ     bplpt+$02
BPL2PT          equ     bplpt+$04
BPL2PTH         equ     bplpt+$04
BPL2PTL         equ     bplpt+$06
BPL3PT          equ     bplpt+$08
BPL3PTH         equ     bplpt+$08
BPL3PTL         equ     bplpt+$0A
BPL4PT          equ     bplpt+$0C
BPL4PTH         equ     bplpt+$0C
BPL4PTL         equ     bplpt+$0E
BPL5PT          equ     bplpt+$10
BPL5PTH         equ     bplpt+$10
BPL5PTL         equ     bplpt+$12
BPL6PT          equ     bplpt+$14
BPL6PTH         equ     bplpt+$14
BPL6PTL         equ     bplpt+$16
BPL7PT          equ     bplpt+$18
BPL7PTH         EQU     bplpt+$18
BPL7PTL         EQU     bplpt+$20
BPL8PT          EQU     bplpt+$22
BPL8PTH         EQU     bplpt+$22
BPL8PTL         EQU     bplpt+$24

Then all I get is a grey screen?? The image is gone completely!

EDIT: Ah okay schoolboy error here. Should be $1A, $1C, $1E rght?? Still doesn't explain why the version below doesn't work.

So if I change the last few lines to this (looks correct this time):

BPL7PTH         EQU     $0F8
BPL7PTL         EQU     $0FA
BPL8PTH         EQU     $0FC
BPL8PTL         EQU     $0FE

Then I get an image but it is corrupted. Am I missing something here?? I've added the new lines for clearing BPL7 and BPL8 to my copperlist so it should work now shouldn't it? #confused

[ross]

Is you image steady now, isnt it?
Then last bitplanes for some reason is not properly initialized in copper list.
You can attach your code if you want, also a zip archive.
Hard to help you otherwise.

[Steve]

yeah it's steady now. I'll up it the zone for you.

[ross]

Check tut.raw file dimension

From your code:

; Bitplane info: 320*256*8. 40 words per line, 256 lines. 320x256/8bits = 10240bytes

x8=?

[Steve]

Originally Posted by ross

Check tut.raw file dimension

From your code:

; Bitplane info: 320*256*8. 40 words per line, 256 lines. 320x256/8bits = 10240bytes

x8=?

Ah, The code was taken from someone else so all the comments are someone else's. I realise the picture is actually 320x200 but wasn't aware I need to change anything? But the display is 320x256 is not? Standard PAL Low Res.

I guess the screenmode has to match the picture resolution. Seems obvious I guess. So I need to open an NTSC screenmode??

[ross]

Originally Posted by Steve

Ah, The code was taken from someone else so all the comments are someone else's. I realise the picture is actually 320x200 but wasn't aware I need to change anything? But the display is 320x256 is not? Standard PAL Low Res.

You have to adapt screen to picture.
File seems to be for a 320x200 picture, your copper code for a 320x256 screen.
So you need a new raw grab for the image or a change in copper values

EDIT:

Originally Posted by Steve

EDIT: I guess the screenmode has to match the picture resolution. Seems obvious I guess. So I need to open an NTSC screenmode??

For a 320x200 screen you need DIWSTOP,$F4C1

Actually not an NTSC screen but a restricted 320x200 PAL screen .
If you want real NTSC video signal you need also another register change in addition (and an ECS Agnus because you are in PAL territory).

[Steve]

Fantastic! It works. Thank you.

I changed the image to a 320x256 one and converted it again to a raw file.

Here is the correct image.

EDIT: use DIWSTOP,$F4C1

This didn't work for some reason. Is this to get the original (320x200) file to work?. Would I also need to set some other register for NTSC?

[ross]

Originally Posted by Steve

I changed the image to a 320x256 one and converted it again to a raw file.

This didn't work for some reason. Is this to get the original (320x200) file to work?. Would I also need to set some other register for NTSC?

Yes, for the original file.
See my edit to previous message.

For real NTSC video you need to modify BEAMCON0, but better leave it alone

[Steve]

Hmmm. It would be nice to have the original file working with a restricted screen - good stuff to know.

However setting DIWSTOP to $F4C1 isn't working. See image below.

Is this because of the code in post #6?

[roondar]

Originally Posted by Steve

Is this because of the code in post #6?

Yes. If you resize the picture to something other than 320x256, the add.l #10240,d1 needs to be changed to reflect the new size - otherwise your bitplane pointers will point to something other than picture data

[ross]

Originally Posted by Steve

Hmmm. It would be nice to have the original file working with a restricted screen - good stuff to know.

However setting DIWSTOP to $F4C1 isn't working. See image below.

Is this because of the code in post #6?

Yes, you have a bitplane of 320x200/8bits.

So you need an

add.l #8000,d1

instead.