skeezix
Internal Development
Its simple.
An emu is a software system emulating hardware; ie: A _PC_ based emu is usually intel x86 arch.. so its a piece of C code written for intel to support ARM virtual processor, as well as the other cusotm chips and effects in the target system.
Now, if you're actually running on an ARM processor it _may_ not be fully necessary to emulate every little bit.. ie: ARM on x86 coudl sometimes be different than ARM on ARM .. you may be able to skip some of that.
A _port_ is just getting the C code for the emu (Written to be portable, and thus run on x86 and everything else); but as you can see, if you change it, or write it from scratch you can potentially leverage the native processor better.
Consider this angle..
A good full software emu dopes everythign in software, and thus is maximumly portable; but a SNES and GBA can do sprite rotation in hardware, so you emulate it in software.. well and good, and slow on slow machines. But if your native hardware (video card etc) can do rotation, why not emulate that in hardware.. nice and fast. So an emu ideally is written in pure software (max portability), and when brought to a given arch some components can be swapped out to better use the native platform (use hardware scaling say).
This is why a 'basic port' of an emu usually sucks -- its interface is not native feeling, or may be very clumsy; but a port where the author localizes with sweat and blood, it'll be better.. might be the same code, but localized.
Thats why 'recompiling to make it faster' is rediculous; if life were that easy, we wouldn't need developers.
jeff
An emu is a software system emulating hardware; ie: A _PC_ based emu is usually intel x86 arch.. so its a piece of C code written for intel to support ARM virtual processor, as well as the other cusotm chips and effects in the target system.
Now, if you're actually running on an ARM processor it _may_ not be fully necessary to emulate every little bit.. ie: ARM on x86 coudl sometimes be different than ARM on ARM .. you may be able to skip some of that.
A _port_ is just getting the C code for the emu (Written to be portable, and thus run on x86 and everything else); but as you can see, if you change it, or write it from scratch you can potentially leverage the native processor better.
Consider this angle..
A good full software emu dopes everythign in software, and thus is maximumly portable; but a SNES and GBA can do sprite rotation in hardware, so you emulate it in software.. well and good, and slow on slow machines. But if your native hardware (video card etc) can do rotation, why not emulate that in hardware.. nice and fast. So an emu ideally is written in pure software (max portability), and when brought to a given arch some components can be swapped out to better use the native platform (use hardware scaling say).
This is why a 'basic port' of an emu usually sucks -- its interface is not native feeling, or may be very clumsy; but a port where the author localizes with sweat and blood, it'll be better.. might be the same code, but localized.
Thats why 'recompiling to make it faster' is rediculous; if life were that easy, we wouldn't need developers.
jeff