| View previous topic :: View next topic |
| Author |
Message |
Coldbird
Joined: 08 Feb 2007
Posts: 155
|
 Posted: Tue Mar 23, 2010 3:17 am Post subject: How to control heap allocation. |
 |
|
Im trying to control the heap allocation of umd games.
Every umd game executeable (EBOOT.BIN) allocates 23MB of userspace as its heap... this leaves only 1MB for use with other usermode applications which isn't enough for my needs.
Thus I want to code a plugin that controls the maximum ammount of heap a game can allocate.
Does anyone of you guys have a idea how I could do this?
_________________
Been gone for some time. Now I'm back. Someone mind getting me up-2-date? |
|
| Back to top |
|
 |
Alberto
Joined: 12 Feb 2007
Posts: 57
Location: Sofia
|
| Posted: Tue Mar 23, 2010 5:07 am Post subject: Re: How to control heap allocation. |
|
|
| Coldbird wrote: | Im trying to control the heap allocation of umd games.
Every umd game executeable (EBOOT.BIN) allocates 23MB of userspace as its heap... this leaves only 1MB for use with other usermode applications which isn't enough for my needs.
Thus I want to code a plugin that controls the maximum ammount of heap a game can allocate.
Does anyone of you guys have a idea how I could do this? |
don't know if what I'm going to say is a big bull****, but how about:
I guess you need this because you're willing to run your plugin in automatic "game" mode...
a) load your plugin _before_ running the game, so that it takes the memory it needs, leaving the rest for the game (I guess it will not complain...)
or
1) load bulk plugin that just allocates the memory you'll need, and maybe a bit more ;-)
2) run the UMD game (this will also fire your plugin loading event)
3) exit the bulk plugin and load the real one (that is, have it exit once it detects your real plugin is loaded, and leave the memory for you)
Just my 2c
note1:
I pretend not knowing _more_ than you in first instance (although I'm not new to C, I am to PSP env.)
note2:
I have no clue at all about how to implement even a single statement of the above, but my imagination tells me that somehow this can be done.
Cheers, A. |
|
| Back to top |
|
|
Coldbird
Joined: 08 Feb 2007
Posts: 155
|
| Posted: Wed Mar 24, 2010 4:34 am Post subject: |
|
|
Not bullshit but... its what I tried already... and it didn't work out, the system works a bit differently... sadly... :(
_________________
Been gone for some time. Now I'm back. Someone mind getting me up-2-date? |
|
| Back to top |
|
|
m0skit0
Joined: 02 Jun 2009
Posts: 226
|
| Posted: Wed Mar 24, 2010 5:02 am Post subject: |
|
|
I don't think you can. If the game expects 23 MB, I guess all its code is prepared for that, thus it will either crash or behave strangely if it doesn't get that amount of memory.
_________________
| The Incredible Bill Gates wrote: | | The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers. |
|
|
| Back to top |
|
|
Alberto
Joined: 12 Feb 2007
Posts: 57
Location: Sofia
|
| Posted: Wed Mar 24, 2010 6:46 am Post subject: |
|
|
| Coldbird wrote: | | Not bullshit but... its what I tried already... |
I supposed... ;-)
| Coldbird wrote: | | and it didn't work out, the system works a bit differently... sadly... :( |
Have no idea, so... but having read also other posts, then, seems the game actually _wants_ all those 23MB of free memory, so I yhink you're left with no chance...
Of course it could be only a check (if-I-cannot-get-exactly-23MB-then-abort...) because... well... why exactly 23 and not 25??? and then patching the EBOOT somehow, just to leave one more meg for you, could solve the thing, poosibly with no hassle.
But... do you really need more than one meg o memory? Can't you really deal with smaller chunks a time? (just a guess).
Cheers, A. |
|
| Back to top |
|
|
Jim
Joined: 02 Jul 2005
Posts: 487
Location: Sydney
|
| Posted: Wed Mar 24, 2010 9:29 pm Post subject: |
|
|
Sony must promise the game developers a minimum amount of user memory - even with the latest FW loaded there must still be as much memory left today as there was with FW1.0 else some of the older games won't work. I'd guess a lot of games just take that amount (is it 23Mb?) and assume it exists.
I suspect you'd only be able to persuade a small percentage of games they weren't running with that assumed memory availability.
Jim
_________________
http://www.dbfinteractive.com |
|
| Back to top |
|
|
SilverSpring
Joined: 27 Feb 2007
Posts: 115
|
| Posted: Thu Mar 25, 2010 3:28 pm Post subject: |
|
|
Hook the sceKernelAllocPartitionMemory function.
The prototype is:
SceUID sceKernelAllocPartitionMemory(SceUID partitionid, const char *name, int type, SceSize size, void *addr);
Check for when name is "UserSbrk" and modify the size arg (in bytes) for that case.
However, the game might crash if it doesn't have enough mem.
_________________
PSP PRX LibDocs |
|
| Back to top |
|
|
Coldbird
Joined: 08 Feb 2007
Posts: 155
|
| Posted: Sun Mar 28, 2010 9:51 pm Post subject: |
|
|
Oh hi Silverspring. Long time no see, you should log into MSN more often.
That aside, I already tried that myself... I was able to catch that particular allocation myself... but it seems to only allocate 100kb... not 23mb of memory or anything close to it. :(
_________________
Been gone for some time. Now I'm back. Someone mind getting me up-2-date? |
|
| Back to top |
|
|
Coldbird
Joined: 08 Feb 2007
Posts: 155
|
| Posted: Tue Mar 30, 2010 2:25 am Post subject: |
|
|
| Code: | uAllocPartitionMemory(2, UserSbrk, 3, 21372928, 1000) //Dungeon Siege
uAllocPartitionMemory(2, UserSbrk, 3, 102400, 1000) //Warriors Orochi 2
uAllocPartitionMemory(2, UserSbrk, 3, 102400, 1000) //Dantes Inferno
uAllocPartitionMemory(2, block, 0, 65536, 0) //Edecrypt 1.3.1 (Homebrew) |
I've logged some data for comparison... you guys see what I mean now?
Dungeon Siege allocates a big bunch... while Warriors Orochi 2, Dantes Inferno, etc... allocates nearly nothing...
In comparison to it all, I also logged a homebrew sdk created app...
What I'm wondering about however is the type flag... on homebrew sdk its zero while on sony sdk stuff its 3... the homebrew sdk documentation only covers types 0-2......
_________________
Been gone for some time. Now I'm back. Someone mind getting me up-2-date? |
|
| Back to top |
|
|
SilverSpring
Joined: 27 Feb 2007
Posts: 115
|
| Posted: Tue Mar 30, 2010 4:26 pm Post subject: |
|
|
The type flag has been expanded in later fw that's why PSPSDK only has 0-2 (it's based off 1.50 SDK). Type 3 is the same as 0 except it is aligned with the last arg specifying the alignment value. Type 4 is the same as 1 but again with alignment.
Btw, the last arg you have listed as 1000, it should be 0x1000.
_________________
PSP PRX LibDocs |
|
| Back to top |
|
|
Coldbird
Joined: 08 Feb 2007
Posts: 155
|
| Posted: Tue Mar 30, 2010 10:08 pm Post subject: |
|
|
I know, its because I logged the data using %p formatting.
I already thought it would be some alignment related thing... exactly 0x1000 made me kinda curious... thanks for clearing this up.
But I still have the problem with lack of memory...
In fact I am that desperate for more memory, that I thought of utilizing the slim-only memory...
But afaik it's used as kernel memory (in normal umd game mode atleast) and I need to free this memory in a way it gets added to the user memory pool...
(So the total memory calls return about 50mb instead of 24...)
Sadly I have no idea how I'm ment to do that, it must be possible somehow however as the official sony sdk added a SFO flag afterall to add the extra memory to the user pool...
Silverspring, you don't have a idea how I can do that do you?
_________________
Been gone for some time. Now I'm back. Someone mind getting me up-2-date? |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
