GP2X Gp2x Sdk?

[Squidge]

Only MPEG decoder is in the 940, 2D accelerator and the like is all in hardware, and so don't require 940.

My plans are to use Linux for playing videos and nothing else.

Yes, various people are already working on a pre-linux menu system (the kind you get on the gp32). This offers benefits such as the full 64MB of RAM in one contiguous chunk, interrupts, dma, and various other hardware features not possible under the Linux environment.

 

[MiniMoose]

Yes, various people are already working on a pre-linux menu system (the kind you get on the gp32). This offers benefits such as the full 64MB of RAM in one contiguous chunk, interrupts, dma, and various other hardware features not possible under the Linux environment.

​

So how do you take over the harware? I assume the Linux kernel is running the built-in menu on the GP2X. It seems like it would launch your game as a Linux process. I have very little embedded Linux experience. If it is anything like the uC-OSII embedded OS, then it would be easy to just write a loader that loads your actual game exe into the right spot in memory and jump to it, effectively taking over the hardware.

 

[theoddbot]

If you modify the bootloader you can take control before linux is even started. The gp2x uses uboot.

 

[Squidge]

yup, just write a launcher program (like you see on the gp32) that is launched from u-boot, and you can do anything you want.

once linux is booted however, your in user-space and immediately restricted.

 

[Oscaruzzo]

My plans are to use Linux for playing videos and nothing else.

Yes, various people are already working on a pre-linux menu system (the kind you get on the gp32). This offers benefits such as the full 64MB of RAM in one contiguous chunk, interrupts, dma, and various other hardware features not possible under the Linux environment.

​

But also that leaves you without device drivers and filesystem. If you do so, then how can you access the SD card, or the files stored into its filesystem? Are you going to reimplement FAT32? :blink:

 

[DJWillis]

But also that leaves you without device drivers and filesystem. If you do so, then how can you access the SD card, or the files stored into its filesystem? Are you going to reimplement FAT32? :blink:

​

What, just like the GP32 did. That's a yes by the way, no need to reimplement from scratch, there are loads of sources to work from .

 

[Squidge]

But also that leaves you without device drivers and filesystem. If you do so, then how can you access the SD card, or the files stored into its filesystem? Are you going to reimplement FAT32? :blink:

​

Yes, reimplement SD driver, FAT32, audio, etc... Exactly the same as we did on the GP32 when we didn't like the GPSDK

 

[MiniMoose]

But also that leaves you without device drivers and filesystem. If you do so, then how can you access the SD card, or the files stored into its filesystem? Are you going to reimplement FAT32? :blink:

​

I was actually going to crib from the Linux kernel source to create a stand-alone library that handles SD cards, FAT32, and USB. I was planning on writing libraries to handle the video device, inputs and sound chip myself.

If we concentrated on making simple libraries for each device, then we can write games directly on the metal much easier and get way more out of the device. Since you don't really need multi-threading in games, this is a workable solution.

 

[Oscaruzzo]

But also that leaves you without device drivers and filesystem. If you do so, then how can you access the SD card, or the files stored into its filesystem? Are you going to reimplement FAT32? :blink:

​

I was actually going to crib from the Linux kernel source to create a stand-alone library that handles SD cards, FAT32, and USB. I was planning on writing libraries to handle the video device, inputs and sound chip myself.

If we concentrated on making simple libraries for each device, then we can write games directly on the metal much easier and get way more out of the device. Since you don't really need multi-threading in games, this is a workable solution.

​

Actually an OS is much more than "multithreading". And even if it was, multithreading can be incredibly useful in games.

Anyway, I think I'd prefer to try to adapt the linux kernel to provide access to the needed resources. For example, a "flat" memory area, a decent interface for the second cpu, whatever. That's the reason for which I think gph MUST release the kernel source code. Just throwing everything out of the window would be a huge step back into the '70s (that would make your gp2x equivalent to an altair...)

 

[MiniMoose]

Just throwing everything out of the window would be a huge step back into the '70s (that would make your gp2x equivalent to an altair...)

​

Up until the XBox, the console manufacturers would just provide a set of libraries for interfacing with the different bits of hardware on a system. No OS at all. The OS that's on the XBox is extremely thin and allows you to use a flat memory space.

The only reason that console manufacturers are starting to give developers thing OS's is for 3D resource management.

Having no OS, or an extremely thin one, is the preferred situation for professional game developers. You want to be able to use the hardware to its maximum. Modifying the linux kernel to be thinner would be a lot of work. Writing libraries for the four or five bits of hardware would be much easier.

 

[grahf]

Forgive my dumb questions. The last time i did any programming was on an msdos 6 box. The extent of my programming knowledge consists of x86 assembly, no high level languages. I appologize in advance if any of these questions have been covered before.. i have been reading the forums like crazy, but im sure i may have missed it.

Q1] How thin is the gpx2 linux kernel? Is it mainly an issue of it using too many resources, or is it just too restrictive (as far as access to memory/video/io)?

Q2] How good of a chance that the kernel source will be released? Rather than thinning out the kernel, do you think it would be feasible to have the device reset upon launch of an application? Im envisioning a situation similar to the "Run in MSDOS mode" function of Win98/95.

Q3] Are you guys planning on making your new libraries availible to the rest of us amateur coders?


Feel free to ignore these questions, as im sure i'll answer them soon enough when i get my gp2x... I've wanted to get back into coding for a while, and this neat little device seems just what the doctor ordered. I just sorry i missed out on the original GP32 when it was first released..

 

[DJWillis]

Ok, these are some quick answers.

Q1] How thin is the gpx2 linux kernel? Is it mainly an issue of it using too many resources, or is it just too restrictive (as far as access to memory/video/io)?

It is a bit of both. The Linux kernel consumes resources and provides a veneer of ‘user-space’ between you and the hardware. On a device like the GP2X this is not always ideal.

Linux also maps out some memory for video decoding duties and other bits and bobs that could otherwise be used by applications (32MB to be exact) so by the time you have that mapped out and Linux loaded you only have somewhere in the region of 24MB available to play with (Well Malloc’able) without low level tinkering.

Using the second CPU core without Linux is also somewhat easier (however it is possible to use it under Linux but again it is not user friendly ).

Q2] How good of a chance that the kernel source will be released? Rather than thinning out the kernel, do you think it would be feasible to have the device reset upon launch of an application? Im envisioning a situation similar to the "Run in MSDOS mode" function of Win98/95.

The MagicEyes kernel on which the GP2X Linux is based is already available via the Open2x project. I am working to GPH to try and get a full release of there finished kernel source so that the project can host it (and use it as a basis for development).

As for restarting the device in RAW mode. There are several ideas in this area. Suffice to say, it should be fairly simple and painless.

Q3] Are you guys planning on making your new libraries available to the rest of us amateur coders?

What do you think . All the guys working on this strongly believe in open source. Everything will be available for anybody to do with as they wish once it is done I am sure .

 

[Oscaruzzo]

The MagicEyes kernel on which the GP2X Linux is based is already available via the Open2x project. I am working to GPH to try and get a full release of there finished kernel source so that the project can host it (and use it as a basis for development).

Uh? I can't see where it is. :blink:

In CVS you only have

(dir) libs-gp2x/ --> incomplete SDL source code (only the "src/video" dir contains some files...)
(dir) linux-mmsp2/ --> empty
(dir) linux-open2x/ --> empty
(dir) open2x/ --> some empty subdirectories
(dir) u-boot-mmsp2/ --> empty
(dir) u-boot-open2x/ --> empty

I think something didn't work when you uploaded the files...

I am working to GPH to try and get a full release of there finished kernel source so that the project can host it (and use it as a basis for development).

This is good news. I sure hope gph will "see the light" B)

 

[DJWillis]

I think something didn't work when you uploaded the files...

Yep, the time it takes SF.Net to mirror CVS from Developer to Public (and a balls up on my part).

 

[TheTurnipKing]

But also that leaves you without device drivers and filesystem. If you do so, then how can you access the SD card, or the files stored into its filesystem? Are you going to reimplement FAT32? :blink:

​

Yes, reimplement SD driver, FAT32, audio, etc... Exactly the same as we did on the GP32 when we didn't like the GPSDK

​

I agree you're almost certainly not going to see the best out of the GP2X if you go through Linux, but isn't that approach what led to problems with the GP32 BLU+, though? Maybe some kind of firmware loader program, that can kick you into Linux or into your "console mode"?

 

[MiniMoose]

I am working to GPH to try and get a full release of there finished kernel source so that the project can host it (and use it as a basis for development).

​

If you can get their kernel source release, including drivers for the GP2X hardware, that would make building a board support package (BSP) much easier. (For those of you unfamiliar with embedded development, a board support package is a set of libraries, usually C functions, that enables easy access to the various bits of hardware on a platform.)

It is my intention to put together a BSP with libraries for interfacing with the video display, 2D accelerator, SD cards, SDIO devices (e.g. 802.11b wifi cards, bluetooth cards, etc.), sound device, button I/O, the external UARTS, a port of the newlib C library, and a port of the Vincent OpenGL ES library. The completed set of libraries will allow anybody to write an app (in C/ASM) directly on the metal and avoid getting boxed-in by the Linux Kernel.

Don't get me wrong, quickly hashing out a game using SDL on the Linux Kernel is a great way to prototype gameplay and decide if a game will be fun. But when it comes time to build the final product, writing directly on the metal opens up more resources for you.

 

[xafier]

MiniMoose, if you really plan to do that I suggest coming into #gp2xdev on EFNET and talking to some of the guys, especially Squidge as I believe quite a few people plan to do similar and have already started

I dont think with the OpenGL thing, but obviously if people are already working on other parts you could concentrate on the Vincent OpenGL ES and combine with the rest, 2 heads are better and quicker than 1

 

[MiniMoose]

MiniMoose, if you really plan to do that I suggest coming into #gp2xdev on EFNET and talking to some of the guys, especially Squidge as I believe quite a few people plan to do similar and have already started

I dont think with the OpenGL thing, but obviously if people are already working on other parts you could concentrate on the Vincent OpenGL ES and combine with the rest, 2 heads are better and quicker than 1

​

Good suggestion. I start hanging out there. So far, this page on the wiki only includes ports of existing libraries. What I'd like to do is put together new libraries for each of the devices in the unit.

 

[grahf]

DJWillis, i appreciate your reply.

It is my intention to put together a BSP with libraries for interfacing with the video display, 2D accelerator, SD cards, SDIO devices (e.g. 802.11b wifi cards, bluetooth cards, etc.), sound device, button I/O, the external UARTS, a port of the newlib C library, and a port of the Vincent OpenGL ES library. The completed set of libraries will allow anybody to write an app (in C/ASM) directly on the metal and avoid getting boxed-in by the Linux Kernel.

Thats exactly what the community needs. Back when i was doing x86, i had a quite a nice procedure list compiled.. too bad its worthless now
I only wish i had the knowledge to help everyone out, but unfortunatly not yet..

 

[icurafu]

I am working to GPH to try and get a full release of there finished kernel source so that the project can host it (and use it as a basis for development).

​

Don't get me wrong, quickly hashing out a game using SDL on the Linux Kernel is a great way to prototype gameplay and decide if a game will be fun. But when it comes time to build the final product, writing directly on the metal opens up more resources for you.

​

OMG, so you're saying that SDL will just be good for prototyping gameplay?

Maybe your focus is on draining as much performance from the hardware, but in the real development world, time and quality of production also play into it. I think it is unfair to state that devs who choose SDL are just hashing something together.