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