G3A File Format

From WikiPrizm
Revision as of 05:09, 12 January 2013 by JosJuice (talk | contribs)
Jump to navigationJump to search

This page was 'borrowed' from PrizmWiki.

.g3a files contain add-ins for the Casio Prizm. Files of this format contain a 0x7000-byte header (28 KB),<ref>http://www.omnimaga.org/index.php?topic=5804.msg103313#msg103313</ref> and a data/code section that can be up to 1 MB large in OS 1.01 and 1.02.<ref>http://www.omnimaga.org/index.php?topic=5610.msg163588#msg163588</ref> The maximum size of the code/data section in newer OSes is unknown, but it seems to be larger. Add-ins (excluding the header) are loaded into virtual memory at 0x00300000 when executed.<ref name="miniSDK">Mini-SDK v1.06 by Simon Lothar</ref> Checksums are used to check if the add-in is valid or not. Running an add-in is the only method of running machine code on the Prizm right now. If a memory location of the header isn't documented here, it's probably supposed to be filled with 00.

File format

Identification/security bytes, checksums, name

0x0000

AA AC BD AF 90 88 9A 8D D3 FF FE FF FE FF. These bytes are found in almost every Prizm file, with the exception of the ninth byte (D3), which is the file type byte.<ref name="miniSDK"/><ref>http://www.omnimaga.org/index.php?topic=5610.msg104330#msg104330</ref> If the header is inverted (xor with FF), the first eight bytes read "USBPower".

0x000E

The low byte of the inverse file size (at memory location 0x0013) minus 0x41.<ref name="miniSDK"/><ref name="fxsdk g1awrapper">http://fxsdk.svn.sourceforge.net/viewvc/fxsdk/g1awrapper/trunk/g1awrapper.cpp?revision=24&view=markup</ref> The actual Prizm OS doesn't care about this byte, but other programs (for example the Manager PLUS) and possibly future versions of the OS do care, so it's important to set this byte correctly even though the add-in can be run if it's incorrect.

0x000F

This byte is always 0xFE.<ref name="miniSDK"/><ref name="fxsdk g1awrapper"/>

0x0010

Inverse filesize (four bytes). For example, if a file size is 00 0B 8A A8 you would xor it with FF FF FF FF, thus setting all 1's to 0's and 0's to 1's, and get FF F4 75 57.<ref name="miniSDK"/><ref name="fxsdk g1awrapper"/><ref>http://www.omnimaga.org/index.php?topic=5610.msg104684#msg104684</ref><ref>http://www.omnimaga.org/index.php?topic=5610.msg104695#msg104695</ref>

0x0014

The low byte of the inverse file size (at memory location 0x0013) minus 0xB8.<ref name="miniSDK"/><ref name="fxsdk g1awrapper"/> The actual Prizm OS doesn't care about this byte, but other programs (for example the Manager PLUS) and possibly future versions of the OS do care, so it's important to set this byte correctly even though the add-in can be run if it's incorrect.

0x0016

It's not completely clear what this is, but it might be a 16-bit CRC checksum calculated based on only the 0x0020 checksum. The polynomial is unknown. It appears that replacing the CRC checksum with null bytes causes it to be ignored by the OS during file verification.<ref>http://www.omnimaga.org/index.php?topic=5610.msg121712#msg121712</ref><ref name="Prizm add in header format edit.txt">Prizm add in header format edit.txt by z80man</ref>

0x0020

A checksum (32-bit) appears to be stored here. The checksum is calculated based on the entire file, except for this checksum and the copy of this checksum at the end of the file.<ref name="miniSDK"/><ref name="Prizm add in header format edit.txt"/>

0x0024

These two bytes are always 01 01.<ref name="miniSDK"/>

0x002E

Location of copy of the 0x0020 checksum (32-bit), minus the header size. This means that if this is equal to 000001F8, the copy of the 0x0020 checksum is at 0x000071F8.<ref name="miniSDK"/><ref name="Prizm add in header format edit.txt"/>

0x0040

Name of add-in. This is in English, but it's not always the same as the name at 0x006B (Picture Plot is named PictPlot at 0x0040). Probably a shorter version of the name.

0x005C

Size of entire file (32-bit).<ref name="miniSDK"/><ref name="Prizm add in header format edit.txt"/>

0x0060

Internal name. Only the uppercase letters A-Z and the @ character seem to be used. @ is always written before the name. There's probably a character limit of eight characters (including the @). Examples: @CONV (Conversion), @GEOM (Geometry), @PICTPLT (Picture Plot)

Localized names, version information

0x006B

Name of add-in (English)

0x0083

Name of add-in (Spanish)

0x009B

Name of add-in (German)

0x00B3

Name of add-in (French)

0x00CB

Name of add-in (Portuguese)

0x00E3

Name of add-in (Chinese)

The font used for Chinese displays Latin letters differently than the other languages. When making an add-in, it's a good idea to check that the name shows up correctly when using Chinese. Long names may take up more space than the icon does, creating overlap.

0x00FB

Name of add-in (English - probably reserved)

0x0113

Name of add-in (English - probably reserved)

0x0130

Version number string. Format: XX.XX.XXXX

0x013C

Date/time created string. Format: YYYY.MMDD.HHMM

eActivity

This area of the add-in header describes what the add-in will look like when viewed from an eActivity. If the add-in doesn't support eActivites, these memory locations should all be set to 00.<ref name=omni152915>http://www.omnimaga.org/index.php?topic=5610.msg152915#msg152915</ref>

0x0170

eActivity name of add-in (English)

0x0194

eActivity name of add-in (Spanish)

0x01B8

eActivity name of add-in (German)

0x01DC

eActivity name of add-in (French)

0x0200

eActivity name of add-in (Portuguese)

0x0224

eActivity name of add-in (Chinese)

0x0248

eActivity name of add-in (English - probably reserved)

0x026C

eActivity name of add-in (English - probably reserved)

0x0290

eActivity strip icon. The icon is 64x24 pixels large, and one nibble is one pixel. 8 different colors can be used. Every color has a value from 0 to 7. If a value between 8 and F is used, the pixel becomes black. (0 should be used if black is desired, though.) Ends at 0x058F.<ref name=omni152915/><ref>http://www.omnimaga.org/index.php?topic=5610.msg121812#msg121812</ref><ref>http://www.omnimaga.org/index.php?topic=5610.msg121829#msg121829</ref>

Colors
Value Color
0 Black
1 Blue
2 Green
3 Cyan
4 Red
5 Magenta
6 Yellow
7 White

File name, icons, executable code, checksum

0x0EBC

File name (including the .g3a extension).

0x1000

Icon that is displayed when the add-in is unselected.<ref name="miniSDK"/> The icon is 92x64 pixels large, and each pixel has 16 bits of color information (5 red bits, 6 green bits, and 5 blue bits). This means that the icon is 0x2E00 bytes long (ends at 0x3DFF).

0x4000

Icon that is displayed when the add-in is selected.<ref name="miniSDK"/> The icon is 92x64 pixels large, and each pixel has 16 bits of color information (5 red bits, 6 green bits, and 5 blue bits). This means that the icon is 0x2E00 bytes long (ends at 0x6DFF).

0x7000

Executable code starts.

0x????

Copy of the 0x0020 checksum. These are the last four bytes of the file. The location of these four bytes can be read at 0x002E.<ref name="Prizm add in header format edit.txt"/>

References

<references/>

Retrieved from "http://prizm.cemetech.net/index.php?title=G3A_File_Format&oldid=962"