Virtual memory on psp need help !!!!

[pspd3vil]

Hi i would like to create a malloc the wouldn't use the ram, but instead uses a .bin in the MS like an mmu-page.

because I want to port emulators such as mame or neogeo cartridge i've already ported this emu's but now i need a lot of memory i already play with the cps1 system an some roms Neogeo MVS of 6Mb zipped .

can anyone help ?


Thx

[ReKleSS]

Somehow, I don't think this is going to work. The psp has no MMU. I can't think of any feasible way to fake one...
-ReK

[Dr. Vegetable]

...And don't forget that using flash for virtual memory will tend to wear it out more quickly. A typical flash memory location can only be written to about one million times before it wears out. If you publish software that does a lot of writing to flash, you should post a warning to the user that it may shorten the life of the memory card.

By the way, there is a company now (Max?) that sells a 4 gigabyte hard drive that plugs into the memory slot on the PSP. The drive itself is mounted inside an "ergonomic" bump that snaps onto the underside of the PSP. This uses more power than a memory stick, but it is cheaper per megabyte and can be re-written many more times. Something to consider. (And no, I don't work for them or have any financial stake in the company.)

EDIT:
You can do this kind of thing without dedicated MMU hardware, but you would have to use handles instead of pointers. Your allocation routine would return an integer that identifies the memory block to the memory management system. To use the memory, you pass the handle to a "lock" routine, which finds space in RAM and copies the memory block in from VM (if it is not already resident) before incrementing a lock count and returning an actual pointer to the buffer in RAM. When you are done accessing the memory, you pass the handle to an "unlock" routine, which would decrement the lock count for that buffer. When the memory manager needs more RAM to lock a buffer, it can reclaim the RAM used by any handle whose lock count is zero simply by copying the block back into virtual (aka flash) memory.

It sounds ugly, but it's really not that bad:

Code: Select all

// Rough pseudocode compiled only in my cranium...
typedef unsigned int HANDLE;

HANDLE VirtualAlloc(size_t bytesToAllocate);
void* VirtualLock(HANDLE handleToLock);
void VirtualUnlock(HANDLE handleToUnlock);
void VirtualFree(HANDLE handleToFree);

HANDLE h = VirtualAlloc(sizeof(someStruct));
someStruct* p = (someStruct*)VirtualLock(h);
if (p != NULL)
{
     // Access the structure using pointer 'p' here...

     // ...When finished using the structure:
     VirtualUnlock(h);
}

VirtualFree(h);

Actually writing the guts of the four Virtual****() functions is left as an exercise for the reader.

[mrbrown]

...And don't forget that using flash for virtual memory will tend to wear it out more quickly. A typical flash memory location can only be written to about one million times before it wears out. If you publish software that does a lot of writing to flash, you should post a warning to the user that it may shorten the life of the memory card.

He's talking about paging in ROMs, so he doesn't need to flush discarded pages if they never would change. Virtual memory doesn't always equal a "page file", Dr. Windows Guy... Anyway, typically on consoles virtual memory is used to make what would normally be heap allocations contiguous. There's a good chapter on the subject (dealing with arrays) in GPG4.

Not that it does the PSP any good, as there's no conventional MMU.

[Dr. Vegetable]

Yeah, I realized that he is talking about paging in ROMs which is a different story altogether. The way the question was framed, I thought he was simply looking to allocate more memory than the PSP physically has.

Yikes - I guess 18 years as a Windows programmer have warped my mind. I just didn't realize it was that obvious! How's this:

Code: Select all

/* rough pseudocode compiled only in my micro$oft-addled cranium... */
typedef unsigned int COOKIE; 

COOKIE virtual_memory_allocate(size_t number_of_bytes); 
void* virtual_memory_lock(COOKIE cookie_to_lock); 
void* virtual_memory_lock_read_only(COOKIE cookie_to_lock); 
void virtual_memory_unlock(COOKIE cookie_crumb); 
void virtual_memory_free(COOKIE cookie_gone_stale); 

COOKIE monster = virtual_memory_allocate(sizeof(someStruct)); 
someStruct* p = (someStruct*)virtual_memory_lock_read_only(monster); 
if (p) 
{ 
     /* access the structure using pointer 'p' here...  */

     /* ...when finished using the structure: */
     virtual_memory_unlock(monster);
     /* NOTE: since 'monster' was only locked "read only", it doesn't
         need to be paged back to flash. */
} 

virtual_memory_free(monster); 

/*  ;-)  */

(This doesn't really solve his original problem, either. I should just crawl back into my Windows box and shut up.)

But if he's emulating another console, couldn't he also emulate an MMU? I'm not saying it would be fast, but at least possible?

[AnonymousTipster]

Is it actually feasible to write to the memory stick this often? When saving a 480x272 sized image, it takes about 6+ seconds, which makes using the standard fopen() functions unusable, because they are too slow. Is there a faster way to write to the memory stick, in order to swap files above 1mb in under a second?
Reading a file seems fast enough, but writing seems very slow.

[pspd3vil]

Hi thanks for all answer but i've found teh user manual for Mips R4000 and R4400 and on it you can see all info about the MMU , virtual addr ,virtual memory ,ect..... .

Now i need to understand why a psp cant use it thank's .

you can get it here :

http://cag.csail.mit.edu/raw/documents/ ... ok_Ed2.pdf

[mrbrown]

Hi thanks for all answer but i've found teh user manual for Mips R4000 and R4400 and on it you can see all info about the MMU , virtual addr ,virtual memory ,ect..... .

The PSP's ALLEGREX CPU is not a R4000. You have Sony marketing drones to thank for the confusion. The ALLEGREX does not have a MMU, but instead has some freakish memory mapping hardware that doesn't allow you to do virtual memory. All in the interest of saving silicon, I suppose.

[pspd3vil]

Thx mrbrown and bad new :( .

[siso]

Hi, but the project is dead? The cps1 system is very good!!!!

[sherpya]

does psp have mmap ? then a large file can be used as read/write operation as in real memory

[groepaz]

and without a MMU mmap would work how? o_O

[sherpya]

and without a MMU mmap would work how? o_O

dunno maybe an ugly emulation ? :)

[siso]

Why? The cps1 has more interesting games

[Sharkus]

Couldn't you "emulate" read only virtual memory (i.e. ROMS) with the following:

- Create a memory pool outside of the PSP address space
- Create an exception handler for bus errors (data)
- When this area is accessed, an exception will occur, the exception handler looks at the badvaddr, pulls the value from a cache in ram (or mem stick if location is not currently cached in memory), loads the value into the appropriate register, jumps back to main code

This of course would cause an exception to happen for each memory access.

-Sharkus

[BlackDiamond]

End then you'll need to use kernel mode and say goodbye to 2.00+ psps. I don't really care myself, but a lot of people do and it's something to consider if you like you're emulator to be 'popular'.

[TyRaNiD]

Not even considering how truely awful the performace would be :)

[Gary13579]

Is it actually feasible to write to the memory stick this often? When saving a 480x272 sized image, it takes about 6+ seconds, which makes using the standard fopen() functions unusable, because they are too slow. Is there a faster way to write to the memory stick, in order to swap files above 1mb in under a second?
Reading a file seems fast enough, but writing seems very slow.

I know it's a bit late...
but tests have shown that the sceIoOpen, sceIoWrite, and sceIoClose functions are faster then the fopen/fwrite/fclose functions.