What emus?


in3D

Member
Joined
Apr 3, 2012
Messages
103
Location
US
I don't own a pandora yet. But I need to know, which emulators does it come with preinstalled?
 
I don't own a pandora yet. But I need to know, which emulators does it come with preinstalled?

The device does not arrive 'preinstalled' with any emulators. You would put emulators that you can find on repo.openpandora.org on SD Cards you use with the device. You can browse that site for the list of available applications.


Hope that helps. :)
 
Last edited by a moderator:
Also (if you didn't already know this) you will need and SD/SDHC card - the internal disk is full of firmware
 
OK cool. I just wanted to know because I'm going to try to start working on an emulator for the Pandora. I didn't want to make an emulator that already came preinstalled.
 
OK cool. I just wanted to know because I'm going to try to start working on an emulator for the Pandora. I didn't want to make an emulator that already came preinstalled.

Good man, what system do you plan to emulate?
 
I don't know... something easy, like the Atari 2600.
 
emu.jpg



That emu
 
:wacko: Confuzzled...


EDIT: Oh now I get it... HEY! I've never wrote an emu before! my goal is to eventually make an emu for something in the seventh gen era, though.
 
Last edited by a moderator:
You're in for a rude awakening if you think Atari 2600 is easy, just because it's the oldest and the games look the most primitive.
 
could go the easy route, take one of Exophase's emulators, compile it with a different name, than claim fame, claim its not Exo's emu, and dont show support when it doesnt run the same games Exo's emu's dont
 
This is how I think people write emulators.


1) Obtain the target hardware they are attempting to emulate


2) Disassemble it and note all the core components which are required to run the "Cartridge (or ROM image).


3) Learn about how the CPU works in the target hardware and write it in software


4) Learn how all the other components work in conjunction with the CPU and write the corresponding software which interacts with the current hardware.


5) Get it compiling and running on a new target system (such as the Pandora) and make a UI that runs that interface.


Its no simple task as everyone is saying.
 
could go the easy route, take one of Exophase's emulators, compile it with a different name, than claim fame, claim its not Exo's emu, and dont show support when it doesnt run the same games Exo's emu's dont
2725274366_5d8b23aae4.jpg



See also list of EMUs here
OK, first, I was not planning on starting from scratch. I was going to take someone's code anyway. For example, I might port Dolphin and call it Dolphin for Pandora. Second, I don't get what your talking about Binky...
 
This is how I think people write emulators.


1) Obtain the target hardware they are attempting to emulate


2) Disassemble it and note all the core components which are required to run the "Cartridge (or ROM image).


3) Learn about how the CPU works in the target hardware and write it in software


4) Learn how all the other components work in conjunction with the CPU and write the corresponding software which interacts with the current hardware.


5) Get it compiling and running on a new target system (such as the Pandora) and make a UI that runs that interface.

Rarely will disassembling a console give you very much useful information, much less enough to emulate it if nothing else is known. The most important chips will usually not be off the shelf parts with public documentation, and even if they are they'll still be using special part numbers or have their real ones etched off. In a lot of cases you'll learn a lot more about the system by reading what the company advertises about it than by looking at its PCBs.


In the vast majority of cases, when someone starts writing an emulator other people have already made information available (and/or information from the console maker has been leaked.. sometimes this information has passed around indirectly for a while so you don't really know, but probably most of the time official leaks are behind at least some initial info). So the emulator author doesn't need to do a bunch of their own reverse engineering to start writing the eight thousandth NES emulator.


Usually the information available isn't enough to get every last detail perfect, but most emulators aren't aiming for perfection. Or at least not initially. You can emulate a lot then fill in the gaps either. Sometimes that'll involve writing more tests on real hardware, but often it'll just be taking stabs based on what makes sense given the context.


When reverse engineering really does have to be done it won't just be done by emulator authors, but also by ROM hackers/homebrew authors, or people who are just interested in the console. The most important thing to start with is an ability to dump some manner of code that was written for the platform and to run new code for it. Without this it's hard to really start.


Recently more RE has been done by actually decapping processors to read embedded ROMs optically, and get die etchings to try to get a hint as to what kind of processor is running. But this is still kind of a new thing and is only attempted after all other methods have been exhausted. It's very expensive, time consuming, and error prone.

OK, first, I was not planning on starting from scratch. I was going to take someone's code anyway. For example, I might port Dolphin and call it Dolphin for Pandora. Second, I don't get what your talking about Binky...

And if you think that it'll run at anything more than a tiny tiny fraction of the proper speed (< 5%, probably < 1%) then you're in for another rude awakening..
 
OK cool. I just wanted to know because I'm going to try to start working on an emulator for the Pandora. I didn't want to make an emulator that already came preinstalled.
OK, first, I was not planning on starting from scratch. I was going to take someone's code anyway. For example, I might port Dolphin and call it Dolphin for Pandora.
Making != porting, as far as I know. ;) There's absolutely nothing wrong with porting pre-existing code, of course, but it is distinct from making something. (Do correct me if I'm wrong, please, coders - I just don't see the correlation between the terms.)
 
Well, I think there is some customization possible when it comes to porting. The source code is the most basic component of the program. So basic that you can allow it to run on tons of platforms just by putting more layers on top of the source. For example, Firefox, on Windows Vista+, has an orange button in replacement of it's window title. That couldn't be part of the source code, because it's a very windowsy component if you know what I mean.


screen-firefoxbutton.png
 
Well, I think there is some customization possible when it comes to porting. The source code is the most basic component of the program. So basic that you can allow it to run on tons of platforms just by putting more layers on top of the source. For example, Firefox, on Windows Vista+, has an orange button in replacement of it's window title. That couldn't be part of the source code, because it's a very windowsy component if you know what I mean.


screen-firefoxbutton.png

Werr? There is definitely some source code in FF that creates an orange button at the top of the window - sure it relies on a ton of windows stuff to work, but much of the code is in Firefox.


Many ports are customized, but the core functionality is left pretty much unchanged, hence its a port, not a new project.


AFAIK Programs are made to run on different platforms by A removing/replacing platform specific dependencies (libraries etc) (involves source-code tweaking) B recompiling for different hardware
 
Back
Top