Word vs not word aligned playfield question

[nandius_c]

Hi everyone,

I've been playing around for a while with the blitter working with even and odd bytes and while doing some tests I've found a playfield issue I can't explain. I have a 4 bitplane .IFF file that I use for the background of my game. If I word align (EVEN) the playfield it seems to appear on the right place of the screen (see 'Word aligned playfield.png'):

EVEN
bfr: INCBIN "images/background.raw"

But what I can't explain is what happens when It's not word aligned (when I remove the EVEN instruction, see 'NOT word aligned playfield.png'), as the entire playfield moves some pixels to the right but keeps perfectly displayed ( the image remains the same in colour and shape). I know that bitplane pointers have to contain even addresses but can't see how having an odd address in the bitplane pointers can drive to this result: moving the entire platfield to the right when the difference between these two alignments is just 1 byte...

Can anybody explain why this is happening, please?

Thanks in advance for your help .

Regards.

[phx]

Originally Posted by nandius_c

I have a 4 bitplane .IFF file that I use for the background of my game. If I word align (EVEN) the playfield it seems to appear on the right place of the screen

The BPLxPTL registers will ignore the LSB. So when the displayed bitmap is not word-aligned the display will actually start one byte earlier.

This would result in an uninitialized byte in the upper-left edge, but it cannot explain the shift of the full display window.

Can anybody explain why this is happening, please?

I can't. Does it happen with UAE only, or also with real hardware?

[Toni Wilen]

Some other data after the bitplane data that also gets unaligned and it should not be unaligned? Long AGA fetch mode? (It has even larger alignment requirements and results can be unexpected if it is misaligned)

Not enough information available, screen shot does not really show where bitplane data starts vs edge of visible area.

[Mrs Beanbag]

what I'd expect is simply the image to be shifted 8 pixels to the right, with the rightmost 8 pixels appearing at the start of the next line. There is no reason for the colour or shape to change.

[Toni Wilen]

8-bit shift would be totally impossible result. DMA pointers are always word aligned (or longer in AGA), bit 0 does not exist. (as replied above too)

[nandius_c]

Hi everyone,

I totally agree with you in that the result I'm getting is unexpected, that's why I'm asking . I'm trying to prepare a simple example isolating the relevant code. In the meantime, two comments in case they can help to find out what's happening:

- To move the playfield to an odd address I do this (ugly, but just to be sure... ):

EVEN
null dc.b 0
bfr: INCBIN "images/background.raw"

- Bitplane pointers are poked into copper list during initialization, something like this (4 bitplanes):

move.l #bfr,d0
swap d0
move.w d0,CopBplP0+2
swap d0
move.w d0,CopBplP0+6

move.l #bfr+40,d0
swap d0
move.w d0,CopBplP1+2
swap d0
move.w d0,CopBplP1+6

move.l #bfr+80,d0
swap d0
move.w d0,CopBplP2+2
swap d0
move.w d0,CopBplP2+6

move.l #bfr+120,d0
swap d0
move.w d0,CopBplP3+2
swap d0
move.w d0,CopBplP3+6

And in the copper list (notice that the bfr comes right after the end of the copper list...):

...
CopBplP0:
dc.w $e0,0 ;bitplane 1 pointer...
dc.w $e2,0
CopBplP1:
dc.w $e4,0 ;bitplane 2 pointer...
dc.w $e6,0
CopBplP2:
dc.w $e8,0 ;bitplane 3 pointer...
dc.w $ea,0
CopBplP3:
dc.w $ec,0 ;bitplane 4 pointer...
dc.w $ee,0

dc.w $100,$4200 ;BPLCON0

dc.w $ffff,$fffe ;END of copper list

EVEN
;aaa dc.b 0
bfr: INCBIN "images/background.320x256x4.raw"
bfrE:

Thanks to all of you for your help, you are great!

Regards.

[Mrs Beanbag]

Originally Posted by Toni Wilen

8-bit shift would be totally impossible result. DMA pointers are always word aligned (or longer in AGA), bit 0 does not exist. (as replied above too)

The hardware isn't shifting the data 8 bits. The data is pre-shifted 8 bits shifted in the memory by starting at an odd address, while the hardware accesses it from an even address. In above example the hardware pointers effectively point at "null" instead of "bfr".

[Toni Wilen]

Oops, of course it works that way, it was too simple. I always want to find most complex possible reason

(Having full executable, or at least copper list, would have narrowed possible other reasons greatly)

[nandius_c]

Originally Posted by Toni Wilen

Oops, of course it works that way, it was too simple. I always want to find most complex possible reason

(Having full executable, or at least copper list, would have narrowed possible other reasons greatly)

Hi Toni,

I'm sorry if my initial description of the problem was not detailed enough. I have posted today some more details and, if it's not enough, I'll post executable o more detailed code as soon as I have time.

Hope my last post can help find the answer.

Thanks and regards.