02 December 2013, 09:24 | #1 |
Fernando Cabrera
Join Date: Oct 2013
Location: Spain
Posts: 106
|
Word vs not word aligned playfield question
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. |
02 December 2013, 13:34 | #2 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,545
|
Quote:
This would result in an uninitialized byte in the upper-left edge, but it cannot explain the shift of the full display window. Quote:
|
||
02 December 2013, 14:25 | #3 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
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. |
02 December 2013, 16:13 | #4 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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.
|
02 December 2013, 16:22 | #5 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
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)
|
03 December 2013, 10:02 | #6 |
Fernando Cabrera
Join Date: Oct 2013
Location: Spain
Posts: 106
|
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. Last edited by nandius_c; 03 December 2013 at 10:08. |
03 December 2013, 11:42 | #7 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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".
|
03 December 2013, 11:52 | #8 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
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) |
03 December 2013, 12:03 | #9 | |
Fernando Cabrera
Join Date: Oct 2013
Location: Spain
Posts: 106
|
Quote:
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. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
vasm and word alignment | Den | Coders. Asm / Hardware | 9 | 07 February 2014 11:25 |
Italian word? | mai | support.Other | 7 | 17 December 2008 05:35 |
X-Word 2 | BippyM | EAB's competition | 15 | 26 October 2008 16:49 |
Textcraft word processor | davidpc | request.Apps | 5 | 21 February 2007 14:32 |
X-Word | BippyM | EAB's competition | 11 | 14 July 2004 20:26 |
|
|