How many Mhz does your CPU emulation take? WedNESday's is 45Mhz. I just wanted to see what was average and what was considered good. Please state which language you wrote it in (mine is C++).
Are you talking 486DX MHz or Pentium III MHz? Processors' instructions per clock vary.
Loopy's core for PocketNES runs in well under 16.8 MHz on ARM7TDMI.
Good point. I am talking Pentium or higher. Mine is 45Mhz/60FPS on a Pentium III.
Hats off to Loopy.
For normal 60 fps emulation, my NES emulator uses 3.5% CPU time on my 400MHz PowerMac, and 0.90% CPU time on an Athlon64 3200+ running at 2.0GHz. That comes out to 14-18MHz. It's written as a large switch statement with function calls for access to I/O registers; no assembly is used. Considering how much time is available on even a slow computer like my Mac, a CPU emulator that ran three times slower would still be plenty fast (though it would make it harder to have a
"live" ROM browser running at 60fps).
blargg wrote:
(though it would make it harder to have a
"live" ROM browser running at 60fps).
What emulator is that from? The only emulator I recall having a feature remotely like that is pile called "smynes" which has a 'live' preview of selected game in browser.
It's from a simple demo of my to-be-released NES emulator library. It runs all 12 ROMs at 60fps (on my 400MHz Mac) and randomly replaces one every once in a while.
My CPU core (and ONLY the CPU core), when executing every valid opcode at equal frequencies (using a special test ROM), takes about 100MHz for full speed on a P3. Running 'typical' code is significantly faster, though.
Oddly enough, this same CPU core, along with my per-cycle APU core, takes less than 3% CPU on my 1000MHz P3 when playing an NSF in my Winamp plugin. I suppose this is at least partially due to caching issues.
Quote:
takes less than 3% CPU on my 1000MHz P3 when playing an NSF in my Winamp plugin.
This would be expected, unless your NSF engine converts the NSF file into a NES ROM before playing it. Most NSF play routines just do some APU writes and then return, at which point the NSF player would then skip to the next 1/60 second rather than emulating an "forever: jmp forever" until the next NMI occurred.
blargg wrote:
Quote:
takes less than 3% CPU on my 1000MHz P3 when playing an NSF in my Winamp plugin.
This would be expected, unless your NSF engine converts the NSF file into a NES ROM before playing it. Most NSF play routines just do some APU writes and then return, at which point the NSF player would then skip to the next 1/60 second rather than emulating an "forever: jmp forever" until the next NMI occurred.
That's the thing - my NSF engine
DOES effectively convert the NSF file into an NES ROM before playing it, using a ~256 byte BIOS mapped at $3F00-$3FFF and some I/O registers at $3E00-$3E13 (for reading the NSF header, interfacing with the GUI, and handling the interrupt rate) and hijacking the RESET and IRQ vectors during interrupts, and it DOES emulate a "loop: JMP loop" until the next IRQ comes along.
can somebody tell me how to do a windows application not to take the 100% cpu, couse im using sleep() and i think is not right.
The Win32 API call Sleep(int milliseconds) will sleep for the given time. Also, FYI, passing a 0 will cause it to relinquish the rest of its timeslice, with the CPU usage remaining at 100%, but other applications will receive a fairer amount of time slices.
I find this subject interesting, as I decided for the heck of it (boredom mainly) to write an NES CPU core to see if I could do it. The fun part here is I am using a variant of BASIC (namely FutureBasic) for the Mac. Much faster than other BASICs for the Mac, but much slower than comparable C code. On my 1GHz PowerMac G4, my core currently requires around 25-30% the amount of time the real NES needs, a figure that I can almost certainly improve since the current implementation isn't well optimized at all (a lot of subrouine/function calls at present, not much inline stuff). Someone writing in C should have zero trouble getting a CPU core running well fast enough for any of today's superfast systems.
If I figure a way to do it, I might try a PPU core as well, but I'll be shocked if FutureBasic lets me do that in enough time (I certainly won't be able to with its built-in features, as its drawing is embarrassingly slow - I'd have to call the Mac API directly to even have a shot).
Warning: topic drift
A good way to emulate the PPU with regards to the OS is to render pixels directly, then use a single OS call to draw it on screen. For the Mac, you should be able to use an 8-bit or 16-bit GWorld and directly access its pixels (use NewGWorld, GetGWorldPixMap, LockPixels, GetPixBaseAddr, and GetPixRowBytes, then CopyBits, or send me a private message).