GP32 Uclibc

[pea]

Does anyone know where I can get a precompiled uclibc toolchain for windows (win XP)?

 

[Robster]

Hmmm, not sure what you're asking here... you want to build uclibc to run on what target?

Compiling applications for Win32 with uclibc doesn't make any sense, so I presume you're talking about an embedded platform.

In case you're interested, there's a guy at Samsung who found that ARM CPUs run really well on ucLinux, even when they have a MMU. The link is here.

 

[pea]

Well, I wanted a cross-compiler toolchain (or whatever its called) running on winXP compiling for GP32 ARM.

The reason being that uclibc would create tiny apps compared to glibc (or lic, or whatever is being used) - and need an updated version of glibc/uclibc anyway that fixes a problem with setjmp/longjmp on devices with software floats (uclibc has this fix).

I don't have linux, so I can't compile/mount/whatever the toolchain myself, so need a precompiled toolchain

EDIT: That uCLinux running on ARM is cool. However, I don't know much about linux in general, or uCLinux for that matter, so it doesn't mean much to me, sorry

 

[Robster]

Aha! Well, uclibc has the fix, but it was only uclibc that had the problem in the first place

I, and everyone else that I know, use newlib. I'm not sure what using uclibc over newlib will buy you, and I don't know how to hook uclibc up to gcc.

So really, I'm bugger all use to you

Newlib does have setjmp/longjmp as far as I know. I've done a few instructions on setting up your own gcc toolchain on my site, although it's for Linux. DJWillis improved on it and gave instructions on doing it with Cygwin on Win32, but I'm not sure where it is. DJWillis? Are you there?

 

[pea]

Thanks Robster

I use a toolchain by bobintrees that was on Mr.Mirkos site about 6 months back or so, even before I got my GP. The version I have must use newlib then? It definately has setjmp and longjmp.

I compiled pnglib, which uses setjmp and longjmp to as a 'goto' to jump back to a specific part of code when an error occurs (goto: naughty naughty). All was fine and dandy until this happened (longjmp was called). After it happened once, the code would not continue to run. It didn't crash, but sort of froze or something. Perhaps infinately looping the longjmp?

I have since gone through the whole source for pnglib and replaced all functions that called png_error with custom code to set and pass back abn error variable - which was a LOT of work, and it seems to have fixed the problem. However, I may have introduced memory leaks by doing this, by jumping out of a function before freeing a struct or something. It is unlikely though, because in most instances I simply replaced 'png_error' calls with my own exit code, so the original would have had the leak too

However, the long and short of it is, that if I could get it to work with the original setJmp and longJmp, it would be better because I would feel better about using orginal code

Maybe it is something else (not an error, but an ARM oddity) that makes setjmp work funny? It screws up the LCD sometimes too

 

[Blah]

I dunno, but I had a thought. The gp32 game Vorton uses pngs through Chui's port of SDL. It might help to consult Chui or his SDL code.

Also, since you said you'd release it, I was wondering...Will it be able to read the gamma and transparency information?

 

[pea]

Hey Blah,

Yes, it reads gamma and transparency info - this is the exact reason I am working on it. I currently use GIFs, but would like PNGs for the following reasons:

1) Full transparency
2) Non-paletted images (more than 256 colours)
3) About same file size as GIF

At the moment I am trying to work out how to get the damn pixel info out of the png struct once it is loaded! It is loading a PNG at the moment, but then I can't get the colour and transparency info out! haha.

 

[pea]

ooh yeah! PNG is working. Haven't tried alpha yet, but basic 24bit images are working!

EDIT: Full alpha-channel seems to be working too... I'll post a preview.

The dancing girl in bikini has a transparency fade from left to right (not a uniform one) and is pasted over the top of the closeup girl.

 

[pea]

It also loads/decompresses images very quickly. My test app that loads and displays 2 320x240 PNG images at full transparency does so in probably around one second at 66 MHz.

Will be releasing the source soon.

 

[Blah]

Glad to hear! My favorite thing about PNG is the lossless compression...

 

[pea]

Hey blah - how adept are you at coding?
If I send you the code, are you able to alter it to work with whatever code structure you use (e.g. Mirko sprites)?

I use a canvas structure that I use for all my graphics routines that looks something like this:

typedef struct tGP_canvas{
	unsigned short width;
	unsigned short height;
	unsigned short *data;
	unsigned char *mask;
	unsigned char frames;
}tGP_canvas;

canvas->data is the unsigned short colour values (16bpp)
canvas->mask is the unsigned char transparency data (5bpp, so 0-31)

Since I don't know what sort of structure you are going to use to store this data, its best to send you the source, and you can alter it...

 

[Blah]

Looks doable...

 

[cyberic]

To dsiplay JPGs very quickly, there is rasterman's epeg:
http://www.t2-project.org/packages/epeg.html

I had tried it on gp32linux, and it was REALLY fast!

 

[pea]

Couple of things about epeg -
1) You still need libjpeg
2) It is great for displaying smaller images than the source (i.e. looking at pr0n on gp32) but loading normal images is same speed (I believe)

 

[synkro]

@pea: are you goint to post all your stuff as a complete package or in the code snippets section of your site?!

 

[pea]

I have talked to Mr.Mirko, and I am going to release peaSDK soon. It has lots of extra functionality, but is 16bpp only (for now). Won't be for at least a month though.

 

[cyberic]

Couple of things about epeg -
1) You still need libjpeg
2) It is great for displaying smaller images than the source (i.e. looking at pr0n on gp32) but loading normal images is same speed (I believe)

​

Yes, but it would allow for instance to have a fast image viewer on the GP32

 

[pea]

Yep, I'm not contending that. Go nuts.