#3137 - mantrid - Tue Feb 18, 2003 10:24 pm
Hello,
Mode 4, the pallete mode. It says in the documentation I have gbatek.txt that you have to wite to ram 16 bits at a time...fair enough. Now does that 16 bit also have to be 2 byte aligned also like memory acces?
I.e.
is static tUint8 * const ScreenRamPtr = (tUint8*)0x6000000;
*(u16*)ScreenRamPtr+1 = 0xff;
Ok?
#3140 - peebrain - Tue Feb 18, 2003 10:44 pm
It has to be aligned.
~Sean
_________________
http://www.pbwhere.com
#3143 - mantrid - Tue Feb 18, 2003 10:59 pm
Yes I would have thought so too, but the code below seems to work ok, but in theory each 32 bit access to the screen is on an odd address. I surpose that the least significant bit is just ignored then and the cpu doesn't generate any bus faults.
static tUint16 * ScreenRamPtr = (tUint16*)0x6000001;
tBool UB_SoftKeysPresent;
tBool UB_SoftKeysRightLeft;
unsigned UB_PanScreenDelta;
/* Exported Functions */
void TargetScreenUpdate(void)
{
register int i;
for (i = 0; i < (UB_PhysicalScreenWidth>>2) * UB_PhysicalScreenHeight ; ++i)
{
((tUint32*)ScreenRamPtr)[i] = ((tUint32*)UB_PhysicalScreenRamPtr)[i];
}
}
#3156 - DekuTree64 - Wed Feb 19, 2003 5:16 am
I think a 32-bit write to an address like 0x6000001 would be the same as one to 0x6000000, but a 32-bit write to 0x6000002 would write the first 2 bytes (halfword) to 0x6000002, and the second halfword to 0x6000000. I haven't tested writing to a 4-byte aligned +3 (like 0x6000003), but I'd guess it'd be the same as +2. Also, 16-bit writes to odd adresses swap the 2 bytes the same as misaligned 32-bit writes swap the 2 halfwords.
So the bottom line is you have to write at least 2 pixels at a time in mode 4.
#3169 - mantrid - Wed Feb 19, 2003 11:37 am
Thanks for the info. I also see that there is some stuff about this in the Cowbite docs.