Pandora''s Emulators - What Will Work And What Won''t


No, I said it before: Emulating emulators is probably the hardest thing to do for an emulator and therefore won't work in a useful way.
Emulators usually compile the code for the original hardware for their own hardware which is then executed natively. The problem is that if you want to emulate another emulator you always have to check if the code the emulated emulator has in its cache for native execution changed and also compile it again for your host plattform (Which happens really often for emulators!).
Games 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.
Luckily enough the Pandora has a huge RAM compared to the PSP so I will hopefully be able to compile most blocks at startup for native execution and let the DSP do the rest (if possible?!) while the emulator is running if necessary (which should seldomly happen, atleast for games like I said).
For now be happy if I get SOME games running on the PSP Emulator (let them be commercial or homebrew).
 
it still blows my mind a little that emulating a new console like the psp is even possible yet. i'm really thankful for your updates to the community.

as for the list, its looking very full and mouth watering but hope the pandora can develop more away from the emulation scene and more onto specific pandora platform apps that would rock.
 
I'm hoping for that too.
Emulators will give the Pandora a huge library of fairly old games, but they'll be nothing like the gameplay [Some types of gameplay are hardware-constrained, though most people think that extra hardware is just for graphics] and visual options available to native Pandora games.

I think we should consider ourselves lucky that the Pandora is open, so that we can have both.
In a proprietary situation, you can only emulate games from your own older systems, and third-party developers have to be approved.

The 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.
 
The 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.
please dont use that phrase... Gizmondo used that for their tag line.. and we all know what happened to them lol
 
Last edited by a moderator:
* 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.

Though that's not really playing it by itself and you still need to have a beefy computer hidden behind a curtain, it sure looks impressive when you show people. I got my DS to play Crysis that way at ~2-3fps, and that was with the DS's slow 2mbit/s wireless. :D With 54mbit/s and a good signal you could get something that is almost decent.
 
Last edited by a moderator:
and you usually have to recompile a block only once in a while.
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.

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.html

I'm guessing you'll see similar issues with PSP, as it has a similar CPU.
 
Last edited by a moderator:
Neko's comment got me looking around on strmnnrmn's blog out of boredom, and I noticed this tidbit: "For what it's worth, I'm currently working on a new port of Daedalus. I'm going to keep the target platform secret for now, but I think it's very exciting." (http://strmnnrmn.blogspot.com/2008/11/yes-i-am-alive.html)
Has this already been discussed? Has it been decided that he wasn't talking about Pandora?
 
I'm guessing you'll see similar issues with PSP, as it has a similar CPU.
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.

To give you an idea of how high level PSP games are, consider that you can usually run them off of memory stick instead of UMD just by employing the right loader.

QUOTE ('wermy')
Has this already been discussed? Has it been decided that he wasn't talking about Pandora?


Has been discussed about a million times. I personally don't think he's talking about the Pandora because he hasn't had any contact with the Pandora team, but I could be wrong.
 
Last edited by a moderator:
Games 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.
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.html

I'm guessing you'll see similar issues with PSP, as it has a similar CPU.

Exosphase answers a large part. Even if PSP was using self-modified code which is very doubtful, you need to use an instruction to instruct a code change which is (1) slow and (2) mandatory since without using it code will easily crash.
 
Last edited by a moderator:
mandatory since without using it code will easily crash.
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.

It'd be strange for a game not to do it on PSP, but not really any more strange than it is on N64 where it could have been overlooked but still works correctly on accident. A recompiler will probably not be so kind since it much lower restrictions on the amount of translated code it can generate.
 
Last edited by a moderator:
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.
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.
 
Last edited by a moderator:
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.
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.

What I was more suggesting is that someone who is modifying code might have forgotten to do anything about it at all or don't realize that they have to, and they happened to have gotten away with it. Afterall, on platforms like x86 you don't have to clear cache manually since it's coherent.
 
Last edited by a moderator:
Another Amstrad emu in the works. Pasting wikicode 'cuz I'm lazy:

|-
|Caprice32
|Amstrad CPC
|[http://www.gp32x.de/board/index.php?showtopic=48140 Link1] [http://www.caprice32.cybercube.com/ Link2]
|wip
|hdonk
|

Not sure if it should be green or yellow. It's in progress, but only on Beagleboard at this stage (his Pandora is ordered).
 
Last edited by a moderator:
thanks for the heads-up gruso, I went ahead and green lighted it, beagleboard is close enough in my book. I changed the "rules" for yellow/green lighting to include beagleboard.

some of the other green lighted projects are beagleboard only at present anyways...
 
Back
Top