system on the gp32 then the chances are very good of full-speed emulation.
If you are trying to emulate a 16 bit system then maybe or maybe
not. It depends on your coding skills and your ability to effectively
use ARM assembly language.

the input file contain a non-empty Read/Write (RW) section due to the
algorithm they use to convert to fxe format (and the emu probably
requires this as well). [i.e. DWORD at input file offset 0xc should
not equal DWORD at input file offset 0x14] B2fxe doesn't care if your
RW section is empty and creates an output file that works fine
in emulators and hardware.

.fxe - Scrambled (light encryption) binary file & graphic icon for
free games/apps from GP & third party developers. You have to use
Game Park's free launcher to run these on your gp32. When the launcher
unscrambles these files and removes the icon, the result is identical
to a .gxb file. They are usually found in the gp:\GPMM directory.

.gxe - Binary info file : title, company, icon, encrypted stuff,..
This file can also contain the first X number of encypted bytes
of the binary. The remainer of the binary is found in the
.gxc file with the same name.

.gxc - Encrypted binary file. After a header, every X interval number
of bytes in this type of file you will find Y number of bytes of information
that is encrypted. The rest of the file is unencrypted.

If you remove the 20 byte header and unencrypt the file (placing it
after any unencrypted code from the .gxe file), then the resulting
data is identical in all other respects with a .gxb file.

.gxb* - Non-encrypted binary file. This is placed in gp32 ram
starting at location 0xc000000. The entry point is the starting
location and the entry is performed in ARM (not thumb) mode. Here
is the header in ARM SDT format:

There basically are no separate chips for graphics or sound processing.

The gp32 CPU handles most of these operations. There is an external
Samsung LPC3600 LCD timing controller but this is only used for
generating correct signal timing for the LCD. There is also an external
Phillips UDA1330A stereo filter IIS-bus DAC but this is only used to
convert the final composite sound signal from digital to analog.

The gp32 graphics hardware has no layers, tile modes, sprites, or other
fancy hardware. It basically just has double-buffering of a bitmap-style
screen mode.

~22MHz up to ~133.5MHz. The slower the selected speed, the longer
the battery life that you will experience. However, just because
the CPU can be set for very high speeds does not mean that the
rest of the system (in particular the SDRAM) can handle this
speed as well. Bios v1.5.7 defaults the clock speed to 67.8MHz.
FireFly and others have managed to run their GP32 at up to 99MHz,
with instruction and data cache on, without noticeable problems.
Some people appear to experience problems at this speed.

tell the compiler what registers are being used by bios swi
code so that the compiler will know what registers will be
safe and what registers will be destroyed by the swi. YOU
MUST ALWAYS TELL THE COMPILER THAT THE LR REGISTER WILL BE
DESTROYED. Read that last sentence one more time to commit
it to memory. ;-) Here is the format for passing that info:swi 0x?, {input registers}, {output register}, {lr,destroyed registers}
If the swi call requires no input or output registers, then use the
following format as an example:swi 0x?, {}, {}, {lr,destroyed registers}

MS Visual C++ is supported by GamePark in the form of libraries
that allow you to develop and test a game on a PC. The resulting
compiled code will only run on a PC but this same source code can
be compiled on other C compilers to generate binaries that will
run on real GP32 hardware. The main drawback to VC++ is that you can
not develop optimized ARM assembly language with this setup. GP will
make the VC++ libraries available here when they are released:
http://www.gameparkdev.co.kr

ARM SDT is a very efficient compiler but it is ~$4000USD.

GCC is also a popular approach. There are several different
GCC compilers that have been targeted to the ARM platform as listed
below. For each of these packages you will need additional libraries
or files that can be found here: http://www.devrs.com/gp32/files/gcc/
1) Dev Kit Advance was originally intended for the GameBoy
Advance, but it is basically a generic ARM GCC 3.0.2 C/C++ compiler for
windows: http://www.io.com/~fenix/devkitadv Add this to your compile
options for smaller code that is tuned for
the ARM920T processor: -mtune=arm920
2) GCC 3.0.4 that is available from http://darkfader.net/gp32
is a slightly later version of GCC that is much smaller than
Dev Kit Advance

SMC card reader for windows should work fine for reading & writing
files on the SMC card. Note that file names can only be up to 8
characters in length, followed by a period, and 3 extension
characters. Directory names can only be up to 8 characters long.
The EMS 5in1 card reader from LikSang.com is known to work fine for gp32 SMC cards.

There is also other SMC info that is read by using SMC command 0x90:
The 1st ID byte identifies the manufacturer, being either Samsung (0xEC) or Toshiba (0x98).
The 2nd ID byte tells you the type/size of the SMC (0x73 = 3.3V NAND 16MB / Samsung SMC)
The 3rd ID byte, if it contains the value 0xA5, indicates that this
SMC card contains a unique 16-byte SMC ID. Due to security reasons,
Toshiba and others do not provide information for reading SMC IDs
without first requiring you to sign a Non-Disclosure Agreement.

The GP32 only supports 3.3 volt cards. When looking at the
metallic pins of the SMC card, hold the card such that the
pins are at the top of the card. If the notch on the end of
the card is on the right then it is a 3.3 volt card, otherwise
it is 5 volts.

If you ever want to experiment with SMC ID encryption
then the SMC card must contain a SMC ID. However, for
all other uses the presence of an SMC ID is not required.
(i.e. mp3 files, GP32 ID encryption, etc.)
Some or all Toshiba SMC cards are known to contain an SMC ID.
The SMC Option Code will be 0xA5 if it contains an SMC ID.
GP32 games that are all made in one batch will contain the
same 16 byte SMC ID code, otherwise they will be different.

Due to security reasons, Toshiba and others do not provide
information for reading SMC IDs without first requiring you
to sign a Non-Disclosure Agreement.

SMC ID Encryption - Games that are encrypted this way will only
work on one particular SMC card, but the game will work on any gp32
console. Some SMC cards have their own unique ID that
is built into the hardware of the card itself and it can not be
changed. The gp32 bios uses this unique ID as a key to unencrypt
.gxe files. Most, if not all, commercial games are encrypted this way.

GP32 ID Encryption - Each gp32 game console has it's own unique
product ID. (This ID can be viewed from the gp32 test screen. Accessing
the test screen is covered in another FAQ in this file.) Games which
have been encrypted using the GP32 ID will work on only one gp32 console, but
can be run from any SMC card.