PocketMatrix

ARM is the most forgiving of the 3 processors (as far as alignment, etc). If it will run on MIPS, it will most likely run on ARM right off (assuming you don't have any MIPS inline assembly).

On the older iPaqs GXEndDraw doesn't need to do anything, since GXBeginDraw returns a pointer to the real hardware screen buffer. Other devices (MIPS, etc) expose a back buffer, so you have to call GXEndDraw to force it to blit from the DRAM buffer to the hardware. Again, ARM is the most forgiving in this area as well.

Dan East

Trying to think back...but I seem to remember my E125 being RGB565, but in reverse order. like the blue and the green where flipped.

kzinti, I'm not being a smart ass here, but if you take a 24 bit rgb color DDFFEE and do a straight shift to make it 16 (565) 371F3B, then plug that into the GX screen buffer, you get a color match?

RICoder: that's right, it works with simple shifts. I dunno... Is is possible that different E-125 have different screens? (Unlikely imo)

hmm thats what that command was for. hell and all this time i was doing all this extra work.. well at least i have DB support in case i need it. anyway on the ipaq when does the screen actually update?

second.. if you use windows messages to catch key presses and not use gapi for input, would i still be affected by the one key press bug?