GP32 Executing Fxe Files From Program


FabreNZ

Member
Joined
Dec 21, 2004
Messages
132
Hi, would anyone be willing to let me see their code that allows FXE files to be booted from within their program? I am working on a new project (Sudoku has been put on hold for now), and this is essential to the project's success.

As a little gift, here is a preview of my project:

gp32daily7jd.jpg


I have quite a lot planned for this project, and if it turns out anywhere near as good as I believe it will, it will be an item that everyone can enjoy :D
 
Here's something I just untangled from an old project. Not tested or optimised but here you are....

Code:
#include "gpdef.h"
#include "gpstdlib.h"
#include "gpstdio.h"

void GpMain (void * arg)
{
	F_HANDLE ini;
	ERR_CODE err;
	int i;
	char launch[256];
	int path_len, data_len, enc_len, gxb_len;
	char buf[4];
	unsigned char *enc, *data, *gxb;

	GpFatInit();
	gp_str_func.strcpy(launch,"gp:\\GPMM\\myprog.fxe");
	path_len=gp_str_func.gpstrlen(launch);
	if(err=GpFileOpen(launch,OPEN_R,&ini))
	{
  //File not found, so do something about that here.
	}
	if(err=GpFileRead(ini,buf,4,NULL))
	{
  //Unable to read from file
	}
	if(!((buf[0]=='f')&&(buf[1]=='x')&&(buf[2]=='e')))
	{
  //Not an FXE file!
	}
	GpFileSeek(ini,FROM_BEGIN,1116,NULL);
	GpFileRead(ini,&data_len,4,NULL);
	GpFileRead(ini,&enc_len,4,NULL);
	enc=gp_mem_func.malloc(enc_len);
	GpFileRead(ini,enc,enc_len,NULL);
	for(i=0;i<enc_len;i++)
  enc[i]^=0xff;
	data=gp_mem_func.malloc(data_len);
	GpFileRead(ini,data,data_len,NULL);
	for(i=0;i<data_len;i++)
  data[i]^=enc[i%enc_len];
	gxb=gp_mem_func.malloc(4+data_len+enc_len);
	gxb_len=data_len+enc_len;
	gp_str_func.memcpy(gxb,&gxb_len,4);
	gp_str_func.memcpy(gxb+4,data,data_len);
	gp_mem_func.free(data);
	gp_str_func.memcpy(gxb+4+data_len,enc,enc_len);
	gp_mem_func.free(enc);
	launch[path_len-4]='\0';
	GpAppExecute(gxb,launch);
}
 
Chris - I'll see how that works out, thanks

Aquafish - Your website isn't working - I'm getting 404s on both links
 
Could be one of two problems why aquafish's link wasn't working for you:

1. He posted it as http://www.gp32x.de/aquafish/..., but I switched to a new server and now he got a subdomain (aquafish.gp32x.de). I changed the links, but maybe you tried looking earlier...

2. I moved to the new server two days ago - maybe the DNS of your provider hasn't updated that yet, so you'll have to wait a bit more.
 
It's a DNS issue. I managed to get the files from the old server now. Thanks!
 
Interesting...

Could be possible to go deeper for MAME-GP32???

I would like to do a frontend of all supported games in an FXE and after the user selection, load the appropiate FXE executable to launch the game. But i would like to pass the name of the game to the executable.

I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.

I don't want to use SMC file writings for this, due to the maximum number of SMC writings.

I have been thinking about changing on-the-fly the contents of a memory location of the loaded executable. Maybe i could change the contents of a variable to tell the executable the game to run. Could it be possible? The problem is that i would have to use not compressed FXE's to access the variable location (using B2FXE instead of B2FXEC).

Another chance could be writing the name of the game in memory zone not used by the executables (i.e. in the not used in my program 8bit video buffers 3-4). But i don't know if it could be done, maybe the contents of these memory regions are cleared by the GP32 O.S. when the new program starts to run.

Also another problem could be the memory. It seems that executable is loaded in RAM and maybe the memory occupied by the calling program is not freed for the called program. It could be a real problem because some drivers spend a lot of RAM and it would be problems to load biggest games...

Maybe some of you could enlighten me???
 
Wouldn't it be smarter to use a dynamic linking library system? There are ways of doing it on the GP32. A couple of people posted about it a little while back. Also, I believe Slubman's firmware uses a similar system for its plug-ins. And Slubman's firmware's source code is available.
 
I would like to do a frontend of all supported games in an FXE and after the user selection, load the appropiate FXE executable to launch the game. But i would like to pass the name of the game to the executable.

I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.
The second parameter passed to GpAppExecute is supposed to be the application path, but it can actually be anything you like. In the gpQuake launcher I use the app path variable to send various command line parameters to the main quake executable. Use GpAppPathGet in your main executable to retrieve these parameters.
 
Last edited by a moderator:
The second parameter passed to GpAppExecute is supposed to be the application path, but it can actually be anything you like. In the gpQuake launcher I use the app path variable to send various command line parameters to the main quake executable. Use GpAppPathGet in your main executable to retrieve these parameters.

THANK YOU!!! I will check it
 
Last edited by a moderator:
I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.

you can use a simple trick: after you selected the game to start in the frontend, you write the game-filename in a textfile. and after that you load the .fxe and the .fxe loads by default the game from the textfile the frontend just wrote.

should work, i guess.
 
I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.

you can use a simple trick: after you selected the game to start in the frontend, you write the game-filename in a textfile. and after that you load the .fxe and the .fxe loads by default the game from the textfile the frontend just wrote.

should work, i guess.

You'll eventually kill your SMC that way.
 
Last edited by a moderator:
I would like to do a frontend of all supported games in an FXE and after the user selection, load the appropiate FXE executable to launch the game. But i would like to pass the name of the game to the executable.

I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.
The second parameter passed to GpAppExecute is supposed to be the application path, but it can actually be anything you like. In the gpQuake launcher I use the app path variable to send various command line parameters to the main quake executable. Use GpAppPathGet in your main executable to retrieve these parameters.

I've tried to use this to put a front end into GP Mame, and I've had success passing in an argument so that a ROM file is automaticallly loaded. However, I've had a problem which seems to make these improvements pointless.

When you've finished playing the game, or you've changed your mind which game you wanted to play after getting as far as the options screen, then how do you return control to the calling application?

i.e.
LAUNCHER.FXE displays a list of available games, then calls matari.fxe with the full path of the ROM file. matari.fxe can then automatically play the game, but how do I get control back to LAUNCHER.FXE so it can continue listing other games to be played?

I've tried using GpAppExit() and that just seems to reboot the GP32!
 
Last edited by a moderator:
thegrimreaper posted on Jul 9 2005 at 03:02 PM said:
I would like to do a frontend of all supported games in an FXE and after the user selection, load the appropiate FXE executable to launch the game. But i would like to pass the name of the game to the executable.

I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.
The second parameter passed to GpAppExecute is supposed to be the application path, but it can actually be anything you like. In the gpQuake launcher I use the app path variable to send various command line parameters to the main quake executable. Use GpAppPathGet in your main executable to retrieve these parameters.

I've tried to use this to put a front end into GP Mame, and I've had success passing in an argument so that a ROM file is automaticallly loaded. However, I've had a problem which seems to make these improvements pointless.

When you've finished playing the game, or you've changed your mind which game you wanted to play after getting as far as the options screen, then how do you return control to the calling application?

i.e.
LAUNCHER.FXE displays a list of available games, then calls matari.fxe with the full path of the ROM file. matari.fxe can then automatically play the game, but how do I get control back to LAUNCHER.FXE so it can continue listing other games to be played?

I've tried using GpAppExit() and that just seems to reboot the GP32!
You can't 'return' control to the calling application because you're not using a multitasking system - once app1 has launched app2, app1 is completely erased from memory and there is nothing to return to. You can fake this behaviour replacing GpAppExit() with something like GpAppExecute(OriginalApp,LoadedRomName). Eg, in app1 browse to find the rom, select and launch app2 passing the rom name. When exit from app2, reload the launcher (app1) and pass the rom name again. app1 can then use the previously selected rom name to somehow return to the same menu location and it will appear like it has always been sitting there waiting.
 
Last edited by a moderator:
woogal posted on Jul 9 2005 at 05:38 PM said:
You can't 'return' control to the calling application because you're not using a multitasking system - once app1 has launched app2, app1 is completely erased from memory and there is nothing to return to. You can fake this behaviour replacing GpAppExit() with something like GpAppExecute(OriginalApp,LoadedRomName). Eg, in app1 browse to find the rom, select and launch app2 passing the rom name. When exit from app2, reload the launcher (app1) and pass the rom name again. app1 can then use the previously selected rom name to somehow return to the same menu location and it will appear like it has always been sitting there waiting.

A brilliant idea, in fact Franxis gave me the same suggestion earlier today.

Cheers
 
Last edited by a moderator:
i didn't understand what's so dangerous with the .ini file method i posted on the first page.
if you write all options/settings and the rompath to load in an .ini file, then you can easily get back all the settings.
 
0-bake posted on Jul 9 2005 at 07:09 PM said:
i didn't understand what's so dangerous with the .ini file method i posted on the first page.
if you write all options/settings and the rompath to load in an .ini file, then you can easily get back all the settings.
It's not really that dangerous, but people often try and limit the amount of times an smc is written to because eventually they will wear out (but nowhere near as fast as people seem to think). Your method is slightly slower though because writing the .ini will add an extra second or so to the launch time, but it's probably better if you're passing lots of parameters because I'm sure the string passed to gpappexecute must have a maximum size (although I've no idea what that size may be). Your method is also the only way to store the selected rom between reboots (so the menu will always return to the last selected rom).
 
Last edited by a moderator:
I don't know if this way to load an FXE from the program could be the solution, but it seems there is no way to pass command line parameters to the FXE's.

you can use a simple trick: after you selected the game to start in the frontend, you write the game-filename in a textfile. and after that you load the .fxe and the .fxe loads by default the game from the textfile the frontend just wrote.

should work, i guess.

You'll eventually kill your SMC that way.

Through a bit of "hacking" I found out that Fenix works that way, so I guess its ok.
 
Last edited by a moderator:
Back
Top