|
|
Post by madcrw on Jan 21, 2008 18:19:38 GMT 1
I recently got a used Tungsten E from the local Freecycle mailing list and while I'm loving it (and LJP) I do have a question: Why is the performance of Z80-based devices (primarilly the Gameboy) so bad? I remember getting full speed GB/GBC emulation on an old Pentium 90 "way back when" and am enjoys full performance with NES games. Is the Z80 really that much more complicated that I can play even fairly complex and big NES games at full speed with sound, but am stuck at 45 FPS for Pokemon Red/Blue? I know that their's an Open Source GBC emulator for GBA (which has an even lamer ARM than my T|E) that run most games at full speed. If that could be ported to the LJP framework (maybe as part of LJX) then I suspect GBC stuff would fly...
|
|
|
|
Post by metaview on Jan 21, 2008 18:38:28 GMT 1
It's more than processor speed involved: memory access speed, speed of gfx memory for example. The GBA was made for gaming, the Tungsten E was made for appointments...
|
|
|
|
Post by _Em on Jan 21, 2008 20:37:12 GMT 1
Indeed... it is kind of like saying that a Porsche has a puny haul capacity compared to a Honda CRV. Sure they're both handheld devices, but there's a lot more that goes into building them than the form factor and the CPU.
|
|
|
|
Post by countbuggula on Jan 21, 2008 20:50:01 GMT 1
Um...I think you're confused. He's not comparing a T/E to a GBA, he's comparing NES emulation on the T/E to GB/GBC emulation on the T/E. He just added the note about playing it on his GBA as an aside, but the question is about if GB hardware is more difficult to emulate than NES hardware.
|
|
|
|
Post by _Em on Jan 21, 2008 21:14:07 GMT 1
We were responding to
However, in response to the other question: depends what you mean by "difficult to emulate". GBC is orders of magnitude easier to code than NES due to all the mappers, hardware-based timing shortcuts, etc. done on the NES. However, the NES takes less processing power than the GBC, which means FPS (which is what he seems concerned with) are easier to achieve in an NES emulator than a GBC emulator... once the actual emulation coding has been done.
In summary, it is easier to write a functional GBC emulator than a functional NES emulator... but it is easier to write a FAST NES emulator than a fast GBC emulator once the emulation itself has been accomplished.
That said, fast NES emulators are not accurate NES emulators. An accurate AND playable NES emulator is beyond the capabilities of any current handheld device.
|
|
|
|
Post by Tinnus on Jan 21, 2008 21:52:14 GMT 1
The CPU in the GBC s not that heavy though (at least not from what it seems from the emulator code, maybe it has a high clock?), and I think I used to run GBC faster than that. In any case, I might consider emulated CPU underclock for LJX, which can help a lot when a correct setting is discovered for each game  BTW, I think the implementation in LJP has some problems too. GBC runs ridiculously fast in LJX compared to, say, SMS (when I put it in turbo mode), and I did the implementation with the framework in a different fashion. Then maybe GBC is indeed fast, but something's wrong with LJP? ;D |
|
|
|
Post by metaview on Jan 21, 2008 22:12:50 GMT 1
Tinnus: only you does know...
|
|
|
|
Post by _Em on Jan 21, 2008 22:17:17 GMT 1
Hmm... do either of you have access to code profilers? I'm thinking that since the code is written in C, it should be pretty easy to use a profiler to check for obvious issues such as bad memory handling and superfluous loops.
|
|
|
|
Post by Tinnus on Jan 21, 2008 22:38:16 GMT 1
I should definately add something like that. I think it'd need microsecond precision though, and that's not in SDL, but maybe I'll just implement it for Windows since the relative performance should more or less be the same |
|
|
|
Post by Tinnus on Jan 21, 2008 22:56:20 GMT 1
Tinnus: only you does know... Numbers: GBC runs at 300FPS in turbo mode and NES runs at 200. There's a possibility though that the GBC's problem is the graphics, and that becomes small since we're frameskipping so much in turbo mode. Alas, I disabled timing completely and let them run as fast as SDL would let them. GBC: 72FPS. NES: 62FPS. I believe GBC is faster, then  |
|
|
|
Post by madcrw on Jan 21, 2008 23:45:27 GMT 1
The CPU in the GBC s not that heavy though (at least not from what it seems from the emulator code, maybe it has a high clock?), and I think I used to run GBC faster than that. In any case, I might consider emulated CPU underclock for LJX, which can help a lot when a correct setting is discovered for each game BTW, I think the implementation in LJP has some problems too. GBC runs ridiculously fast in LJX compared to, say, SMS (when I put it in turbo mode), and I did the implementation with the framework in a different fashion. Then maybe GBC is indeed fast, but something's wrong with LJP? ;D Two possible issues there: the GBZ80 had different cycle timing from (and well as a few missing opcodes) vis a vis the "stock" Z80, which SMS/GG used. Upon doing some research, it DOES look like the Z80 was a beefier chip than the 6502 (more opcodes, more complex design, some rudimentary features for accelerating 16-bit math and data transfers, etc), so it makes sense that it would need more CPU power to properly emulate... |
|
|
|
Post by Tinnus on Jan 22, 2008 1:11:23 GMT 1
The CPU in the GB is far, far simpler to emulate than a full Z80. Just download the source code and compare GB's cpu.c with SMS's or Genesis' z80.c.
BTW, SMS's Z80 ran at 3.57MHz, while GB's CPU ran at 4.19 MHz and GBC's at ~8MHz. (Wikipedia)
|
|
