Library needed for sceGeEdramSetSize?

[MDave]

Hi there, I'm trying to use this in my application to access the extra 2MB of vram for the slim psp's:

sceGeEdramSetSize(4*1024*1024);

However, it says 'undefined reference to sceGeEdramSetSize(int)' so it seems like theres a lib or something I'm missing thats not in the normal pspsdk. I've tried searching, but not luck. Any idea on how I can access this extra vram?

[MDave]

Ahh I figured it out after some trial and error. Have to start a kernal mode prx which will then start sceGeEdramSetSize(4*1024*1024); I was setting it in usermode, oops!. Wish there was more documentation on things like this :)

EDIT: Doh! Seems like I still don't have enough vram to do want I wanted. Is there an IRC channel where I could ask for help concerning my queries?

[J.F.]

I posted a version of D_A's dvemgr.prx a while back that sets the edram size to 4M when you set a TV mode.

http://forums.ps2dev.org/viewtopic.php?t=10005

But changing it when NOT using the TV could be good as well - more space for textures in the edram for stuff that wants it... like maybe SNES.

[MDave]

Yeah or better still, deadalus :P

I'm running into another issue, I want to use:

PSP_HEAP_SIZE_MAX();

instead of defining how much memory I want to use. But I get this warning during compile:

Code: Select all

module.cpp
../psp/module.cpp(29) : warning: converting negative value '-0x00000000000000001
' to 'unsigned int'

And I get a black screen (home dosn't work either). Any ideas?

[J.F.]

Yeah or better still, deadalus :P

I'm running into another issue, I want to use:

PSP_HEAP_SIZE_MAX();

instead of defining how much memory I want to use. But I get this warning during compile:

Code: Select all

module.cpp
../psp/module.cpp(29) : warning: converting negative value '-0x00000000000000001
' to 'unsigned int'

And I get a black screen (home dosn't work either). Any ideas?

MAX rarely works for most homebrew (it's a rather useless value, IMHO). It doesn't leave enough memory for anything to be done. If you create a thread - there you go - not enough memory left for the stack for the new thread. The warning is because MAX is just -1 which in the new system means leave 1KB free (it used to mean leave 0KB free). Try PSP_HEAP_SIZE_KB(-1024) - that leaves 1MB free for the PSP to use, allocating all the rest to the heap. If you don't need to leave that much free, experiment with smaller values (-256 for example). The point is that negative values tell how much to leave the PSP, while positive values still mean how much to take from the PSP.

[Pirata Nervo]

Setting the HEAP does not work for me.
I always get errors when reading my configuration files.

Only:
PSP_HEAP_SIZE_MAX();
works or not even set the heap.

what should I do? set to max or dont set it?

[J.F.]

Setting the HEAP does not work for me.
I always get errors when reading my configuration files.

Only:
PSP_HEAP_SIZE_MAX();
works or not even set the heap.

what should I do? set to max or dont set it?

What are you working on? An app or a plugin? Are you using an up-to-date toolchain? The changes for negative heap size specification was to newlib, not the pspsdk libc. If you specifically use that libc (or the kernel libc), you don't get that functionality.

[jimparis]

Code: Select all

module.cpp
../psp/module.cpp(29) : warning: converting negative value '-0x00000000000000001
' to 'unsigned int'

Seems this variable was left unsigned when the semantics were changed to support negative values... I've made it signed in rev 2399.

[Pirata Nervo]

Setting the HEAP does not work for me.
I always get errors when reading my configuration files.

Only:
PSP_HEAP_SIZE_MAX();
works or not even set the heap.

what should I do? set to max or dont set it?

What are you working on? An app or a plugin? Are you using an up-to-date toolchain? The changes for negative heap size specification was to newlib, not the pspsdk libc. If you specifically use that libc (or the kernel libc), you don't get that functionality.

I am working on NervOS 2.1, it's a shell.
I don't use kernel libs/libc.
but I have the same problem if I set the heap to positive, only works on setting to max or not setting it :/

[J.F.]

Setting the HEAP does not work for me.
I always get errors when reading my configuration files.

Only:
PSP_HEAP_SIZE_MAX();
works or not even set the heap.

what should I do? set to max or dont set it?

What are you working on? An app or a plugin? Are you using an up-to-date toolchain? The changes for negative heap size specification was to newlib, not the pspsdk libc. If you specifically use that libc (or the kernel libc), you don't get that functionality.

I am working on NervOS 2.1, it's a shell.
I don't use kernel libs/libc.
but I have the same problem if I set the heap to positive, only works on setting to max or not setting it :/

Is the thing compiled as a PRX? PRXs use 64K as the heap if you don't set the heap size.

[Pirata Nervo]

I set BUILD_PRX = 1 if I set the heap

[J.F.]

I set BUILD_PRX = 1 if I set the heap

BUILD_PRX = 1 -> 64K if not specified
BUILD_PRX not set -> same as MAX if not specified

Might be why those two do the same thing for you. :)

If you don't use newlib, you can't use negative heap sizes. Sounds like you're not using newlib, and your guesses for how big to make the (positive) heap size were wrong. That's why we made the change to newlib - it took lots of trial and error to guess the heap size to use with apps: too small and you run out of heap - too big and you don't get a heap to begin with. Then you also need to do the same guesswork on the slim since it has a different amount of memory. I spent a FULL DAY doing nothing but trying different heap sizes when me and Capt Shoe did the Slim version of SNES9xTYLme++. By allowing the negative heap size in newlib, the only guess you need is how much to leave for other threads, which isn't as critical as the other way around.

[Pirata Nervo]

Thanks I will change my code later.
So I set BUILD_PRX = 0 and the HEAP to -1024?
I am using newlib, I use Linux and installed newlib when I set up the toolchain 3 weeks ago again.

[Insert_witty_name]

BUILD_PRX = 1
PSP_HEAP_SIZE_KB(-1024)

[MDave]

Thanks for the help.

I have a few more problems. Even though I set the heap size to something like 40MB, it still seems like my application is limited to using a smaller set of memory. In other words, I'm still running out of texture space to store in RAM as if I was on a normal PSP. Do I need to unlock the extra RAM using some sce function?

Also, here is another problem:

Code: Select all

// the lightmap texture data needs to be kept in
// main memory so texsubimage can update properly
byte		lightmaps[LIGHTMAP_BYTES*MAX_LIGHTMAPS*BLOCK_WIDTH*BLOCK_HEIGHT];

If the total data in the byte goes over about 1835008 bytes, I get a black screen. Equal or under that number is a ok. Now if I had the extra slim memory available, I'm pretty sure I wouldn't get the black screen.

What I'm basically trying to do is get colored lighting working in Quake for the psp, but I need to allocate extra lightmap bytes for the extra color information :P

[sakya]

Hi! :)

Do I need to unlock the extra RAM using some sce function?

Add

Code: Select all

PSP_LARGE_MEMORY=1

to your makefile. ;)

Ciaooo
Sakya

[Pirata Nervo]

@IWN, yeh I already did that but never works :/

[MDave]

@sakya

Using that in my makefile seems to make no difference :(

[sakya]

Hi! :)

Using that in my makefile seems to make no difference :(

I don't know, sorry, but the 3.71 sdk's sample says:

Code: Select all

Use PSP_LARGE_MEMORY = 1 in the makefile  and the size of user memory will become of 52 MB.
This requires an up to date pspsdk, revision 2333 (Novemeber, 1) or newer.

There's a sample in the 3.71 sdk on how to use the extra ram, give it a look (I never used the extra ram, since I don't have a slim). ;)

EDIT: did you try to use malloc?

Ciaooo
Sakya

[MDave]

Ahh thanks sakya.

However, I'm having trouble with the sample I compile for my slim psp, it fails all the memory tests, but the sample eboot thats there already has no problem. What is the correct way to install the sdk supplied with the 3.71 M33 - 3 update? Placing them in my \pspdev\psp\sdk folder dosn't seem to be it.

I didn't think I would need to use the M33 sdk to access the extra RAM :(

And yes, my pspsdk revision is up to date! :(

[Pirata Nervo]

why dont you install the 4.0.1 sdk? (it has more functions and updated NIDs)
and yes placing them there is the irght way or you can add the path yo your INCDIR and LIBDIR in your makefile to the 3.71 sdk folder

[J.F.]

Compile the ram test D_A made. If it doesn't work, your toolchain isn't up to date, no matter what you think. If it works, then you're doing something wrong in the app. But FIRST compile that test to make sure you really do have the proper toolchain.

[MDave]

Ok, just did a full clean re-install of the latest cygwin and toolchain.
Still the same results.

It compiles fine without errors or warnings, and the ramtest does say it has about 50MB free and max free, yet it still fails on all the tests. I do notice my eboot is half the size of the one that comes with the ramtest.

Can anyone confirm if they're getting the same?

[J.F.]

Works fine on everything I try... double check your project. The makefile MUST HAVE

Code: Select all

PSP_LARGE_MEMORY=1
BUILD_PRX =1

and the main file should have the heap set somehow

Code: Select all

PSP_HEAP_SIZE_KB(-256);
PSP_HEAP_SIZE_KB(40000);
PSP_HEAP_SIZE_MAX();

[MDave]

I havn't touched the main.c and makefile for the ramtest.
I'm at a loss as to why it dosn't work. I know cygwin isn't the most stable when it comes to building the toolchain. It failed up to running the psplinkusb.sh script, but I don't need to worry about that for the moment.

Isn't installing the required dependencies enough during the toolchain install (the ones listed in psptoolchain\depends)? Is there something else I need?

[J.F.]

I havn't touched the main.c and makefile for the ramtest.
I'm at a loss as to why it dosn't work. I know cygwin isn't the most stable when it comes to building the toolchain. It failed up to running the psplinkusb.sh script, but I don't need to worry about that for the moment.

Isn't installing the required dependencies enough during the toolchain install (the ones listed in psptoolchain\depends)? Is there something else I need?

Well, you also need the includes and libs included with SDK in the latest custom firmware releases... like where the ramtest sample is.

Try using Heimdall's pre-built Windows toolchain. I know many people have trouble getting cygwin to work for them. I work from linux, so that could very well be your problem.

http://forums.ps2dev.org/viewtopic.php?t=9812

[whistler]

Ok, just did a full clean re-install of the latest cygwin and toolchain.
Still the same results.

It compiles fine without errors or warnings, and the ramtest does say it has about 50MB free and max free, yet it still fails on all the tests. I do notice my eboot is half the size of the one that comes with the ramtest.

Can anyone confirm if they're getting the same?

that error your getting is what happens when newlib isn't up to date. are you sure you installed the latest toolchain from svn

svn checkout svn://svn.ps2dev.org/psp/trunk/psptoolchain

[MDave]

Thanks for the help so far. But Heimdall's pre-built Windows toolchain produces the same result. :(

Yeah I'm positive I have installed the latest toolchain, using that command my revision checks out at 2399. But I've noticed something about the toolchain. It downloads and installs newlib 1.15.0 instead of the latest 1.16.0 ? Is that the cause of the problem? I'm guessing not though.

[MDave]

Ok, discovered the problem!

It happens to be related to my windows enivornment settings, there was a path looking at an old version of a pspdev folder on one of my other drives. Removing the path from the environement variables and removing the old pspdev folder solved the problem. This is handy info for others having the same problems I had! Need a FAQ sticky covering most people's compile problems :)

Thanks for all the help, much appreciated.

[J.F.]

Ok, discovered the problem!

It happens to be related to my windows enivornment settings, there was a path looking at an old version of a pspdev folder on one of my other drives. Removing the path from the environement variables and removing the old pspdev folder solved the problem. This is handy info for others having the same problems I had! Need a FAQ sticky covering most people's compile problems :)

Thanks for all the help, much appreciated.

Okay, that was something we probably wouldn't have guessed. How many people run multiple versions of the same toolchain on the same system? :)

At least you found the problem.