I'll let you figure this one out for a change

**V3N0M** · April 30th, 2006, 02:03

i really am amazed with the progress psmonkey and thanx for your time and knowledge using it so many people can enjoy their psp

**MonoLoco** · April 30th, 2006, 04:28

PSMonkey, are you seriously considering using the memory stick for virtual memory? I'm not sure I'd be comfortable with that...wouldn't streaming data from the memory stick frequently greatly reduce the life of the memory stick? It wasn't really meant for type of thing, right?

Ehh, maybe I don't know what I'm talking about, but I'm protective of my memory stick, it's a 1GB and I'm not planning on ever replacing it...

**PSmonkey** · April 30th, 2006, 08:26

Im not gonna do virtual memory. I'm gonna do something simular to data cache yet with tolerance. I'll have it probably load in 2-4 MB chunks for roms larger then 16MB, when a fetch is out of the cache it will get it from the memory stick. If the cache fails 2-3 times in a row then the cache will be dumped and new data will be loaded into cache.

again, it is not my consern to do this yet since most 32MB roms use more advance or custom microcodes (f3dex2). As a result wasting time on this now would yield zero results since the rsp/rdp emulation could not run the games in the first place. The only game that MIGHT work, and that is a huge one, is zelda64.

Anyway regarding monkey, i did not do much today due to time constraints. I did probe the opengl plugin that i based my hle emulation on. The plugin by default uses 4d cords (x,y,z,w). Psp only allows 3d cords. Yet for some reason when I transfer the cords to homogenious space (w = 1.0), the cordinates skew heavly (and to the same extend that they do in m64). So once I can figure this out or find a fix I should see a huge improvement in 3d.

**Wally** · April 30th, 2006, 08:37

Great! Now I see how this works..

Maybe its time to make an FAQ for those questions which are most commonly asked..

**amadeus** · April 30th, 2006, 09:02

Just had an idea about the large roms problem, I see by reading the above that a solution might be found anyway but here goes....

A large part of the 32meg etc would be textures right? How about when it tries to load a texture it gets replaced by a flat colour instead? If it could look at the texture and see the medium of all the colours use that colour. i.e say you've got a grass texture. It would see a file with light to dark green dots and shows a medium green flat colour.

Or maybe the textures in the original carts were not compressed in the most effient way and theres scope for recompressing the textures using a the jpg system etc..

Both ideas could be done at startup, the emu would scan the rom for all texture files then make a cache of the replacements.

Any just my idea, excuse it if it's rubbish but it's sunday morning and i've got a stinking hangover...

**V3N0M** · April 30th, 2006, 09:39

Hi PSmonkey just wondering about the m64 emu and the progress u have made on it (very impressed by the way.) well i was just wondering why u have your emu running in user mode instead of kernal witch i am told runs homebrew faster i know user mode will make 2.xx be able to play but just wondering why exactly? do u think u can make it run just as good? or are u going to do what yoyofr's team did and make one emu for kernal alowing it to run faster for 1.0 and 1.5 psp and then one in user mode alowing 2.xx to play anythin that makes m64 play faster and better and by the way thanx for your time and effort oh ya almost forgot do u think smash bros will work just wondering because its a great game but looking at it might have some problems with the emu well thanx

-Jman

**Kite0** · April 30th, 2006, 10:35

Though I am a couple hours/days/pages late to say this,
I would like to say that all Americans living in the Kaiserslautern American Military Communities
across the 3 major military bases here in Germany, give Psmonkey our support!!
Go Monkey!!

**Demolition49** · April 30th, 2006, 11:22

Originally Posted by amadeus

Just had an idea about the large roms problem, I see by reading the above that a solution might be found anyway but here goes....

A large part of the 32meg etc would be textures right? How about when it tries to load a texture it gets replaced by a flat colour instead? If it could look at the texture and see the medium of all the colours use that colour. i.e say you've got a grass texture. It would see a file with light to dark green dots and shows a medium green flat colour.

Or maybe the textures in the original carts were not compressed in the most effient way and theres scope for recompressing the textures using a the jpg system etc..

Both ideas could be done at startup, the emu would scan the rom for all texture files then make a cache of the replacements.

Any just my idea, excuse it if it's rubbish but it's sunday morning and i've got a stinking hangover...

It sounds like a good idea, but i THINK the problem with that would be loading time... we will have to see what monkey says...