GP32 Standard information file (File managers)

[taras]

OK, I was thinking of this a lonnnng time ago and just remembered.

There are some great file managers for GP32 at the moment, particularly Wind-Ups and comi. There are also (obviously) lots of great programs and emulators.

Now for the idea. The purpose is to combine the file manager with the programs.

There could be a standard file, for example gp:/etc/current.dat, which would contain information about what the user was currently doing. So you could have something along the following lines:

1. User selects mariodx.gbc in file manager and presses A to open it;
2. File manager (comi.fxe) has been set up to open gpmm/fgb.fxe when a .gbc file is selected;
3. File manager writes this to etc/current.dat:
open=gpmm/gb/mariodx.gbc
return=gpmm/comi.fxe

4. Now, when fgb.fxe is opened, it checks current.dat and sees that it needs to open mariodx.gbc, and does so automatically.
5. When you quit fgb.fxe, instead of rebooting the GP32, it runs comi.fxe - effectively returning you to the file manager, which deletes or overwrites current.dat as the operation is complete.

This would also be great for applications - for example, you could then choose a stand-alone text editor instead of the file manager's built-in one. It would be effectively imitating very crude multitasking.

I can see problems with this system, namely if you turn off the gp32 mid-way and later return and run fgb.fxe by itself, it will automatically run mariodx.gbc. But if you could run any rom you wanted from the file manager, you wouldn't need to run fgb.fxe by itself anyway.

Weeeellll..?

 

[Robster]

It's a cool idea, and it's been discussed a lot already.

The difficult bit as I see it is "instead of rebooting the GP32, it runs comi.fxe" - is there some pre-written code to run .FXEs out there, that all the application coders can "clip in" to their applications?

If someone can provide a nice simple library with a "ExitAndRunFxe("...")" function, then I'm sure this will eventually become a reality.

Another idea would be to make the file manager part of the BIOS so it runs at reset/power on. Then the applications themselves wouldn't have to worry about running the file manager, they could just reset as they do now.

 

[taras]

That would mean people would have to flash their machines, though, something which I'm never going to do (want to keep mine exactly how I bought it )

 

[trooper]

You can do this already with pacrom (in multiFW).
When you switch on or reboot the GP32, Pacron can
load up a predefined program eg. a file manager.

Trooper

 

[rcx21000]

You could even make it able to do more than one thing at once if you wanted. Once you run a prog it adds some info to current.dat, and on exit it removes, but if you 'minimize' it, it would change it, so:

1. On GP32
2. Run filemanager
3. Run this.gbc
4. curent.dat looks like:
[fgb]
open=this.gbc
return=comi.fxe
data=NONE
[/fgb]
5. 'Minimize' fgb
6. current.dat:
[fgb]
open=this.gbc
return=MINIMIZED
data=(whatever data fbg needs to start at the same point)
[/fgb]
7. Now you run gloopdx.fxe
8. Current.dat:
[fgb]
open=this.gbc
return=MINIMIZED
data=(whatever data fbg needs to start at the same point)
[/fgb]
[gloopdx]
open=NONE
return=comi.fxe
data=NONE
[/gloopdx]
9. You minimize gloopdx
10. current.dat:
[fgb]
open=this.gbc
return=MINIMIZED
data=(whatever data fbg needs to start at the same point)
[/fgb]
[gloopdx]
open=NONE
return=MINIMIZED
data=(whatever data gloop needs to start at the same point)
[/gloopdx]
11. You maximize fgb through the filemanager, and fgb checks the current.dat, and finds all its stuff
12. current.dat:
[fgb]
open=this.gbc
return=comi.fxe
data=NONE
[/fgb]
[gloopdx]
open=NONE
return=MINIMIZED
data=(whatever data gloop needs to sart at same point)
[/gloopdx]
13. You close fgb
14. current.dat:
[gloopdx]
open=NONE
return=MINIMIZED
data=(whatever data gloop needs to sart at same point)
[/gloopdx]
15. You turn off GP32
16. You turn on GP32
17. You run filemanager
18. You still see in your minimized section gloopdx!

That would take alot of programming and SMC space, but would be cool You cold even turn off in the middle of a game (if everything is 'minimized') and start off at the same point...

 

[Dave18]

Would it not be possible to create a file manager that also controlled memory.
It would effectively protect it's own memory space and load the program into an available area of memory.

It would place the file managers registers and current PC onto the stack and as long as the program exited properly control would be returned to the file manager.

The big difficulty would be ensuring that once the program was running, memory allocations made by the program did not overwrite the file manager's code.

Soon we'll have GP32OS!

 

[rcx21000]

Then the mem would go down to ~7MB and the OS would also use up some processing power, so youd need to run at 166 to get 100MhZ for the prog I guess...

 

[Dave18]

The file manager wouldn't take any processor overhead as it wouldn't be running simultaneously with the program. It simply stores certain information on the stack so that it can be returned to when the program exits.

Granted you would lose some memory but it wouldn't be much and how often is all 8 meg used anyway.

The FM could store systems variables such as where it finishes in RAM and the alloc command could be adapted to ensure that it only allocates memory after that address. Trouble is, C has so many ways of allocating memory (such as simple variable declarations) that it would be difficult to stop the FM from being overwritten.

 

[Squidge]

Well, the ARM processor does have a memory management unit, which would allow you mark certain sections of memory as "read only". Also, when loading an app, you could only leave in memory say 1kb of code, which, when returned to, simply loaded the rest of the prog back from the SMC - no need to store it all in memory.

Actually, thinking about it, a MMU page is about 4kb, and you should easily be able to store a program that simply loads the rest from disk and executes in that amount of ram (it would only need to be a AXF or GXB file for direct loading).

Would need to know how the machines default memory allocators work though - do they allocate memory upwards towards higher addresses or downwards to the lower addresses?