GP2X Gp2x General Info


Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,493
Location
UK
Website
Visit site
To make executable gp2x programs, compile them as standard Linux ELF files, call them "filename.gpe" and place them in the root of the sd card. User programs have access to at most 23MB of RAM whilst running. When your program exits, the GP2X will drop to a shell, so you have to load /usr/gp2x/gp2xmenu yourself if you want the user to be able to do something else with the device.

To make a GP2X utility (I've no idea what these are supposed to be yet, but they are run exactly the same as above), call them "filename.gpu" and place them in the root of the sd card.

The device takes a while to bootup, and most of this time is spent uncompressing the linux kernel and mounting the root file system. Not a lot can be done about how fast the root file system is mounted, but the uncompressed size of the linux kernel seems to be smaller than the compressed size :blink: (it reads 1048576 bytes from nand, and the uncompressed size is 1027686 bytes).

The menu system, and all applications, are run from bash. Whilst this seems strange (additional bootup time and memory usage), at least it means us developers can drop to a shell to launch our stuff instead of messing around with the interface. Makes testing stuff much easier and faster.

People wanting to use SDL to parse the joystick with the latest kernel on dev boards should try and type the following once per reboot:

mknod /dev/GPIO c 253 0

It just may give you SDL joystick support :) (with the latest file system image, it's done automatically on startup)

All buttons are now reported via SDL, you can even press the joystick (VK_TAT), use the volume buttons (VK_VOL_DOWN, VK_VOL_UP) etc. The joystick is 8-way.

SD card is auto-mounted using file system type 'vfat', so this means long filename support as standard.

SD is mounted at location "/mnt/sd" whilst nand is at "/mnt/nand" should you wish to access datafiles from your apps.

SD access now seems to be much faster:

Reading:

[root@Linux /]$umount /mnt/sd
[root@Linux /]$mount /dev/discs/disc0/part1 /mnt/sd -t vfat
[root@Linux /]$ls -l /mnt/sd/squidge
-rwxr-xr-x 1 root root 1608260 Oct 13 2005 /mnt/sd/squidge
[root@Linux /]$time cat /mnt/sd/squidge >/dev/null

real 0m2.082s
user 0m0.000s
sys 0m0.300s
[root@Linux /]$

754KB/sec

Writing:

[root@Linux gp2x]$ls -l MusicPlayer
-rwxr--r-- 1 root root 1179668 Jan 1 00:00 MusicPlayer
[root@Linux gp2x]$umount /mnt/sd
[root@Linux gp2x]$mount /dev/discs/disc0/part1 /mnt/sd -t vfat
[root@Linux gp2x]$time cp MusicPlayer /mnt/sd; time umount /mnt/sd

real 0m1.006s
user 0m0.030s
sys 0m0.970s

real 0m3.497s
user 0m0.020s
sys 0m0.300s

255KB/sec

USB

Device uses the NetChip 2272 IC for USB support. The NET2272 is a USB-function device, and as a result is a slave to the USB host.

Anything I've missed?
 
Just upgraded to kernel4.

Creating /dev/gpio works, but something strange is happening in duke. Can't move, and up=fire, right=look up, down=look down, and some of the diagonals seem to do look left and look right. Can't get any buttons to do anything. Going to try a basic sdl joytest app to see if it's sdl/hardware or duke thats at fault.

The sd speed is also fixed in kernel4 on the dev boards! :) Duke used to take almost 2 minutes to boot to the first screen, and then the loading was so slow that it couldn't load the images quick enough to animate the intro screen. Loading a level took around 20 seconds without caching, 6 minutes with!. With kernel4 it boots in ~11 seconds and takes less than 2 seconds to load a level, 12 seconds with caching. Me happy now :).
 
GPH's version of SDL is a mess :(. Instead of creating a true joystick device with axis that most (all?) existing sdl games will expect to find, they've mapped all stick controls to buttons so SDL thinks we have a 19 button device with no stick. And as the stick is 8 positions instead of 4, you can't just map the buttons to existing movement code as the diagonals won't work (up-left is a seperate joystick button in SDL, not a combination of up and left). Yes, thats right, once again we have a device with knackered diagonals.
 
I kinda expected that from gph to be honest - even on direct hardware you have 8 bits denoting the status of the joystick, and two bits never seem to get set at the same time. So your code has to take a diaganal and translate it into up+left, etc. Not fun. It must be even worse for SDL - and I thought the entire purpose of SDL on the GP2X was to make porting easier, not harder, like they seemed to have done.

Ah well, at least there's not many changes to SDL, and since we know exactly how the hardware works in regards to joystick, buttons, and LCD, we should be able to port a better version of the library with proper joystick. I really need to look at the AC97 audio (or perhaps just use /dev/dsp ?)
 
They're very creative in the way they bugger things up; do you think they sit around trying to come up with this stuff? :)

jeff

Can we get 8bit displsy surface?
 
SDL has an abstraction layer; if your h/w can't do 8bp, then modern SDLs will translate for you (very slow :)

I generally do all my stuff in 16bpp and not sweat it, but Iv'e got a few things which depend on 8bpp for palette tricks, and simulating it in 16bpp is really slow (each palette cxhange required re-colouring the backbuffer.. ugh :/)

jeff
 
The hardware supports 8 bpp, but whether GPH actually implemented it as such is another question - from the looks of things, they've only read the hardware manual to find out how to change the screen resolution from 640x480 to 320x240 and nothing more. (The ME display driver is a real hack job too - it doesn't even support changing resolutions without recompiling the kernel).
 
ehm, according to the manual the chip supports 24bpp true color. Does gph's SDL implementation support it? Or have they fixed it to 16bpp ?
 
It's probably hardcoded, as the MagicEye's graphics driver, which GPH have no doubt just butchered up to run on a 320x240 display, hardcodes everything like the pixel clocks, resolution, bit depth, etc, and doesn't support changing them without recompiling the kernel.

You can probably hack the hardware and turn it into 24bpp, but does the LCD itself support 24bpp? Most portable LCD's I've seen support 24bpp, but can only display 16bpp, so it would be quite useless if that is the case.
 
Back
Top