Files in eboot for single file programs

[Art]

Hi Guys,
I've searched for a way to do this, but hit a dead end.
I would like to know how to store complete files in a c program so
that they can be accessed by the program and written to memory
stick or flash at run time.
I have seen MPH downgrader stores a font in the c program this way,
and there's a program called mach-1 that stores pictures this way,
but doesn't tell you how to access them.

Any help in this matter would be appreciated. (inc. links to source) :)
Cheers, Art.

[ipsp]

Are you really sure you want to do this ????

There are various side-effects you should consider, biggest of those being that each resource you include will add to the amount of memory required to start up the application. For example say the executable is 250kb, and you include 2mb of images, the executable will become 2.25Mb, and hence when the progam starts up it will need that much memory to execute.

If you need these resources, why not just dump them into a subfolder and access them that way.

I get the impression people have read examples that come with the PSPSDK, and assume that this is the best way to include resources, infact most of the gu examples are like that. If you give an example of what you are trying to do then perhap I can give you an example of a better way to do it.

[Art]

I don't care if it uses more memory and takes more time to load.
In fact, that's great, I won't see the ms LED flashing after the program
is loaded into RAM.

Are you really sure you want to do this ????

Um, Yes :)

If you need these resources, why not just dump them into a subfolder and access them that way.

I am, but I don't want to.

I get the impression people have read examples that come with the PSPSDK, and assume that this is the best way to include resources,

I've looked at quite a few samples, and still can't see how to do it.

If you give an example of what you are trying to do then perhap I can give you an example of a better way to do it.

Store certain files destined for flash0 and flash1 away from anyone who
would pry or alter the files. opening_plugin.rco is one example,
The pair of registry files in flash1 complete with WEP keys is a better example.

I have my program working, but there files are in subfolders that are best off
not there.

[starman2049]

I use bin2o to convert a file into object format that can then be linked into my app.

In my makefile I include, for example, golfball.vo as an object file, and the the rule to make golfball.vo is:

golfball.vo: golfball.bin
bin2o -i golfball.bin golfball.vo golfball

This creates an extern int reference to 'golfball_start' which I can get the address of at runtime. If you look at bin2o I think it generates other ints too.

Don't know if this helps or not but I use it sucessfully...

[Art]

ok, Google yields results for bin2o, so there's no problem finding it,
but could you provide syntax of how you'd retrieve the file and use
it in a copy routine?

[Art]

I didn't realise it was a tool in the sdk http://ps2dev.org/kbversions.x?T=1161

Are you supposed to compile bin2o and bin2c on the PSP and convert the
files with the PSP?

[weltall]

no they should be compiled for your pc/mac if you made the toolchain

[Art]

I only got the c files in the sdk.
I downloaded bin2c executeable from the net though,
but is there any samples to show how it is inserted into a program
and accessed with fileio?

[danzel]

A quick look at the code of bin2c explains what it does:

It reads in your input file and create a c file containing the following code:

Code: Select all

extern const unsigned char %s[];
extern const unsigned int %sSize;

static const unsigned char %s[] =  {%x,%x....};
static const unsigned int %sSize = %d;

(where %s = the name you want the output file to have without extension, I'll assume bob for the rest of the explanation)

So now your input file is stored in a character array named bob, which has size bobSize.
In your code you access your file as a character array (c-string).


To use it in your program you should copy the first two lines into a header file and include it, and add the .c file it generated to your makefile.

Code: Select all

//bob.h
extern const unsigned char bob[];
extern const unsigned int bobSize;

and then use it in your program as a c-string, example:

Code: Select all

printf("size of file: %i\n", bobSize);
printf("first 3 bytes in hex: %x %x %x \n", bob[0], bob[1], bob[2]);

[Art]

Idealy, I would like to save the file back to memory stick, but that's a very
good start, thanx :)
I will try to get what you have posted so far working.

[danzel]

(iirc) Writing the data out to a file would go like this:

Code: Select all

FILE* outfile = fopen("somefile", "w");
size_t written = fwrite(bob, 1, bobSize, outfile); 
fclose(outfile);
printf("wrote %i bytes\n", written);

Standard c file output stuff :)

[floorball92]

OK, but how to use the picture than in the file, I mean, bin2c makes my .png to a c file, and in this c file, there is my image in hey, but there is only the hex code, so I don' t know, how to blit it. Could you please explain this??

[Art]

It's done in the sample here:
http://forums.qj.net/f-developers-dunge ... page3.html

[floorball92]

Oh, that' s nothing for me cause I' m using the OSL to make my Programms. Then I will have to load them from Memory, if it' s only for normal graphics.c.

[AlphaDingDong]

What's the difference in loading the filedata via bin2c vs bin2o? I mean, yeah, an .o is a binary data file iirc, but I've never worked with them directly. Are they accessed from the program in the same way? Also, is it really true that a larger eboot will take up more memory? It can't be possible that an eboot loads completely into memory because the PSP only has 32mb of ram and many eboots are much, much larger than 32mb. I suppose that if you used bin2c it would work that way, since I'm assuming bin2c simply string-dumps the file and then puts it into a char array, so the array would be loaded into memory, but ... Hmm... (So if I did it that way I could just cut and paste the file created by bin2c and put the data into the variable manually when I wanted it to load, then kill it when done...) Anyway, does using a .o file work differently? There must be some way to store massive amounts of data in an eboot and then load them when they're needed. :p

I'm rambling. Sorry. I'm a PSP-C noob.

[Art]

The whole eboot is loaded into memory with all the images that were stored in arrays with it.
Then graphics c loads the images into another array at runtime using more memory,
so one image used double the memory,
BUT once the image is loaded, you are free to use the original array for something else, so you can claim the first part of memory back for yourself.

[AlphaDingDong]

I'm confused then. How can eboots be larger than the RAM size and still run?

Why would the eboot itself be loaded into RAM when it can just be read from the ms? At any rate, the idea I had about bin2c was that you could use it to create the char array and then just copy and paste the char array into the statement that creates the image. For instance, if a png image converted to:

"dfjvnadfjkvnajklfdnvladf"

then instead of loading that into a char[?] you could just feed it to the image creation command directly... Unless that command takes a pointer....

Argh... I need to look it up now, but my docs are at home.

[Tinnus]

"dfjvnadfjkvnajklfdnvladf" is a pointer.

What bin2c or bin2o do is that they convert your stuff to a char*, not much different than "sgjvoryh9ejg9ejrf0e", IIRC it writes the data in hex because not all 256 char values can be encoded in the C file.

[AlphaDingDong]

"dfjvnadfjkvnajklfdnvladf" is a char array. A pointer is just a number referring to a memory address. The pointer for "dfjvnadfjkvnajklfdnvladf" would just refer to the location of the RAM address of the first byte.

char mystr[20];
mystr is an array containing 20 char's

int mystrp = *char;
mystrp is a pointer that refers to the first byte of mystr

If it's hex then that would work even better because the size would be smaller. It could be handled similarly with a simple function.

I'm still confused about how a 500mb eboot can run if eboots are loaded into RAM on runtime.

If the image from memory function takes a pointer then the data could be handled jit:

Code: Select all

char imagedata[200] = "????????????";
Image myimg = functionWhosNameIdontKnow(*imagedata);
imagedata = NULL;

But if the whole eboot is loaded into RAM then it's pointless.

[Jim]

int mystrp = *char;
mystrp is a pointer that refers to the first byte of mystr

char *mystrp = mystr;

If it's hex then that would work even better because the size would be smaller

No, there's no difference between
char mystr="ABC";
and
char mystr[]={0x41, 0x42, 0x43, 0x00};

char imagedata[200] = "????????????";
Image myimg = functionWhosNameIdontKnow(*imagedata);
imagedata = NULL;

You can do

Code: Select all

char imagedata[200] = "????????????"; 
Image myimg = functionWhosNameIdontKnow(imagedata); 

But you can't free it by doing
imagedata=NULL;

You really need to brush up on your C coding before tackling the PSP.

Jim

[sallyxi]

Oh,if I' m using the OSL to make my Programms. Then I will have to load them from Memory, how shall i do..

[AlphaDingDong]

int mystrp = *char;
mystrp is a pointer that refers to the first byte of mystr

char *mystrp = mystr;

Yeah. That one.

If it's hex then that would work even better because the size would be smaller

No, there's no difference between
char mystr="ABC";
and
char mystr[]={0x41, 0x42, 0x43, 0x00};

I thought what he was saying was that rather than dumping it to a string of escaped base 10 values it was dumping to a string of hex values "41424300" and converting them later with an included function. I guess it makes more sense the way you describe. At any rate I found the source of bin2c and bin2o and I'm gonna read them in a little while here and figure out what the hell is going on.

char imagedata[200] = "????????????";
Image myimg = functionWhosNameIdontKnow(*imagedata);
imagedata = NULL;

You can do

Code: Select all

char imagedata[200] = "????????????"; 
Image myimg = functionWhosNameIdontKnow(imagedata); 

But you can't free it by doing
imagedata=NULL;

Ah, there's no garbage collector in C, is there. I think I was thinking in Lua.
Is it 'free(imagedata);'?
I'll look it up.

You really need to brush up on your C coding before tackling the PSP.

If I never developed anything because I didn't know the language first I wouldn't know any languages at all. One of the advantages of 'tackling the PSP' is that I've already learned more C just by PSP tinkering than I did in the two semesters I took in college, but I'm also in the middle of learning Lua, trying to figure out all the in's and out's of cygwin, learning to manage downloaded libraries and trying to figure out where the hell the documentation for them is and still trying to deal with paying the bills and feeding the cat. I can't afford to go to school for this stuff and I don't have an internet connection at home because I'm poor, so I have to drive to a friend's house and mooch bandwidth.

I'm sorry I got pointer declaration wrong and forgot that there's no GC in C. I'm trying to figure this stuff out all at once because after the Brad Dwyer tuts and my crappy old "C for Yourself" reference book I'm having a hard time finding documentation on a lot of things and understanding what the hell it's talking about when I do. Lately I've been spending more time on Lua than C because I can't go much further with C until I've put together what libraries to use for sound and how to use the GU for more than just drawing wavy triangles and squares.

Please bear with me while I try to wrap my brain around this stuff. I'm not trying to step on anyone's toes or anything. Give me a couple months and I should have caught up.

At any rate, does the whole eboot seriously load into RAM at runtime?

Meh, nevermind. I'll just write something to check it out myself.

My whole point was just that unless the eboot is indeed loaded into RAM then this can be done without detriment. But if the whole eboot is loaded into RAM then it has a big downside. However, I know from experience that eboots larger than the RAM can be loaded and run, therefore I know that there must some way of loading and running an eboot with at least part of it outside memory. Possibly the same method could be used to accomplish what's being discussed.
---------------------------------------------------------------
edit:
Convergence. One of the other questions I came up with last night was wth is a .psar?

Googling resulted in finding this:

EBOOT.PBP contents:
PARAM.SFO 944b
ICON0.PNG 24830b, 0.02mb
PIC0.PNG 2847b
PIC1.PNG 269424b, 0.26mb
DATA.PSP 29595b
DATA.PSAR 143.44mb

I think they were discussing an eboot of a POPS game from the playstation store. The reason I had the question is because I saw last night that mksfo can take a .psar along with icons and all that. Now researching .psar's. I'll post back here what I find.
-----------------------------------------------------------------
After googling the site all I've found about psars is that they're archives in eboots that Sony uses to store FW upgrade files and PSX ISO data. This means that if someone has figured out how to create and access a psar then we have our answer. (lol. I'm half expecting a similar response to this: (http://www.dcemu.co.uk/vbulletin/showthread.php?t=45247)

[Jim]

Is it 'free(imagedata);'?

You can only free() something that you got with malloc(), calloc() or realloc(). There's no way at all to free a static array.

Jim

[adrahil]

You could also use the PBP format to embed your file inside, such as updaters who embed the PSAR ones. (Then, they just sceIoOpen the file and seek to the position of the PSAR which is indicated in the PBP header) Like this, you can embed a lot of data in a file and read parts of it without loading it all to memory.

[AlphaDingDong]

Sweet. It can be done then.

I'll look into malloc() and try to figure that out. Thank you for your patience.

I'll look around for psar embedding stuff and if I can't find anything I'll try fiddling with it myself.

[jsharrad]

There's a program out there called PBPCat that does it, it's by flatmush and should still be available for download on the psp-programming.com forums.

I believe it allows you to use a command line tool to add any file you like to the EBOOT.PBP itself and just stores the data offsets in its own header at the beginning of the file.