GP2X Ann: Libgp2x


andrew_j_w

Still Fresh
Joined
Sep 18, 2005
Messages
59
Hi all,

One of my two little projects for the GP2x has reached an almost usable stage, so I thought I'd post about it here so I can hopefully get some comments/feedback about it.

LibGP2x is a minimal library for getting low-level access to the GP2x's hardware, in the same vein as rlyeh's minimal library. Why didn't I just use rlyeh's library? Well partly because I think the code used is horrible, and with the little amount of documentation and examples it was very hard to get my head around it. The other reason is of course because I wanted to toy around with the bare metal.

LibGP2x provides access to the controls, screen and the second processor. There is no access to the sound hardware or the blitter, but those are both planned features.

One of the key features is the ease with which you can use the second processor, it's almost the same as programming for the main processor. Currently the number of functions that are implemented is limited, but that will improve. See this example for more.

The other key feature is that you can recompile the program and it will run on your PC - no changes to your code are needed. This won't work on Windows, as I don't have a Windows development machine, but it shouldn't be hard to get it to work. Everything that is supported on the GP2x is supported on the PC, including the second processor.

I haven't got around to creating a proper website yet, but documentation is availabe here whilst the code, and bug tracking facilities can be found at Google Code.

Finally, you can download an OpenGL rendered spinning cube - rewritten using libgp2x and GL2x - here.

I hope this will be useful to somebody, and I'd be delighted to hear any comments or suggestions that you might have, or about any bugs you might (will? :lol:) find.

Cheers,
Andrew
 
Blah posted on Aug 12 2006 at 09:35 PM said:
Isn't that calculator code a little wasteful?

The point is to show how you run code on the second processor and communicate between the two cores. It's not meant to be a real-world example :)

Andrew
 
Last edited by a moderator:
Hi there,

I've looked over your code. Its not bad, Ive been currently working on improving the minimal lib code, I also found the code a bit messy. My current plans are to intergrate compile options into the lib, (Such as -DBLIT -DSOUND etc) to give it a bit more flexability, and to just generally optimise the code.

With your code, I love the fact its a million times better layed out making it much more readable, but however I can't see any improvement over rlyeh's. I also love the way rlyeh's uses function "naming" for dualcore, and rlyeh's is in one file, which for such a small lib makes sense...

Check out... http://www.gp32x.de/board/index.php?s=&am...st&p=436103 for some ideas.. Or pm me if you want some of the latest stuff =)

Don't give up tho!

If its ok with you, Can I mix the two libs together?

Mike

Oh, Id also try and remove as many dependancies as possible.. So gettimeofday() and also have a -DDEBUG for the printf's

=)

Mike

Ah! And also, I was thinking of finishing the port of TinyGL =)

Mike
 
Last edited by a moderator:
cxzuk posted on Aug 12 2006 at 10:05 PM said:
I've looked over your code. Its not bad, Ive been currently working on improving the minimal lib code, I also found the code a bit messy. My current plans are to intergrate compile options into the lib, (Such as -DBLIT -DSOUND etc) to give it a bit more flexability, and to just generally optimise the code.

The build script builds a single static link library, libgp2x.a. You build it once then link it against all of your projects - and a statically linked libraries only include what you use in the final binary so I don't think having compile options like that will have any benefit.

With your code, I love the fact its a million times better layed out making it much more readable, but however I can't see any improvement over rlyeh's. I also love the way rlyeh's uses function "naming" for dualcore, and rlyeh's is in one file, which for such a small lib makes sense...

To be honest there probably isn't much improvement over rlyeh's, but that's not really the point. Having to include a single file in every project is not the right (IMHO) way to do things - what if you want to upgrade the library?

I assume by function naming you mean the ability to run a function on the second processor - the thing to remember is that function cannot call anyother functions, hardly a very scaleable way of doing things. I plan on letting you include the compiled code for the 940t into the main binary, but I don't see the point in the single function thing.

Check out... http://www.gp32x.de/board/index.php?s=&am...st&p=436103 for some ideas.. Or pm me if you want some of the latest stuff =)

I've been following that thread, some interesting stuff going on.

If its ok with you, Can I mix the two libs together?

My library is released under the GNU GPL so if you follow those restrictions then sure. The other thing that worried me about rlyeh's library was the lack of a specific license.

Oh, Id also try and remove as many dependancies as possible.. So gettimeofday() and also have a -DDEBUG for the printf's

The PC build depends on SDL, but other than that there are no dependencies. Why on Earth would I want to get rid of gettimeofday()? :unsure:

Andrew
 
Last edited by a moderator:
I think we see a gp2x library differently, altho you are correct.

I see it as more as an abstract layer, that intergrates into the program alot more than something u link to and call functions from.

with the gettimeofday() thing, r's minimal has a tick function which would be "better"?

Its not that i dont want to use the linux functions, I just feel that most can be replaced with something better.

Mike
 
Code:
#define SWAPm(a, b, c)  (((a) == (b)) || (((a) ^= (b)), ((b) ^= (a)), ((a) ^= (c))))
// DEBUG printf("x: %d, data[%d]: %d, data[%d]: %d\n", x, x - 1, snip[x - 1], wd - x, snip[wd - x]);

void gp2x_hflip15(gp2x_rect *r) {
  unsigned short *data=(unsigned short *)r->data, *snip = NULL;
  unsigned int x = 0, w = 0, y = 0;

  // work down the buffer...
  for(y = r->h; y >= 0; --y) { // or.. y + 1, while(--y); &data[y - 1 * wd];
	x = r->w;
	//take the row to flip...
	snip = &data[y * r->w];
	// SWAPm, Trying to save a bit of time, by replacing the last request in the swap with 
	// --x, instead of x-1 ready for next run..
	for(w = (r->w >> 1); w>=0; --w) SWAPm(snip[r->w - x], snip[x - 1], snip[--x]);
  }
}

void gp2x_hflip8(gp2x_rect *r) {
  unsigned char *data=(unsigned char *)r->data, *snip = NULL;
  unsigned int x = 0, w = 0, y = 0;

  for(y = r->h; y >= 0; --y) { // or.. y + 1, while(--y); &data[y - 1 * wd];
	x = r->w;
	snip = &data[y * r->w];
	for(w = (r->w >> 1); w>=0; --w) SWAPm(snip[r->w - x], snip[x - 1], snip[--x]);
  }
}

Use to you? - I can't wait to get my gp2x and accually test these things out. I know the gp2x has hardware gfx stuff too.. Can it do v/h flip ? If so, can someone tell me how you would go about doing it?

Mike
 
cxzuk posted on Aug 13 2006 at 12:36 AM said:
Use to you? - I can't wait to get my gp2x and accually test these things out. I know the gp2x has hardware gfx stuff too.. Can it do v/h flip ? If so, can someone tell me how you would go about doing it?

What is it supposed to do? Is it flipping the screen in the vertical axis? Why would you want to do that?

I'm all for adding useful functions, but there needs to be a good reason why it's there...

Andrew
 
Last edited by a moderator:
Its flips the Horizontal (i think?). It (should) flip any rectanglar area of the buffer.

e.g

{ 1,2,3
4,5,6
7,8,9 }

should become

{ 3,2,1
6,5,4
9,8,7 }

Mike

I think it needs an offset value for the X, so at the mo its only for the whole screen.
 
cxzuk posted on Aug 13 2006 at 12:58 AM said:
Its flips the Horizontal (i think?). It (should) flip any rectanglar area of the buffer.

Sounds useful for sprites, if its effecient, but in a minilib ...
 
Last edited by a moderator:
andrew_j_w posted on Aug 12 2006 at 02:29 PM said:
I hope this will be useful to somebody, and I'd be delighted to hear any comments or suggestions that you might have, or about any bugs you might (will? :lol:) find.

Cheers,
Andrew
This looks quite interesting; having more options for coding is always a good thing.

Related to the 940, there are a lot of things what would be amazingly useful; if you could add features like the following you would achieve godlike status:

1. 940-based malloc/free subsystem.
2. Ability to proxy at least some system calls across to the 920. That is, implement stubs for the 940 that communicate with a processing thread on the 920 which does the action and then communicates the result. Of particular interest would be file I/O (open, close, read, write, etc).
3. Build in something similar to squidge's MMU hack so that ideally you could choose the cached/uncached status of memory shared between the processors.
4. 940 versions of useful libraries such as mikmod, freetype, and so on. libjpeg and libpng would be nice.
5. Maybe dreaming here, but a version of the core parts of SDL that would allow surfaces to be accessed from either processor, with the same APIs.

More mundanely, nicely wrapped functions for more new simple things would be nice, such as:
* setting/getting cpu speed
* setting/getting gamma
* flushing cache and locking/unlocking cache lines
* highly efficient fixed-point math functions

The possibilities are endless!
 
Last edited by a moderator:
Dzz posted on Aug 13 2006 at 04:11 PM said:
1. 940-based malloc/free subsystem.

That is already there - call GP2x_upper_memory_malloc or GP2x_upper_memory_free on the 920t, or plain malloc/free on the 940t. When transferring pointers to memory between the two processors you have to use GP2x_convert_ptr_from/GP2x_convert_ptr_to so it gets mangled correctly. I need to write some documentation about this, although there is an example program called 'malloc' which shows how to use it.

The implementation is very simplistic, but I believe it works correctly. I intend to improve it so it doesn't use up so much memory in tracking what is/isn't used and to use buckets to speed things up.
2. Ability to proxy at least some system calls across to the 920. That is, implement stubs for the 940 that communicate with a processing thread on the 920 which does the action and then communicates the result. Of particular interest would be file I/O (open, close, read, write, etc).
I am working on this at the moment. I'm currently writing my own string manipulation functions, then I'll move on to printf, fprintf. Other file operations will be simple to add after that.
3. Build in something similar to squidge's MMU hack so that ideally you could choose the cached/uncached status of memory shared between the processors.
This is certainly something I would like to add. You might notice a striking similarity between the code from your demo tutorials and the code which runs on the 940t for setting up the memory - I, um, 'borrowed' it. Hope you don't mind :)
4. 940 versions of useful libraries such as mikmod, freetype, and so on. libjpeg and libpng would be nice.
This would definitely be a nice thing to have, and freetype was something I'd thought about. How easy it will be really depends on how many system calls they use.
5. Maybe dreaming here, but a version of the core parts of SDL that would allow surfaces to be accessed from either processor, with the same APIs.
As you can pass pointers to malloc'd memory on the 940t between the processors it is fairly easy to do this already, and the frame buffers are usable from both with the same API. Keeping the API consistant between the two processors is something at the forefront of my mind when designing this library - as is making everything work on both the GP2x and the PC.
More mundanely, nicely wrapped functions for more new simple things would be nice, such as:
* setting/getting cpu speed
* setting/getting gamma
* flushing cache and locking/unlocking cache lines
* highly efficient fixed-point math functions
All of those are things I want to work on, the fixed-point stuff is essentially required for my OpenGL implementation so that will definitely be getting done.

Andrew
 
Last edited by a moderator:
Sounds very cool!

I like to retain freedom regarding which parts of my code I publish and which I don't, so I don't use any GPL code... if you loosen your license a bit in the future I'll be sure to check back and have a look! Good luck, I think this will be helpful to many people developing open source stuff for the gp2x!
 
3. Build in something similar to squidge's MMU hack so that ideally you could choose the cached/uncached status of memory shared between the processors.

Look into the 940's MPU for some interesting stuff in this area. If I can ever get it working as I want I have things in mind for it.

Looking good BTW. More neatly wrapped up options then better :).
 
Back
Top