GP2X Gp2x Executable Format

[Robster]

OK, so now we have a bit of conflict! Excellent!

This is kinda important to me because, starting with the 17th of October, I'm going to be hacking GP2X full-time for a little while and I'd like to churn out a few development tools while I'm there.

So, more discussion please

Perhaps a little poll: with 1 for "strongly disagree" and 5 for "strongly agree", we can vote on:
1) We should have icon animations
2) Animations should have per-frame delay and transparency settings
3) There should be a "transparency colour" field in the header (as opposed to a fixed transparency value of 0xF81F)
4) We should support a range of icon sizes - 32x32, 48x48, 64x64, 80x80
5) We should two icon sizes, 32x32 and 64x64, both present in the header
6) We should expand the "Description" field in the header to a larger value (add a recommended size for the field)
7) We should allow optional compression (default: ZLib) for icon data
8) We should put the icon data at the end of the file

Since I'm asking the questions, I guess I should commit myself to an opinion:

1) 2
2) 1
3) 4
4) 1
5) 3
6) 4 (128 bytes?)
7) 4
8) 1

I'm being a bit negative, by the look of it! But what I mean is that my preference is for a single, static icon. I'm kinda keen on Inopia's idea of two icon sizes. The transparency colour should be selectable for flexibility. ZLib would be handy if there are 32x32 and 64x64 icons, because that would be 10kB of icon data. And I definitely think the metadata should be at the start of the file

 

[mr.spiv]

Next time someone wants to change the change the OXE format please use the following official form: http://www.3gpp.org/ftp/Information/CR-Form-v7.1.zip

Ok.. Here's my list h34r:

1) 1 (sorry for ever proposing this)
2) 1
3) 4 (I'll only cut my left little finger in case of fixed transparent color.. I'll survive)
4) 1 (only 32x32)
5) 1
6) 1 (current is enough.. no one will use it anyway)
7) 1 (with one 32x32 icon.. useless)
8) 1

:blink:

 

[woogal]

Well from my experiences with YAFL I can say that animated icons are usually a distracting mess. Aquafish created an animated fxe format and tried to get a few people to support it. I think it got added into slubmans launcher and rov's YANL and they had all the icons constantly animating at once. Nice for causing a headache, completely useless for trying to find the right app to launch. Added the animated fxe stuff into YAFL and the effect was horrible (which is why that version never got released). If animated fxe icons ever started to be used by people I was going to add animation on the detail screen where the icon was doubled in size, but no-one bothered to use them so I never finished the code.

As for multiple icon sizes, I think that 2 sizes could be nice (one for large 'normal' icons, and a smaller one for a list view), but it's far from essential.

Larger description field would be very nice, but as spiv says most people wouldn't use it.

 

[Squidge]

There's loads of things to put in the file header, but seriously, we just need to use the bits that will be useful, actually used, and easy to do. We really don't want to spend 6 months on writing the generator program for this file format, the parser, file launcher, etc.

So I'd say we use Inopia's menu code, and the following structure:

1) 1 - A single icon is enough in 99% of cases, and the menu system already supports this, so that work is already done.

2) 1 - See 1 - there should be no anims.

3) 3 - Although I'm not really bothered, but a non-fixed value would be nice - we can use a fixed value for now and just set this to that value (eg. 0xF81F) until we support it in the launcher. The current menu code has a fixed value - lets use that for now.

4) 1 - A single icon size should be enough. Icons of differing sizes would look a mess.

5) 1 - We only need a single icon.

6) 2 - People will normally only put the name of the whatever the program is called here anyway, or perhaps there nick, so 32 bytes is enough. Overflow from here can go into the programs readme file.

7) 1 - With only a single 32x32 icon, it doesn't make much sense.

8) 1 - There's no reason to put it at the end of the file - it just creates more work with no gain.

 

[rlyeh]

1) We should have icon animations

4, i find cute animations nice, but that's cos I know what kinda animations I have to do... i dont like messy animations like woogal said

2) Animations should have per-frame delay and transparency settings

3, the delay is good when you're an artist and want to do your work easily and with no problems. i can live with no transparency but the classic purple btw

3) There should be a "transparency colour" field in the header (as opposed to a fixed transparency value of 0xF81F)

2, not important really see 2)

4) We should support a range of icon sizes - 32x32, 48x48, 64x64, 80x80

2, not important really as long as you do 5)

5) We should two icon sizes, 32x32 and 64x64, both present in the header

4, yes please! i need to draw better icons for my apps! 32x32 is too small for me

gp32 icon:

zodiac icon:

(its bigger and more detailed and im not even using the whole 64x64 grid...)(see what i mean?)

6) We should expand the "Description" field in the header to a larger value (add a recommended size for the field)

2, useful? i agree with squidge about putting the extra bits on a readme as usual

7) We should allow optional compression (default: ZLib) for icon data

3, a 64x64 in hicolor + 32x32 in hicolor makes 10 kb yep... zlib is ok and portable isnt it? although 10kb wont hurt anyone im pretty sure... and by using uncompressed icons makes an easy job for some people when doing a custom loader...

8) We should put the icon data at the end of the file

2, i dont mind about this really... do what's better for you when coding the tools really... you choose...


btw, i *WANT* hicolor icons omfg, palettized icons sucked @gp32 big time... i know that option is not listed but i give my *5* there (jeez!)


ps: i've just read what i wrote and im sorry for my english... but its too late to fix the mistakes...

 

[Robster]

OK, the time for talk is over, and here is my executive decision. Thanks for all the feedback, good teamwork guys!

index:
0x00000000   4 bytes   Magic -- 0x3145584F i.e. "OXE1"
                        Digit '1' is also the header format version number
0x00000004   4 bytes   Address of start of code section (normally 0x00008000)
0x00000008   4 bytes   Size of code section (must be > 0)
0x0000000C   4 bytes   Address of start of data section as an offset from start of code section
0x00000010   4 bytes   Size of data section
                        if size == 0 then there is no data
0x00000014   4 bytes   Address of start of bss section as an offset from start of code section
0x00000018   4 bytes   Size of bss section
                        if size == 0 then there is no bss
0x0000001C   32 bytes  Application name
0x0000003C   32 bytes  Application author
0x0000005C   64 bytes  Application description
0x0000009C   4 bytes   Application version
                        bits 31-24 are major version
                        bits 23-16 are minor version
                        bits 15-0 are build number
                        So version is "1.2.3456" sort of thing
0x000000A0   2 bytes   Size of icon data
                        if bit 15 is set, there is a 64x64 icon (total icon data = 10240 bytes).
                        if bit 15 is not set, there is no 64x64 icon (total icon data = 2048 bytes)
                        if value is less than the expected uncompressed value, then the icon data is compressed
                        e.g. if value is 2048, then there is no 64x64 icon and the 32x32 icon is uncompressed
                             if value is 43008 then there are both 32x32 and 64x64 icons and the icons are uncompressed
                             if value is less than 2048 then there is no 64x64 icon and the 32x32 icon is zlib compressed
                             if value is between 32768 and 43008 then there are both 32x32 and 64x64 icons and the icons are zlib compressed.
0x000000A2   2 bytes   icon transparent color
0x000000A4             icon data, as many bytes as described above
0x????????             application code and data

This will enable talented artists to provide nice detailed icons, but if they aren't provided and the launcher wants to display 64x64, it can just blow up the 32x32 one.

I also can't see a reason not to have a bigger description field, it won't cost anything and it sounds like Inopia has a launcher concept in his head so we should support that.

Comment on it if you like (especially factual errors) but I think we can get on and implement some tools around it now

 

[rlyeh]

I also can't see a reason not to have a bigger description field, it won't cost anything and it sounds like Inopia has a launcher concept in his head so we should support that.

OK, the time for talk is over, and here is my executive decision. Thanks for all the feedback, good teamwork guys!

Ok, enlarge the description field, i think we can live with that ;-)

Hmm... do you think we need to LZip the icon data considering the fact the maximum icon size is 2 or 10 kb? I think it had sense when we had animations with an unlimited number of frames... 10 kb wont hurt anyone and would be harder to code for third party launchers... right?

BTW, put some reserved bytes somewhere! think about future

 

[mr.spiv]

Hmm, no extra bytes to header. There's a header version for
future enhancements. Also aiming for easier to parse header
here a slight mod to the header:

0x0000005C   1 bytes  Application description length in bytes * 4
0x0000005D   1 bytes  Flags 
                     7     6    5    4    3    2     1    0
                     +---+---+---+---+---+---+---+
                     |       reserverd   |64 | 32|
                     +---+---+---+---+---+---+---+

                     64 = 64x64 included (1 = included)
                     32 = 32x32 included (1 = included)
0x0000005E   2 bytes  Icon transparent color
0x00000060   4 bytes   Application version
                       bits 31-24 are major version
                       bits 23-16 are minor version
                       bits 15-0 are build number
                       So version is "1.2.3456" sort of thing
0x00000064    n bytes of Application description (0-1024)
                         the string is 0 padded if needed
0x????????     x bytes  of 32x32 icon data
0x????????     y bytes  of 64x64 icon data
0x????????      application code and data

 

[Squidge]

Perhaps the 32x32 icon should be mandatory - if none is provided to the oxe creator, it would use a default ?

Also, since we only have single icons now, I think we can leave zlib out of it now, as it only complicates things.

 

[EvilDragon]

Animated icons wouldn't cause a headache if only the SELECTED icon will be animated and the rest stands still.
Would be neat.

 

[skeezix]

Haven't had time to follow along of late..

In my experience, you don't _need_ animated icons at all; even current machines like PSP, Pocket PC, Palm OS, DS etc don't do such things, though things like OSX will animate the icon on its behalf (bouncing icons, without morphing or the like.) We could throb it etc without animation per se.

Only a few sizes woudl be needed, so could make them discrete; ie: 32x32, 48x48, 64x64 and thats that .. maybe 2 bits somewhere, or go the whole mile.

A "transparency colour" is pretty common; no need for PNG support in a exe header.. just a table of resources, or just one resource set. We don't need a family of icons (black/white, colour, etc) since specsd are static.. so probably best just to have one icon size and scale it as needed.. or pad extra icons onto the end of the file and have the launcher figure it out

Dunno if that helps, I'm just flying through with piles of work chasing after me

Hope to get an advance device soon; the existing tools (SDK with custom gcc etc) workable, or is it a big old mess till we make our own?

jeff

 

[Squidge]

It's still a big old mess, but at least DJWillis has ported GCC4 over.

 

[mr.spiv]

Perhaps the 32x32 icon should be mandatory - if none is provided to the oxe creator, it would use a default ?

Also, since we only have single icons now, I think we can leave zlib out of it now, as it only complicates things.

​

If OXE creator wants to add a default icon, it sets flag for 1 icon and includes it. Still having a possibiliy of not having icons at all, which IMHO is ok. And the above does not include compressed icons anymore.

Below is the current proposal as a whole.. (trying to be faster than Rob):

index:
0x00000000   4 bytes   Magic -- 0x3145584F i.e. "OXE1"
                       Digit '1' is also the header format version number
0x00000004   4 bytes   Address of start of code section (normally 0x00008000)
0x00000008   4 bytes   Size of code section (must be > 0)
0x0000000C   4 bytes   Address of start of data section as an offset from start of code section
0x00000010   4 bytes   Size of data section
                       if size == 0 then there is no data
0x00000014   4 bytes   Address of start of bss section as an offset from start of code section
0x00000018   4 bytes   Size of bss section
                       if size == 0 then there is no bss
0x0000001C   32 bytes  Application name
0x0000003C   32 bytes  Application author

0x0000005C   1 bytes   Application description length in bytes * 4
0x0000005D   1 bytes   Flags
                       7   6   5   4   3   2   1   0
                       +---+---+---+---+---+---+---+
                       |  reserverd    |64 |48 |32 |
                       +---+---+---+---+---+---+---+

                       Reserver set 0s
                       64 = 64x64 included (1 = included)
                       48 = 48x48 included (1 = included)
                       32 = 32x32 included (1 = included)
0x0000005E   2 bytes   Icon transparent color
0x00000060   4 bytes   Application version
                         bits 31-24 are major version
                         bits 23-16 are minor version
                         bits 15-0 are build number
                         So version is "1.2.3456" sort of thing
0x00000064   n bytes   of Application description (0-1024)
                       the string is 0 padded if needed
0x????????   x bytes   of 32x32 icon data (if icon exists)
0x????????   y bytes   of 48x48 icon data (if icon exists)
0x????????   z bytes   of 64x64 icon data (if icon exists)
0x????????             Application code and data

So.. how's this? :blink:

 

[Squidge]

Hmmm, should certain stuff be kept together - eg. like author, name, description, version? Maybe I'm being picky here, but we have author and name, and then description and then version and description come after the transparent icon color?

0x00000000   4 bytes   Magic -- 0x3145584F i.e. "OXE1"
                      Digit '1' is also the header format version number
0x00000004   4 bytes   Address of start of code section (normally 0x00008000)
0x00000008   4 bytes   Size of code section (must be > 0)
0x0000000C   4 bytes   Address of start of data section as an offset from start of code section
0x000000xx   4 bytes   Size of data section
                      if size == 0 then there is no data
0x000000xx   4 bytes   Address of start of bss section as an offset from start of code section
0x000000xx   4 bytes   Size of bss section
                      if size == 0 then there is no bss
0x000000xx   1 bytes   Application description length in bytes * 4
0x000000xx   32 bytes  Application name
0x000000xx   32 bytes  Application author
0x000000xx   4 bytes   Application version
                        bits 31-24 are major version
                        bits 23-16 are minor version
                        bits 15-0 are build number
                        So version is "1.2.3456" sort of thing
0x000000xx   n bytes   of Application description (0-1024)
                      the string is 0 padded if needed

0x000000xx   1 bytes   Flags
                      7   6   5   4   3   2   1   0
                      +---+---+---+---+---+---+---+
                      |  reserverd    |64 |48 |32 |
                      +---+---+---+---+---+---+---+

                      Reserver set 0s
                      64 = 64x64 included (1 = included)
                      48 = 48x48 included (1 = included)
                      32 = 32x32 included (1 = included)
0x000000xx   2 bytes   Icon transparent color
0x????????   x bytes   of 32x32 icon data (if icon exists)
0x????????   y bytes   of 48x48 icon data (if icon exists)
0x????????   z bytes   of 64x64 icon data (if icon exists)
0x????????             Application code and data

(Can't be bothered to adjust all the offsets, as this is just a general suggestion)

 

[Robster]

Fine, all of those changes are fine. I will add a flag tho, for "icon information is zipped" - I don't like the idea of adding up to 14.5k to each and every application just for icons. When the "icon information zipped" flag is set, the first two bytes of the icon information block will be the length of the zipped data block. All icons as specified by the flags will be included in the one data block, which has the advantage that it may improve compression by being a larger block, but the disadvantage that a launcher has to unzip the whole block to get an any of the icons.

Also, we need to be a bit clearer about the meanings of the addresses of the data and bss areas. I'm assuming that if these blocks are not contiguous, then there will be a gap when the image is assembled in memory, but the blocks will be stored contiguously in the .gx2 file.

For example:

Executable code starts at 0x8000, length 0x1000 bytes
data section    starts at 0x9234, length 0x0100 bytes
bss section     starts at 0x9400, length 0x0200 bytes

In the .gx2 file, there will be 0x1000 bytes of code followed immediately by 0x100 bytes of data (total 0x1100 bytes). The header will contain:

Address of code section       0x00008000
Size of code section          0x00001000
Address of data section       0x00001234
Size of data section          0x00000100
Address of bss section        0x00001400
Size of bss section           0x00000200

The loader will take 0x1000 bytes from file location X to X+0x0FFF and put them at memory location 0x8000. It will then take 0x100 bytes from file location X+0x1000 to X+0x10FF and put them at memory location 0x9234. It will then clear 0x9400 to 0x95FF, and finally start execution at 0x8000.

mr_spiv: sound like what you were after?

 

[mr.spiv]

Hmmm, should certain stuff be kept together - eg. like author, name, description, version? Maybe I'm being picky here, but we have author and name, and then description and then version and description come after the transparent icon color?

(Can't be bothered to adjust all the offsets, as this is just a general suggestion)

​

Few things.. Firstly keep the header word aligned. Secondly the stuff is bundled now in a way that all fixed length fields are together (so that you can read then always without further parsing) and those followed by variable length fields.

So just adjusting the order i.e. moving app name & author name after the app version would put all those app name & author name & app descriptin together. Wouild this be ok?

 

[mr.spiv]

Fine, all of those changes are fine. I will add a flag tho, for "icon information is zipped" - I don't like the idea of adding up to 14.5k to each and every application just for icons. When the "icon information zipped" flag is set, the first two bytes of

Ok.

Address of code section       0x00008000
Size of code section          0x00001000
Address of data section       0x00001234
Size of data section          0x00000100
Address of bss section        0x00001400
Size of bss section           0x00000200

The loader will take 0x1000 bytes from file location X to X+0x0FFF and put them at memory location 0x8000. It will then take 0x100 bytes from file location X+0x1000 to X+0x10FF and put them at memory location 0x9234. It will then clear 0x9400 to 0x95FF, and finally start execution at 0x8000.

mr_spiv: sound like what you were after?

​

Yep..

 

[Squidge]

Agree

 

[Inopia]

I'm fine with it

 

[DJWillis]

Works well for me