fopen VS. sceIoOpen ?

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

fopen VS. sceIoOpen ?

Post by anmabagima »

Hi there,

I'm not sure whether this question was ever asked in this forum. However, I would like to understand why and when it is best suited to use either fopen or sceIoOpen to access files in read mode (and the corresponding functions to write etc...)

What is the difference between the functions - if there is one ?
I'm using manly the fopen/fread etc. function to access files in my homebrew - is there a knwon disadvantege in using them ?

Thanks in advance for any suggestions and advice.
Davee
Posts: 43
Joined: Mon Jun 22, 2009 3:58 am

Post by Davee »

fopen/fread/fwrite/fclose etc are the standard libc functions. They aren't "standard" in the PSP kernel so the sdk has wrappers for them which eventually translates them into sceIo* calls.

So the disadvantage is, is that it takes longer to use f* than it does sceIo*.
victorprosa
Posts: 37
Joined: Wed Jan 14, 2009 5:53 am

Post by victorprosa »

If you are able to do that, ALWAYS prefer Sce* functions, because it was designed especially for the PSP hardware, by guys that understand it better than us...
And, the standard libc functions are translated into Sce* functions, but usually you lost performance...
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi there,

thanks for your replies. Just one thought: could I use sceIoOpen with PSPLINK in the same way I would use fopen ?
I just have seen that you need to pass a full qualified path to sceIoOpen in all the threads (starting whith device). I would assume that the device is different when using the homebrew with PSPLINK instead of from the memory stick. Am I right ?

Thanks for any hint.
unsigned int
Posts: 18
Joined: Thu Aug 13, 2009 11:42 pm

Post by unsigned int »

You should be able to use the same file names for sceIoOpen and fopen. Looking at the source code for the PSPSDK libc the fopen function just passes the path through to sceIoOpen without altering it in any way.
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi,

thanks for confirmation. I will give it a try :)
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi,

I've tried sceIoOpen as I have used fopen. However, this results in error: 0x8002032c

fopen( params->fileName, "rb" ); works but sceIoOpen( params->fileName, PSP_O_RDONLY, 0777 ); does not. Any ideas ?

params->fileName = "testfile.txt"

Google returns "No Cwd ??" when searching for this error code...

Thanks for any hints...Am I assuming right I should pass "device:path/filename" to sceIoOpen ? If so, what is the path I need to put if I only know that the file is stored together with the Eboot on MS or together with the PRX on the harddisk using PSPLINK. In many threads I've seen MS0: as device for the memory stick, but shouldn't be host0: during PSPLINK ?
Alberto
Posts: 51
Joined: Mon Feb 12, 2007 8:16 pm
Location: Sofia

Post by Alberto »

anmabagima wrote: I've tried sceIoOpen as I have used fopen. However, this results in error: 0x8002032c
this looks like the dwd (current working directory) has not been set.
I don't know how to set it, (I had a thread few days ago about somenting smilar which I solved my way...)

But from the params passed to your program, argv[0] is the complete filename and path of your eboot. Take the filename out and you have your cwd. Add it in front of your filename and you should be done...


HTH

Cheers, A.
victorprosa
Posts: 37
Joined: Wed Jan 14, 2009 5:53 am

Post by victorprosa »

I don't understand well what you are trying to do, but i may tell that:

Relative paths do work in SceIo, and all commands related to it, like "./" also does...
The initial path in SceIo is always the path of your homebrew, ie:

Code: Select all

	SceUID fd = sceIoOpen("lol.lol", PSP_O_WRONLY | PSP_O_TRUNC | PSP_O_CREAT, 0777);
	sceIoWrite(fd, data, sizeof(data));
	sceIoClose(fd);
In the case above, you are creating/editing a file in:
ms0:/PSP/GAME/MYHBDIR/

-------------------------------------------------------

By the way, i sugest you to store things like paths, in chars...

-------------------------------------------------------

Also, i don't use PSPlink, for me, in linux, is faster to add the exit callback and all the time i get stuck, just leave the homebrew, fix the source and test it again, i don't even disconnect the USB cable...
Btw, things that usually crashes the PSP (which are rare) i solve the old way...

So, i am not able to answer you if this crash is a PSPLink job, i just tell how the PSP reads the stuff in normal conditions...
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi victorprosa,

thanks for your reply. It is exactly what I've assumed and what I'm trying.

I'm calling sceIoOpen( "myFile.lol", PSP_O_RDONLY, 0777 ); which results in the error mentioned.
However, fopen("myFile.lol", "rb") does work.

In both cases it was tested using PSPLINK. In some circumstances I need to debug my code as it is evolving. I found PSPLINK very useful for this in the past. If this does not work with sceIoOpen than may be I need to choose the same approach and compile, pass to MS , execute and if it failes correct my code....
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

Seeing that NOTHING cross platform will ever compile for the PSP without extensive modification, it seems redundant to leave the fopen calls as such. You might as well convert everything to sce* while porting.
hlide
Posts: 739
Joined: Sun Sep 10, 2006 2:31 am

Post by hlide »

Always use sceIo* functions instead of f* functions. Why ? f* uses buffers. The issue is if you let PSP to go in standby whereas you have FILE* handles open, you'll get problem when you wake up your PSP.
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi,

sorry for asking a stupid question, but what does this actually mean ?
Do I need to have a branch on each file activity statement which choses f* if compiling and running using PSPLINK and sceIo* when compiling finally fpr PSP memory stick ?

Thanks.
unsigned int
Posts: 18
Joined: Thu Aug 13, 2009 11:42 pm

Post by unsigned int »

Just wanted to add that I stand corrected on my previous assumption that fopen() didn't change the path when calling sceIoOpen().

I found out that the PSPSDK libc implementation does this, but (unless otherwise specified in the Makefile) it is not used, but newlib is. And in there is in fact code to expand a relative path to a full path before calling sceIoOpen().

So it is probably the best to do what Alberto posted earlier, take the working directory from argv[0] and expand all filenames yourself.
yokfran
Posts: 12
Joined: Mon Dec 28, 2009 9:17 pm

Post by yokfran »

I think sceIo* is better.

If you use fopen, you have to manage these FILE* pointers yourself. And I think the SceUIDs that returns by all sce* functions, is managed by some sce* threads which are built inside the PSP system.
So you do less work than using fopen/f* etc.

If sceIoOpen returns error code, it's better to use abs-path.

Sample code.

int main(int args, char *argv[])
{
char bootpath[64], *ptr;//i think 64 is long enough
strcpy(bootpath, argv[0]);
ptr = strrchr(bootpath, '/');
*++ptr = 0;
//Boot directory is in bootpath now.
}
Last edited by yokfran on Sun Feb 21, 2010 4:23 pm, edited 1 time in total.
anmabagima
Posts: 87
Joined: Thu Oct 01, 2009 8:43 pm

Post by anmabagima »

Hi,

thanks. will try this out.

Regards...
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen.

Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-documented everywhere) and we've already handled a whole mess of these sorts of bugs in the sce* interfaces.
hlide
Posts: 739
Joined: Sun Sep 10, 2006 2:31 am

Post by hlide »

jimparis wrote:sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen.

Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-documented everywhere) and we've already handled a whole mess of these sorts of bugs in the sce* interfaces.
included the case after a suspend mode ?
Alberto
Posts: 51
Joined: Mon Feb 12, 2007 8:16 pm
Location: Sofia

Post by Alberto »

hlide wrote:included the case after a suspend mode ?
I have always been told that before going to suspend mode I need to save my open files (together with theis file positions, of course), if any., and then allow suspend. When resuming from suspend (there is the callback...) reopen the files that were open and reposition them.

...although I don't find a good practice keeping any file open for the entire life of the application...

JM2C
A.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

hlide wrote:
jimparis wrote:sceIoOpen is buggy when it comes to relative paths. I don't recall the details, but the newlib wrappers just canonicalize everything before passing to sceIoOpen.

Unless you're really performance sensitive, you should use the newlib wrappers when available. They're easier to use (since they're well-documented everywhere) and we've already handled a whole mess of these sorts of bugs in the sce* interfaces.
included the case after a suspend mode ?
Not yet, but it would be easy because of Rafael's fd management that keeps track of the filename that goes with each open file. You could add a field to __psp_descriptormap_type to store the offset, and then add two hook functions: one that loops through all open file FDs and gets the offset, then another that closes/reopens/seeks to the right offset in each file.

But libc doesn't know about suspending, so you'd have to call those hooks manually.
hlide
Posts: 739
Joined: Sun Sep 10, 2006 2:31 am

Post by hlide »

jimparis wrote:Not yet, but it would be easy because of Rafael's fd management that keeps track of the filename that goes with each open file. You could add a field to __psp_descriptormap_type to store the offset, and then add two hook functions: one that loops through all open file FDs and gets the offset, then another that closes/reopens/seeks to the right offset in each file.

But libc doesn't know about suspending, so you'd have to call those hooks manually.
maybe using scePowerRegisterCallback to let a callback calls those hooks.
Post Reply