Hi. I think I might have some solutions, or at least hints, for these ARM
problems.
I don't have any ARM development hardware myself, but that might be
changing soon. The $99 TuxScreen phones are quite tempting :) Since it
looks like ARM platforms have been the most picky so far about alignment,
it should be useful to have a TuxScreen around here.
The only problems with ARM that I have heard about are with the theme
interpreter and linear8. Looking at the URL from Netwinder that John Laur
posted was very helpful though. I've tried to keep all the structures
32-bit aligned, but I might have missed some.
The theme interpreter needs to be able to load non-aligned 32-bit and
16-bit data- this is where the problem comes in. There are some macros that
are supposed to be able to simulate this, but I guess that isn't working
right.
Here's the (probably) offending code segment from theme/fillstyle.c:
------8<------
/* Macros to get the next short/long from the fillstyle buffer */
#ifdef UCLINUX /* needs word alignment, so we can't do it the simple way
*/
#define NEXTSHORT (unsigned short)( (unsigned short)(p[0])<<8 | (unsigned
short)(p[1]) )
#define NEXTLONG (unsigned long)( (unsigned long)(p[0])<<24 | (unsigned
long)(p[1])<<16 | (unsigned long)(p[2])<<8 | (unsigned short)(p[3]) )
#else
#define NEXTLONG ntohl(*((unsigned long*)p))
#define NEXTSHORT ntohs(*((unsigned short*)p))
#endif /* UCLINUX */
------>8------
This code is very bad. Yes, I wrote it ;)
Anyway, the #else section is assuming that the CPU knows how to deal with
non-aligned data. This is true for Intel, PowerPC, and MIPS. From the
results Eric has sent me, the ARM reads data at a memory location a byte
(in at least one case) less than where it should be reading. This mirrors
one of the examples in the Netwinder document. The "#ifdef UCLINUX" code is
a hack to make it work on the m68k. Assuming that code is correct, maybe it
would be best to do away with the ifdef and make it the default?
The linear8 VBL only needs to be able to push around bytes, but it has some
pseudo-functional code that tries to speed up the blits by moving most of
it around in 32 bits. Maybe there's a problem with this?
This code can be a little confusing, as it's the inner loop for linear8's
main blitter function. But, I think this is where the problem could be.
Note that drawing the cursor to the screen requires AND/OR masks which are
in a different blitter function, but managing the backbuffer is done with
this blitter. This would explain why the cursor itself looks fine but it
leaves trails.
------8<------
/* Normal blit loop */
#ifdef UCLINUX /* The 32-bit stuff isn't aligned, crashes uclinux */
#define BLITLOOP(op,xtra32,xtra8) \
for (;h;h--,src+=offset_src,dst+=offset_dst) { \
for (i=w;i;i--,src++,dst++) \
*dst op *src xtra8; \
}
#else
#define BLITLOOP(op,xtra32,xtra8) \
for (;h;h--,src+=offset_src,dst+=offset_dst) { \
for (i=w>>2;i;i--,src+=4,dst+=4) \
*((unsigned long *)dst) op *((unsigned long *)src) xtra32; \
for (i=w&3;i;i--,src++,dst++) \
*dst op *src xtra8; \
}
#endif
------>8------
This has a similar "#ifdef UCLINUX" kludge. In fact, looking at this code
again it doesn't do anything to try to word align things in the 32-bit
copy... So, the 32-bit code will fail on ARM, crash m68k, and probably run
slow on x86, PowerPC, and MIPS.
So, either the 32-bit blitter needs fixing or we just comment it out and
use the 8-bit version.
Hope this helps!
On Thu, 20 Sep 2001 09:55:53 Eric Christianson wrote:
> John Laur wrote:
> > Greetings everyone.
> >
> > I am currently working on getting PicoGUI to the TuxScreen phone
> > (www.tuxscreen.net) which is on the ARM platform. I have written an
> > input driver and have things mostly working (except for the keyboard
> > which is coming shortly.) I am having a problem with the blit and
> > tileblit functions in linear8.c - I have tracked it down to an
> alignment
> > problem and tried some preliminary attempts to fix it, but sadly, I
> know
> > very little about these issues especially on ARM.
> >
> > I was trying to go over some of the stuff covered in
> > http://www.netwinder.org/~brianbr/alignment.html but simply lack the
> > expertise to fix this properly. Micah told me that there were some
> other
> > developers out there using ARM and that Eric Christianson had dealt
> with
> > some alignment problems in the theme interpreter (maybe why I'm getting
> > yellow and not white in places in the aqua theme.) Can anyone offer
> > advice on this?
> >
>
> Hi John-
>
> I had been working on getting picogui to work on an ARM
> platform. I was able to get the base functionality working
> using the framebuffer mode. I did have to make some changes
> in the way color palettes were loaded, because the ARM
> platform I was working on had a fixed palette.
>
> I got to the point I noticed theme data was not packed properly
> as it was loaded. I found this by bytes in memory that were
> offset differently than read from the file. So you are correct
> that there are packing issues, but I never got them resolved.
>
> Unfortunately, I don't have the time at this moment to work
> on these issues. I had made some progress debugging it, and
> forwarded that info to Micah, but never was able to progress
> further. (I haven't had access to the board, or the time to
> do it.) :(
>
> If it would be helpful, I can try to get access to the hardware
> next weekend. (I am out of town this weekend) I think if I spent
> a solid two days, I could figure out most of the packing issues
> with some guidance from Micah- however, it's possible that the
> packing issues are prevelant throughout the code, in which case
> it will likely take longer. I know I was able to start loading
> some of the theme data correctly, before giving up.
>
> L8r,
> Eric
>
--
Only you can prevent creeping featurism!
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
