forums.ps2dev.org

[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.

[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:

[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:

[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-dungeon-47/t-post-some-c-samples-64005/page3.html
_________________
If not actually, then potentially.

[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.
_________________
If not actually, then potentially.

[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.
_________________
Let's see what the PSP reserves... well, I'd say anything is better than Palm OS.

[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:

[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]

[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.