gruso
thunderbox
Emulators on top of emulators won't work very well.*
*At all.
*At all.
I'll be more than happy. I don't even expect it.
please dont use that phrase... Gizmondo used that for their tag line.. and we all know what happened to them lolThe Pandora can do anything*, and there's no company paying you to work on an emulator or native game or system application when you'd really rather be doing another one.
* Within the confines of its hardware, obviously. It can't play Crysis.. unless EA does something crazy.
You can give it the 'impression' of playing Crysis fairly easily - VNC to a computer running Crysis, mapping the necessary keyboard commands and sending back jpegs as fast as you have bandwidth. With the speed wireless card in the Pandora you should get a fairly fluid framerate.* Within the confines of its hardware, obviously. It can't play Crysis.. unless EA does something crazy.
The issue with N64 is that for speed reasons most games don't use the MMU. So usually everything is in the same address space, which is a direct map of physical memory.and you usually have to recompile a block only once in a while.
I doubt PSP games employ self modifying or even dynamically loaded code. There's plenty of memory available for code. If it is loaded it's abstracted by the OS to the extent that you can detect it in broad strokes rather than having to check every store. This is different from the N64 which gives you raw access to the hardware and an easy interface to the cartridge.I'm guessing you'll see similar issues with PSP, as it has a similar CPU.
The issue with N64 is that for speed reasons most games don't use the MMU. So usually everything is in the same address space, which is a direct map of physical memory.[/quote]Another issue is that some N64 games are not too good about clearing the cache when they should. So N64 emulators have to detect when writes occur to blocks containing code. Strmnnrmn (schwrzkpf?) writes a bit about that here: http://strmnnrmn.blogspot.com/2007/06/trac...bug-part-2.htmlGames usually don't write to their own process (well, I heard N64 games do because of some hardware limitations but I can't comment on that"] and you usually have to recompile a block only once in a while.
It's not absolutely mandatory. The N64 game referred to wasn't issuing any instruction to clear cache even though the CPU on N64 has both instruction and data cache (whether or not it was going through the cached segments is unknown to me). It was not set associative (direct-mapped), but being only 2-way set associative on PSP only changes things so much. The game can still function if something else happens to knock the item out of instruction cache, especially if a software routine was executed for doing this intentionally. To the best of my knowledge PS1's CPU doesn't even have a direct method of clearing instruction cache lines, despite having 4KB of it.mandatory since without using it code will easily crash.
I know this fact, but do you think PSP game developers will question whether they should call an invalidate i-cache function after modifying a code section ? maybe old generations used more assembler and have their own "operating systems" but you have not a lot of choice to program in PSP, officially speaking.The game can still function if something else happens to knock the item out of instruction cache, especially if a software routine was executed for doing this intentionally.
Yes, unfortunately you have no choice BUT to roll your own on PSP since the sceKernel invalid icache calls are kernel only functions. Incidentally, the instruction for clearing cache is not privileged.I know this fact, but do you think PSP game developers will question whether they should call an invalidate i-cache function after modifying a code section ? maybe old generations used more assembler and have their own "operating systems" but you have not a lot of choice to program in PSP, officially speaking.