search

EmulatorArchive / jpcsp

Automatically exported from code.google.com/p/jpcsp
1 stars 0 forks source link

Need ~450k more mem #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Some applications try to allocate more memory than available.

Final Fantasy VII - Crisis Core:

http://www.jpcsp.org/forum/viewtopic.php?f=9&t=151&p=1722#p1722

28281 [Emu] DEBUG hle - sceKernelCreateFpl(name=SQEX memory 
pool,partition=2,attr=0x0,blocksize=0x1520000,blocks=1,opt=0x9ffba04)
28281 [Emu] WARN  hle - UNIMPLEMENTED:sceKernelCreateFpl option at 
0x9ffba04 (size=8)
28281 [Emu] INFO  hle - sceKernelAllocateFpl
(uid=0x1008,data=0x9ffba00,timeout=0x0)
28281 [Emu] WARN  hle - tryAllocateFpl not enough free mem 
(want=22151168,free=21718288,diff=432880)

Original issue reported on code.google.com by gi...@web.de on 10 Dec 2008 at 7:55

GoogleCodeExporter commented 9 years ago 
Prince of Persia
want=731135,free=380800,diff=350335

R-Type Command
want=19490816,free=19230656,diff=260160

See also:
http://www.jpcsp.org/forum/viewtopic.php?p=1065#p1065

Original comment by pfft.wha...@gmail.com on 10 Dec 2008 at 6:23

GoogleCodeExporter commented 9 years ago

Original comment by pfft.wha...@gmail.com on 15 Dec 2008 at 8:22

GoogleCodeExporter commented 9 years ago 
The affected games may show different behaviour under r854, where the FPL
implementation was changed to reserve memory in sceKernelCreateFpl instead of
sceKernelAllocateFpl.

The game Pipe Mania ULES01094 http://jpcsp.org/forum/viewtopic.php?f=9&t=515 
appears
to be using sceKernelCreateFpl as a way of measuring the amount of free memory
instead of sceKernelMaxFreeMemSize... The developer has since gone bust.

Original comment by pfft.wha...@gmail.com on 4 Jan 2009 at 2:29

GoogleCodeExporter commented 9 years ago 
Changed VPL implementation r866, same fix as for FPL.

Final Fantasy VII - Crisis Core confirmed as still broken
http://jpcsp.org/forum/viewtopic.php?p=2239#p2239

Original comment by pfft.wha...@gmail.com on 8 Jan 2009 at 10:39

GoogleCodeExporter commented 9 years ago 
The Fast and the Furious -
http://www.jpcsp.org/forum/viewtopic.php?f=28&t=2076&p=5172#p5172

Unsupported syscall 3001 sceKernelSetCompiledSdkVersion 02080010 09fffe00 
02080000
Unsupported syscall 3002 sceKernelSetCompilerVersion 00030306 00030000 02080000
sceKernelCreateFpl(name='GameHeap',partition=2,attr=0x0,blocksize=0x1382b24,bloc
ks=1,opt=0x0)
tryCreateFpl not enough free mem (want=20458276,free=20103612,diff=354664)
sceKernelAllocateFpl unknown uid=0x80020190
IGNORED: write32 - Invalid memory address : 0xFFFFFFFF PC=08A377B4

Original comment by gi...@web.de on 29 Apr 2009 at 8:22

GoogleCodeExporter commented 9 years ago 
He wasn't using "Disable reserved thread memory".

Original comment by pfft.wha...@gmail.com on 29 Apr 2009 at 8:41

GoogleCodeExporter commented 9 years ago 
Moving this from High to Medium since we're not seeing this happening much 
recently.
The whole thing is probably related to fragmentation of high memory caused by 
the way
the firmware works.

It's also related to SysMem free() implementation. Some homebrew partitions the
largest free block of memory for malloc(). Then continues to try and create 
threads.
This may succeed if the 256k root thread stack is freed after the call to 
partition
the memory.

Original comment by pfft.wha...@gmail.com on 27 May 2009 at 9:00

GoogleCodeExporter commented 9 years ago 
r1519:

Improved PSP memory management to reflect the behavior on the real PSP:
- area reserved at program startup
- memory is allocated in 256-bytes chunks
- stack size for the root thread
- sceKernalCreateThread: check successful stack allocation
Added a test application to verify these settings on a real PSP.

This change should make the compatibility option "Disable reserved thread 
memory"
obsolete.

Original comment by gi...@web.de on 29 May 2010 at 5:46