6 ms·

IMO, post author is an idiot: Nesticle/Nesticle95 did not required patches to NES games, it was that most time-consuming parts were written in assembly (6202 CP

by faragon 14y ago

IMO, post author is an idiot: Nesticle/Nesticle95 did not required patches to NES games, it was that most time-consuming parts were written in assembly (6202 CPU, PPU, and sound synthesis). Also back in 1996, the Snes96 SNES emulator ran some games at almolst playable speed on 486-DX4 @100MHz (ones not requiring DSP nor "mode 7"), few years later NLKSNES was even faster, being even full frame rate (less accurate, though). IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that (even emulating per-line effects -HSYNC IRQ with palette changes-, custom chips DSP1/FX/FX2 or even a second 65816 found in some cartridges for doing RLE decompression, etc.).

daeken 14y ago
> IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that No, it means accurate implementation. That doesn't mean accurate gameplay (which many inaccurate emulators achieve), but proper accurate emulation. You should really, really read up on byuu's work; he's probably the best developer in emulation at this point.
- faragon 14y ago
  Even for accurate SNES emulation implementation, 3GHz (on 3 way OooE CPU with massive SIMD capabilities -e.g. Core2Duo, Core iX, or modern AMD-), is crazy. BTW, my evaluation was based on his article, not on his reputation.
  - daeken 14y ago
    No, it's not crazy at all. There's a massive amount of synchronization that has to be done between, say, the CPU and PPU. It's not possible to even do per-pixel synchronization right now, which is why line-based sync is in use. Have you read the source? The implementation is brilliant, even if it is "slow".
    - faragon 14y ago
      Per-pixel synchronization makes sense on systems writing pixels directly to the CRT, like the case of Atari 2600, which has no framebuffer at all, and required accurate CPU timing for writing to the DAC (Atari 2600 TIA). In case of the SNES, or any tile-based 8 and 16 bit console, IMO, the only accurate synchronization required is per-line (HSYNC) and per-frame (VSYNC), in most cases. If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written (complex multiprocessors systems with CPUs, coprocessors, DMA, rely on interrupts for synchronization, although some per-cycle heterogeneous memory access thing was used as anti-copy protection, timer handling, etc.).
      - rcfox 14y ago
        > If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written That's the whole point. There are games that did crazy stuff, and don't work well on many emulators. Perfect emulation requires software simulation of these crazy exploitations of the hardware.
        faragon 14y ago
        Yes, but 3GHz of a modern OooE CPU (with at least 3 instruction per clock, capable of massive SIMD)? Come on. Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100% (!). It reminds me the comparison between Git and Monotone made by Linus Torvalds. I find no reason in the Earth for perfect SNES emulation with just one core of a modern OooE CPU and 1-1.5GHz (with GPU assistance for stretch and filtering/postprocess), even written in C, with no SIMD assembly at all (SNES 65816 CPU was running at maximum speed of 3.58 MHz, being its coprocessors even slower).
        byuu 14y ago
        > Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100% The Ars Technica image guy made that screenshot. It wasn't from running my emulator, which is strictly single-core (for a whole host of reasons I won't get into.) Your guess is as good as mine why he chose that screenshot, I didn't know about it until after the article was published.
voltagex_ 14y ago
The brilliant thing about bsnes (the "crazy" emulator you're referring to) is that the author has worked with researchers to reverse-engineer all of the secondary chips that SNES carts used - even an ARM3 chip.
- faragon 14y ago
  I just pointed that his implementation is slow, not that accurate implementation was not hard or require much more CPU than non-accurate. I spoke about the article, not a judgement of author's as a whole, which I respect.
eropple 14y ago
You can call him an idiot if you want, but in the early days of Nesticle many ROMs were patched to actually run on it. I was six or seven at the time and I know this because I had to find ROMs that were pre-patched; IIRC (and I may be conflating things slightly but I'm fairly sure) the [f]ixed tag was created to indicate that this ROM was modified from a standard dump largely because of emulator compatibility. And you seem to be having a very hard time understanding the difference between accurate emulation (i.e., bsnes) and the good-enough-but-much-faster emulation of stuff like ZSNES. The point of bsnes is to be a software implementation of a Super NES, not to run Super NES games, but that one seems to be handled quite nicely in the sibling thread.
- faragon 14y ago
  I understand the difference between accurate emulation and good-enough emulation. Simply, for me, is crazy to see 3 core @3GHz at 100% for accurate emulation. IMO, bsnes is slow and inneficient, not only justified by accurate emulation, but also because of its implementation. In Nesticle days I was around 20 (now 37), and actively interested in the emulation scene. The "fixed" ROMs in most cases came from ROM cartridge simulators (with embedded RAM), often requiring ROMs to be patched because of different ways of simulating bank switching or anti-piracy protections. Of course, I apreciate his work. It is just my opinion, no matter how many negative points I've got.
  - pygy_ 14y ago
    Did you review the source or profile the emu, or do you make your judgement out of what you believe the implementation of an accurate SNES emulator should take? In the former case, cold you enlighten us on the parts that are slower then they should be. In the latter case, please have a look at the source.
    - faragon 14y ago
      Yes, I did, version 089 (http://bsnes.googlecode.com/files/bsnes_v089.tar.xz http://bsnes.googlecode.com/files/bsnes_v089.tar.xz). Is clean and well written C++, but in addition to the accuracy, I see a problem in the emulation itself: templates, data structures, L1 data cache usage, synchronization. In my opinion, that emulator could be rewritten in plain C, with better data structures, and without such rare synchronization, using just one quarter of the resources is using today (v089). I pointed just 2 things: 1) against the byuu affirmation about Nesticle ROM patching for speed (in my opinion the speed of Nesticle was because of great implementation of the Bloodlust folks, via 386 assembly -both for the Watcom C + TASM DOS/DOS4GW case, and the Win32 port-), and 2) the non-sense of a whole 3GHz (with 3 of 4 threads at 100% usage), for running a SNES system, even with 100% accuracy.
byuu 14y ago
> Nesticle/Nesticle95 did not required patches to NES games NES ROMs were distributed pre-patched to work on Nesticle. I was there for it. This was not done by Bloodlust, but by people wanting to play the games. Some emulators to this day ship with databases of checksums to detect these images. > IMO, a SNES emulator requiring 3GHz means brain-dead implementation I look forward to your SNES emulator with no known bugs and much lower system requirements. And if you aren't making one, why are you so sure of what is required? None of the other SNES emulator authors who have looked at my code feel there is a technical flaw in its implementation. You need to understand the exponential function to understand bsnes' system requirements. When I first started out, I was able to run ~99% of games almost as quickly as Snes9X (the latter used ASM cores for the CPU, SA1 and SFX.) The more accurate you get, the less it fixes. To get everything running at the same time is the hard part. It means you can't take shortcuts anywhere. If I chose to remove behaviors that would break at best a dozen games, my emulator could run four times as fast. In fact, I've made a build that does just that. Here it is getting 80fps on an in-order Atom CPU: http://imageshack.us/photo/my-images/405/zelda3v.png/ http://imageshack.us/photo/my-images/405/zelda3v.png/ -- this build pushes 300-400fps on my 3GHz E8400.
- faragon 14y ago
  In my opinion, is slow. And I bet you -or others- have room for increase performance by 2-4x in next years. Even without SIMD intrinsics (autovectorization-friendly code is OK, though), but with proper data structure usage, better code L1 cache usage, increasing data cache hit ratio, reducing function/pointer indirection, reduce data cache pollution, etc.
  - byuu 14y ago
    I wrote an article on this here: http://byuu.org/articles/optimization http://byuu.org/articles/optimization Executive summary: yes, I could probably get it twice as fast with identical accuracy (in the absolute best case -- 50% faster is more realistic); but I would sacrifice the portability, maintainability and readability of the code. This is a big problem because I have very limited time and resources as a single person. It's because the code is so straight-forward that I'm able to rapidly fix bugs when they are found.

by faragon 14y ago

daeken 14y ago

> IMO, a SNES emulator requiring 3GHz means brain-dead implementation, simple as that No, it means accurate implementation. That doesn't mean accurate gameplay (which many inaccurate emulators achieve), but proper accurate emulation. You should really, really read up on byuu's work; he's probably the best developer in emulation at this point.

faragon 14y ago
Even for accurate SNES emulation implementation, 3GHz (on 3 way OooE CPU with massive SIMD capabilities -e.g. Core2Duo, Core iX, or modern AMD-), is crazy. BTW, my evaluation was based on his article, not on his reputation.
- daeken 14y ago
  No, it's not crazy at all. There's a massive amount of synchronization that has to be done between, say, the CPU and PPU. It's not possible to even do per-pixel synchronization right now, which is why line-based sync is in use. Have you read the source? The implementation is brilliant, even if it is "slow".
  - faragon 14y ago
    Per-pixel synchronization makes sense on systems writing pixels directly to the CRT, like the case of Atari 2600, which has no framebuffer at all, and required accurate CPU timing for writing to the DAC (Atari 2600 TIA). In case of the SNES, or any tile-based 8 and 16 bit console, IMO, the only accurate synchronization required is per-line (HSYNC) and per-frame (VSYNC), in most cases. If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written (complex multiprocessors systems with CPUs, coprocessors, DMA, rely on interrupts for synchronization, although some per-cycle heterogeneous memory access thing was used as anti-copy protection, timer handling, etc.).
    - rcfox 14y ago
      > If a SNES game, for perfect emulation, requires higher than per-line synchronization, it was not properly written That's the whole point. There are games that did crazy stuff, and don't work well on many emulators. Perfect emulation requires software simulation of these crazy exploitations of the hardware.
      - faragon 14y ago
        Yes, but 3GHz of a modern OooE CPU (with at least 3 instruction per clock, capable of massive SIMD)? Come on. Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100% (!). It reminds me the comparison between Git and Monotone made by Linus Torvalds. I find no reason in the Earth for perfect SNES emulation with just one core of a modern OooE CPU and 1-1.5GHz (with GPU assistance for stretch and filtering/postprocess), even written in C, with no SIMD assembly at all (SNES 65816 CPU was running at maximum speed of 3.58 MHz, being its coprocessors even slower).
        byuu 14y ago
        > Also, from desktop snapshot, in task manager it showed 4 CPUs, with 3 of them at almost 100% The Ars Technica image guy made that screenshot. It wasn't from running my emulator, which is strictly single-core (for a whole host of reasons I won't get into.) Your guess is as good as mine why he chose that screenshot, I didn't know about it until after the article was published.

voltagex_ 14y ago

The brilliant thing about bsnes (the "crazy" emulator you're referring to) is that the author has worked with researchers to reverse-engineer all of the secondary chips that SNES carts used - even an ARM3 chip.

faragon 14y ago
I just pointed that his implementation is slow, not that accurate implementation was not hard or require much more CPU than non-accurate. I spoke about the article, not a judgement of author's as a whole, which I respect.

eropple 14y ago

You can call him an idiot if you want, but in the early days of Nesticle many ROMs were patched to actually run on it. I was six or seven at the time and I know this because I had to find ROMs that were pre-patched; IIRC (and I may be conflating things slightly but I'm fairly sure) the [f]ixed tag was created to indicate that this ROM was modified from a standard dump largely because of emulator compatibility. And you seem to be having a very hard time understanding the difference between accurate emulation (i.e., bsnes) and the good-enough-but-much-faster emulation of stuff like ZSNES. The point of bsnes is to be a software implementation of a Super NES, not to run Super NES games, but that one seems to be handled quite nicely in the sibling thread.

faragon 14y ago
I understand the difference between accurate emulation and good-enough emulation. Simply, for me, is crazy to see 3 core @3GHz at 100% for accurate emulation. IMO, bsnes is slow and inneficient, not only justified by accurate emulation, but also because of its implementation. In Nesticle days I was around 20 (now 37), and actively interested in the emulation scene. The "fixed" ROMs in most cases came from ROM cartridge simulators (with embedded RAM), often requiring ROMs to be patched because of different ways of simulating bank switching or anti-piracy protections. Of course, I apreciate his work. It is just my opinion, no matter how many negative points I've got.
- pygy_ 14y ago
  Did you review the source or profile the emu, or do you make your judgement out of what you believe the implementation of an accurate SNES emulator should take? In the former case, cold you enlighten us on the parts that are slower then they should be. In the latter case, please have a look at the source.
  - faragon 14y ago
    Yes, I did, version 089 (http://bsnes.googlecode.com/files/bsnes_v089.tar.xz http://bsnes.googlecode.com/files/bsnes_v089.tar.xz). Is clean and well written C++, but in addition to the accuracy, I see a problem in the emulation itself: templates, data structures, L1 data cache usage, synchronization. In my opinion, that emulator could be rewritten in plain C, with better data structures, and without such rare synchronization, using just one quarter of the resources is using today (v089). I pointed just 2 things: 1) against the byuu affirmation about Nesticle ROM patching for speed (in my opinion the speed of Nesticle was because of great implementation of the Bloodlust folks, via 386 assembly -both for the Watcom C + TASM DOS/DOS4GW case, and the Win32 port-), and 2) the non-sense of a whole 3GHz (with 3 of 4 threads at 100% usage), for running a SNES system, even with 100% accuracy.

byuu 14y ago

> Nesticle/Nesticle95 did not required patches to NES games NES ROMs were distributed pre-patched to work on Nesticle. I was there for it. This was not done by Bloodlust, but by people wanting to play the games. Some emulators to this day ship with databases of checksums to detect these images. > IMO, a SNES emulator requiring 3GHz means brain-dead implementation I look forward to your SNES emulator with no known bugs and much lower system requirements. And if you aren't making one, why are you so sure of what is required? None of the other SNES emulator authors who have looked at my code feel there is a technical flaw in its implementation. You need to understand the exponential function to understand bsnes' system requirements. When I first started out, I was able to run ~99% of games almost as quickly as Snes9X (the latter used ASM cores for the CPU, SA1 and SFX.) The more accurate you get, the less it fixes. To get everything running at the same time is the hard part. It means you can't take shortcuts anywhere. If I chose to remove behaviors that would break at best a dozen games, my emulator could run four times as fast. In fact, I've made a build that does just that. Here it is getting 80fps on an in-order Atom CPU: http://imageshack.us/photo/my-images/405/zelda3v.png/ http://imageshack.us/photo/my-images/405/zelda3v.png/ -- this build pushes 300-400fps on my 3GHz E8400.

faragon 14y ago
In my opinion, is slow. And I bet you -or others- have room for increase performance by 2-4x in next years. Even without SIMD intrinsics (autovectorization-friendly code is OK, though), but with proper data structure usage, better code L1 cache usage, increasing data cache hit ratio, reducing function/pointer indirection, reduce data cache pollution, etc.
- byuu 14y ago
  I wrote an article on this here: http://byuu.org/articles/optimization http://byuu.org/articles/optimization Executive summary: yes, I could probably get it twice as fast with identical accuracy (in the absolute best case -- 50% faster is more realistic); but I would sacrifice the portability, maintainability and readability of the code. This is a big problem because I have very limited time and resources as a single person. It's because the code is so straight-forward that I'm able to rapidly fix bugs when they are found.