forums.ps2dev.org

b00st wrote:jimparis: My command is the same, except I put the whole path to psp-config.

No, it is not. You put a space before "/lib" and you used apostrophes instead of backquotes. Read and follow README.PSP.

I don't know where you got that command, but it's wrong. Use the one in README.PSP:

Read README.PSP

I still say that there's no possible difference between calloc() and malloc() because the only variable in the DIR structure gets overwritten immediately anyway. If you can provide a small compilable example I'll check it out, but I suspect your problem is hidden elsewhere and is just being triggere...

You sometimes get a "home" button down event when the backlight turns off. I noticed this earlier (see log for rev 574 in psp svn repo). But you don't need to pay attention to the home button anyway, so just ignore it. Set a flag in your exit callback and check that instead.

It seems that memory that is allocated for DIR structure in opendir() should be initialized to zero, as current implementation causes PSP to freeze. Do you have an example? It's working fine here. The DIR structure only contains a single element anyway, which clearly gets set in the very next line,...

I'd rather see something without a lookup: static int psp_set_errno(int code) { if (code & 0x80010000) { errno = code & 0xFFFF; return -1; } return code; } and then modify our newlib errno.h to use errno codes that match up ...

Add "-Wl,--start-group" to the beginning of your LDFLAGS.

Nevermind, I fixed it in rev 1150.

$at and $v1 appear to get clobbered while stepping with gdb. This is with the gdb sample: Remote debugging using /dev/ttyS0 main () at main.c:81 81 sceCtrlSetSamplingCycle(0); (gdb) info reg zero at v0 v1 a0 a1 a2 a3 R0 00000000 0008ff00 044ba1...

Ground (pin 2, blue) too. That's it.

Yeah, just connect pin 3 (orange) on each PSP to pin 6 (grey) on the other (using the numbering here).

I haven't used the GE; obviously this wouldn't work if there's a case where you're changing the data as the GE reads it. Well, that would be inherently buggy code anyway. Concurrent memory access can surely work if you're careful (think Dekker's algorithm), and this might be useful for future work ...

Rather than all the mess with uncached pointers and cache line sizes, can't you just do business as usual and force a writeback before telling the GE to use it? I haven't used the GE; obviously this wouldn't work if there's a case where you're changing the data as the GE reads it.

The toolchain at oopo's site is old and incompatible with current pspsdk. Checkout svn://svn.pspdev.org/psp/trunk/psptoolchain/ and run the toolchain.sh in there.

I have no idea what your code or build process looks like, but it appears you're not linking against the right libraries. You need -lpsuser and -lpsputility at least. See the build.mak in pspsdk.

Or just start with samples that actually work:

When you install the toolchain, it automatically checks out the latest pspsdk from subversion and builds it, so you probably didn't even need to rebuild it, but it should install to /usr/local/pspdev by default. I found GU_PSM_8888 and used "svn blame" to see when it was added. In general,...

Yes. Looks like those defines you were looking for were changed in revision 661.

You probably checked out the wrong branch from SVN. Use the versions in trunk/.

That'll work. See https://jim.sh/svn/jim/vendor/vendor.txt

It does for me. After following his instructions and having the build fail, you can reproduce it with just main.o and libcairo: neurosis:~/tmp/cairo/sample$ gdb `which psp-ld` GNU gdb 6.3-debian (gdb) set args -L../src main.o -lcairo (gdb) r Starting program&a...

careful) 1) -lpsplibc <-- this is added by AmesianX..(hoho..) why? when you compile SDL library, occur errors because psplibc.. No, this is wrong. -lpsplibc and -lc never go together. The instructions in README.PSP are correct; I just tested them again. Your problem is probably because you need to ...

Make sure you're using a recent autoconf and automake. For Debian, something like Probably similar for Ubuntu.

Looks good and works great; I've applied it to rev 1124. Thanks again for your help.

CPUs have a small cache of fast on-board memory that is used to avoid accessing slower main memory when possible. The CPU takes care of writing that cache back to main memory at some unknown later time. The GU doesn't know about this cache and accesses the main memory directly, so anytime you want t...

I suggest we just get rid of the sce_fd and sceKernelStdin(), sceKernelStdout(), and sceKernelStderr() stuff completely. Those functions just return 0, 1, and 2 anyway, even if something like pspDebugInstallStderrHandler() has been called. You should get access.. every one of your patches has looked...

I also saw the black lines. I added sceKernelDcacheWritebackAll() at line 143 (before "for(;;)") and they went away.

Paste your full code at rafb.net/paste

bumper wrote:1) Any idea about my corrupted texture (black lines) ?

Flush the data cache. sceKernelDcacheWritebackAll()

2) Another question not related to the previous one, can I use malloc and free with the PSPSDK ?

Yes.

What to do with fd < 3 should probably be clarified and cleaned up a bit. Why does _close() treat them differently? That code will behave pretty badly if you can close(0) and then have open() return 0 for some other file. And if they do still refer to the "real" stdin/stdout/stderr, _fstat...