What determines whether an emulator is "fast" or "slow"?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

ArsonIzer
Posts: 115
Joined: Fri Jul 19, 2013 11:38 am

What determines whether an emulator is "fast" or "slow"?

Post by ArsonIzer » Sun Sep 15, 2013 1:52 am

I've looked through the sources of emulators, and some of them say stuff like:

- PPU uses scanline-based rendering, very fast

or

- Cycle-precision CPU, very slow

I get the terminology of scanline-based rendering and cycle-precision and whatnot, but how is one able to determine whether his emulator is fast or slow? Is there a certain time frame in which a CPU needs to execute, let's say, 100k cycles, which decides whether it's fast or slow? For instance, and these are completely random numbers, if a CPU takes less than 50 ms to execute said amount of cycles, it's fast, 50 - 70 it's ok, and above 70 ms is slow? Or is this just based on a programmer's intuition?

tepples
Posts: 22013
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: What determines whether an emulator is "fast" or "slow"?

Post by tepples » Sun Sep 15, 2013 5:33 am

Video game console emulation is a soft real-time application. A "fast enough" emulator can reliably finish 60 frames of CPU and PPU time in one second on the target platform. An emulator supporting fast-forward is "fast enough" when it can hit 240 fps, possibly with skipping some PPU output stages for undisplayed frames. You gave an example of your CPU executing 100K emulated cycles. On the NES, that's about 55 ms worth of cycles. Your emulator needs to execute those cycles within 55 ms, plus the PPU and APU activity that goes along with them.

If your emulator is designed for a PC running Windows or GNU/Linux, it needs to run at 60 fps on the slowest machine that meets the current Windows version's system requirements. Since Windows 7 was released in the fourth quarter of 2009, this has meant a 1 GHz Pentium 4 or Atom. (This reflects Windows 7's use on netbooks and Windows 8's use on x86 tablets.) FCEUX does; few other popular emulators do. An emulator that emulates multiple machines at once, such as nemulator's Wii-inspired menu, has to be even faster, but multi-core machines alleviate this somewhat because emulating multiple machines is an embarrassingly parallel workload.

If your emulator is designed for a device running Android OS, it needs to run at 60 fps on that device. Faster is better because whatever CPU cycles your emulator doesn't use now can be used for making urgent telephone calls later.

ArsonIzer
Posts: 115
Joined: Fri Jul 19, 2013 11:38 am

Re: What determines whether an emulator is "fast" or "slow"?

Post by ArsonIzer » Sun Sep 15, 2013 6:48 am

Wow, that's almost embarrassing. My CPU is much less efficient than that. That 100K thing was just a random number, but mine is nowhere near it, and I'm not even halfway done with my PPU (let alone the APU). Then again, it's written in Java with a ton of object overhead and it's so focused on readability that I can fully understand its slowness. Thanks for the response, your explanation sounds pretty logical.

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Re: What determines whether an emulator is "fast" or "slow"?

Post by MottZilla » Sun Sep 15, 2013 3:20 pm

Maybe a more simple way to put it, a fast emulator is efficient in how is calculates and processes everything it needs to do to avoid wasting CPU time. As well as just how much it needs to process. For example your emulator would be much faster emulating games if it did so by being less accurate. For example it's faster to just draw the nametables at their scrolled position all at once at the end of the frame. This will work for simple games too.

I think alot of what causes extra processing load in a NES emulator is CPU and PPU synchronization. Ofcourse a modern PC has a huge amount cache but on older PC's the cpu had much smaller cache so code size would be more of a concern I believe. The point is that lets saw you emulator one CPU cycle, or CPU instruction, and then catch up the PPU. You'll be constantly shifting between your CPU and PPU cores which causes alot of overhead. To avoid losing accuracy some people use catch-up type methods. With a catch-up method you save on overhead since you only switch between the CPU and PPU cores when you really have to do so. The main reason you'll have to I believe is $2002 register reads for sprite zero or other flag detection. Otherwise you can log PPU register writes/states for rendering later I believe. But this adds complexity to your emulator.

You have to look at what platform you are going to be on and then decide what's important. You may not need to optimize performance much or at all. As long as you don't make any errors, a modern PC CPU is going to be sufficient for a high degree of accuracy and 60fps. Newer systems ofcourse probably need optimizations.

If it's your first emulator, just focus on maintainable code, and getting things working.

User avatar
fergus_maximus
Posts: 38
Joined: Sun Jul 29, 2012 10:13 am
Location: Chicago, IL
Contact:

Re: What determines whether an emulator is "fast" or "slow"?

Post by fergus_maximus » Sun Sep 15, 2013 5:41 pm

MottZilla wrote: You have to look at what platform you are going to be on and then decide what's important. You may not need to optimize performance much or at all. As long as you don't make any errors, a modern PC CPU is going to be sufficient for a high degree of accuracy and 60fps. Newer systems ofcourse probably need optimizations.

If it's your first emulator, just focus on maintainable code, and getting things working.
Pretty much exactly this.

I wrote mine a year ago with only PC's in mind. It had horribly naive bankswitching and occasionally silly switches that could be computed in a single line, but that didn't really matter because I could run it on any desktop as intended. Few weeks ago somebody asked me about porting to Android so I started going hog wild on optimizing for ARM. It's far easier to optimize for that kind of performance once your emulator is stable and mature and you're not fighting with getting the basic functionality in place. Rewriting all of my memory mappers was way easier knowing that as long as I was swapping banks correctly the image would render, and it wasn't a case of the PPU potentially being broken.

User avatar
Dwedit
Posts: 4327
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: What determines whether an emulator is "fast" or "slow"?

Post by Dwedit » Sun Sep 15, 2013 8:31 pm

At one end, you have your emulators written in Javascript in a web browser that tug along slowly on a dual core machine.
At the other extreme, you have PocketNES, written almost entirely in ARM assembly language, which runs at real time on a 16MHz GBA (using hardware accelerated graphics).
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

ArsonIzer
Posts: 115
Joined: Fri Jul 19, 2013 11:38 am

Re: What determines whether an emulator is "fast" or "slow"?

Post by ArsonIzer » Mon Sep 16, 2013 8:01 am

Ah, I see. My emulator is written in Java anyway, so processor-specific optimizations really aren't that viable. To add to that, this is the first thing I've done in my life that is so low-level, I have +- 2 years experience with Java (my first and currently only programming language), and I literally did not know what a CPU did until about 5 months ago (what registers were, what an instruction was, or whatever its general purpose was anyway), so even getting the CPU to work in the first place was a complete and utter disaster, so optimizing it to a point where it can run at X times 60 fps is going to be a living hell.

Thanks for the answers and suggestions. While optimization is going to be put off for a while, the answers did give me some things to think about for the future of the emulator.

User avatar
miker00lz
Posts: 235
Joined: Thu Sep 23, 2010 7:28 pm

Re: What determines whether an emulator is "fast" or "slow"?

Post by miker00lz » Mon Sep 16, 2013 8:41 pm

Writing your first CPU emulator is one hell of a learning experience for sure. My first was the 8086. That was.... taxing.

ArsonIzer
Posts: 115
Joined: Fri Jul 19, 2013 11:38 am

Re: What determines whether an emulator is "fast" or "slow"?

Post by ArsonIzer » Tue Sep 17, 2013 1:20 am

miker00lz wrote:Writing your first CPU emulator is one hell of a learning experience for sure. My first was the 8086. That was.... taxing.
Haha I have to give it to you, you've got some guts to do that as your first emulator. I think I would've thrown away my laptop and lived in the woods after becoming permanently paranoid if I had to do that with the knowledge I had prior to making the 6502. Even now, I think the 8086 would be a major, several-month challenge to me that would have a pretty big chance of failure to be honest. I do, however, plan to emulate one at some point. The NES is just a start in my journey (hopefully) :D

User avatar
miker00lz
Posts: 235
Joined: Thu Sep 23, 2010 7:28 pm

Re: What determines whether an emulator is "fast" or "slow"?

Post by miker00lz » Tue Sep 17, 2013 12:34 pm

ArsonIzer wrote:
miker00lz wrote:Writing your first CPU emulator is one hell of a learning experience for sure. My first was the 8086. That was.... taxing.
Haha I have to give it to you, you've got some guts to do that as your first emulator. I think I would've thrown away my laptop and lived in the woods after becoming permanently paranoid if I had to do that with the knowledge I had prior to making the 6502. Even now, I think the 8086 would be a major, several-month challenge to me that would have a pretty big chance of failure to be honest. I do, however, plan to emulate one at some point. The NES is just a start in my journey (hopefully) :D
Well, if you can do the 6502 you can definitely do the 8086. The most confusing thing on the 8086 is understanding the addressing mode byte (aka mod/reg/rm byte)... once you get that it's really not much harder. There are more opcodes and more addressing modes, so it will take more time. There are also "group" opcodes where the first instruction byte indicates which group, then it has a modregrm byte where one of it's fields indicates the exact operation. It can get pretty weird. Oh and there are segments to worry about too, but that's not so bad. Yeah, it DID take a few months before I was able to boot DOS.

If you get around to doing it, let me know if you want a little help. Once you understand the couple confusing aspects, it does become about as easy as the 6502. :)

tepples
Posts: 22013
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: What determines whether an emulator is "fast" or "slow"?

Post by tepples » Tue Sep 17, 2013 2:02 pm

Are 8086 and 65816 of similar complexity?

User avatar
miker00lz
Posts: 235
Joined: Thu Sep 23, 2010 7:28 pm

Re: What determines whether an emulator is "fast" or "slow"?

Post by miker00lz » Tue Sep 17, 2013 3:53 pm

I don't know 65816 assembly, but reading it's specs on Wikipedia I would hazard a guess that it's roughly the same. If anything, likely a complexity edge to the 8086 because in some cases, the encoding can be pretty strange looking. There are also repetition and segment override prefixes that must be parsed and honored. I'm not sure if the 65816 has anything like that.

This is my main CPU module for it: https://sourceforge.net/p/fake86/code/c ... ke86/cpu.c

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: What determines whether an emulator is "fast" or "slow"?

Post by koitsu » Tue Sep 17, 2013 6:30 pm

The one thing that bit me in the ass with x86 all the time, compared to 65xxx CPUs, was how the x86 handles status flags when doing mov or equivalent operations. Unlike the 65xxx many flags do not get set when moving a value or contents into a register, requiring you to use test or other crap. Can't tell you how often that caused bugs in my code when doing x86 nearly 20 years ago.

65xxx really spoils you in a lot of regards. Honestly the 65816 is a great piece of engineering (IMO), I just wish it had opcodes for multiplication/division (even just integer would be fine); sure, SNES/SFC has memory-mapped registers for that, but we're talking CPUs here.

P.S. -- NSFW, but: fuck x86. Awful processor if you ask me. Been around too long and way too many hacks and extensions (there are I believe two 32-bit feature flags that define what each CPU is capable of, including MMX, SSE and its bazillion derivatives, blah blah). Just so damn nasty. Kudos to all the guys who can do x86 on today's x86 CPUs; I'm glad I stopped with the 486.

User avatar
miker00lz
Posts: 235
Joined: Thu Sep 23, 2010 7:28 pm

Re: What determines whether an emulator is "fast" or "slow"?

Post by miker00lz » Tue Sep 17, 2013 7:06 pm

Yeah, it's not the cleanest arch out there. That's for damn sure. I have no problem with the flags not being modified from a mov though. In fact, I like it and it makes more sense IMO. It's intended to move data, not make calculations. I might be annoyed in a lot of cases if I wanted my flags to stay as they are, but move some data before looking at them. It lets you be a lot more flexible with your code order and not have to worry about storing/restoring flags, and the cost of a test op here and there is negligible. It's only necessary when the value you want the flags to be set from is sitting in memory pre-calculated. I think usually decisions based on flags are going to be from real-time calculations.

Also, I may be wrong since I've never used 65816, but I would bet the 8086 spanks it when it comes to block moves and string operations using rep prefixes.

You're right though, modern x86 is NASTY!!!! And old x86 was still pretty quirky right from the beginning, but that doesn't always mean bad.

Joe
Posts: 437
Joined: Mon Apr 01, 2013 11:17 pm

Re: What determines whether an emulator is "fast" or "slow"?

Post by Joe » Tue Sep 17, 2013 8:21 pm

miker00lz wrote:Also, I may be wrong since I've never used 65816, but I would bet the 8086 spanks it when it comes to block moves and string operations using rep prefixes.
Block moves are pretty fast, but decompressing RLE is faster. :lol: (Scroll down to the "results" section.)

Post Reply