It is currently Mon Jul 15, 2019 7:02 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Thu Jun 13, 2019 4:52 am 
Offline

Joined: Sun May 11, 2014 8:36 am
Posts: 94
Location: France
I often read bsnes is better, but we don't mention SNES9x

Yet, in most of my tests (and my demo), I have always had a similar result between hardware and SNES9x, but with slight differences from other emulators.

Of course, for a little exotic use, may be that SNES9x does not respect the hardware, but it is not what interests me in general ;)

Here are the results I got for my SuperDan demo :
Code:
CPU:
-65% : SNES9x , mednafen , SNES hardware , NO$SNS
-68% : ZSNES (it can vary enormously, on another demo it puts -10%)
-71% : bsnes , mesen-s

Cycles VBlank :
-277/278 : SNES9x , mednafen , SNES hardware , bsnes , mesen-s
-281 : NO$SNS
-431 : ZSNES

(for the significance of the VBlank number, multiply by 7 to know the number of available cycles)

So from my different test, I advise SNES9x, if you want to know how many CPU cycles and DMA transfer takes


Last edited by Kannagi on Thu Jun 13, 2019 4:40 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 10:18 am 
Offline

Joined: Tue Nov 20, 2018 9:23 pm
Posts: 6
What about higan, as you said snes9x is easy and probably what most of your user base will end up using, but I'll still defend not using it over more accurate emulators for development especially interfacing with hardware because it's easy to make mistakes that will work on snes9x but then not work later on hardware. One example from my experience is that you can't read joypad inputs right after a vblank but bsnes debugger and snes9x where working fine despite inputs being ignored on hardware. Higan was the only emulator to replicate that behavior correctly. Higan also has more accurate vblank timing from my experience.

This also ignores any attempt to do exotic things, you can't control memory maps for custom roms in snes9x without editing the source, some romhacks only work in snes9x after being developed and working in other emulators first. You can't play sattellaview roms you need the fork of bsnes that luigiblood works on. If you want to emulate the snes keyboard you need to use no$sns. Snes9x is probably fine for what your doing but hardly what I would consider as the best emulator. If you ask me Higan is probably the best.

That being said if your aiming for compatibility with the highest number of emulators make sure it works in snes9x 1.43 I think as that's what ports tend to be based on off.


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 12:17 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4149
Location: A world gone mad
I don't understand these numbers. What exactly are you measuring/what are these numbers referring to? There's literally no context outside of "So from my different test, I advise SNES9x, if you want to know how many CPU cycles and DMA transfer takes", which doesn't explain any of the numbers you're giving. At all. It's basically the equivalent of saying this:

Code:
CPU:
- derpaemu: 95892.8
- SuperSnakeRider: 56 microsnakes
- BobsEmulator: t42 + pi
- helloworld: 99.8% (varies wildly sometimes 900%!)

Vblank:
- derpaemu: 6
- SuperSnakeRider: 450
- BobsEmulator: 0
- helloworld: 22.3 (this is correct)

If for CPU you're talking about actual CPU usage on the system running the emulator, then you've chosen to omit system specs as well. GPU matters too.

Furthermore, with bsnes, you didn't disclose what version, nor did you disclose what profile (accuracy vs. standard; this applies to older versions). It matters!

But to answer the question in the summary line: there is no "best emulator". Ensure your stuff works on hardware -- preferably on actual cartridge (read: not SD2SNES, EverDrive, etc.) -- and if it does then that's good, from there start to try and work out what quirks need to be added to be compatible with emulators. It's kind of a back-and-forth relationship though: usually today you start with developing things using emulators (because they make the development process easier), you then later test on hardware + get things working there properly, *then* go back to make sure emulator compatibility is as good as you can get it.

I also can't stress enough including a README or manual/documentation outlining emulators (and their versions/builds, including CPU architecture used) which may not work correctly. For example: "my stuff runs on bsnes v1.07 64-bit correctly, but with bsnes-plus 073.3a 64-bit requires you use bsnes-accuracy.exe". That's just one of many examples.


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 12:39 pm 
Offline

Joined: Sun May 11, 2014 8:36 am
Posts: 94
Location: France
@hibber22
If we rely on the hardware, no emulator is perfect on this point.
When I do something exotic with the material, I test on a real SNES
(but this is the case of all the consoles, I don't know who would emulate the hardware perfectly).
I find it more interesting an emulator that respects the cycles of instructions and transfers.

@koitsu
I thought everyone was using a Windows or Linux task manager to analyze CPU usage.

So, if you have 100%, it means that you are using your processor completely.
My test shows that cycles are not respected on emulators other than SNES9x / mednafen.

As for VBlank, I explained it is the number of cycles that I have left (after sending OAM, sprite and BG3 files), but that does not really matter, the emulators are fairly faithful to DMA transfers.

So this is only my opinion and my advice, I have not tested all possible cases, but for my demo I often saw the result that I put.

Of course, you still need to test on the real hardware, but is you optimizing code, (which I do very often), I would like to know the result without needing to test on SNES with each code change ;)


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 2:49 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 932
This demo, viewtopic.php?f=12&t=18970&p=239768#p239768 ?
It's showing two percent values (the second one is the 65% value that you had mentioned?)
I don't see the vblank value anywhere in that version?

Looking at the cart header, it's supposed to be an NTSC game, right?
Hmmm, and, probably unimportant, the cart hdr title string seems to be a bit too short (with a 00h byte in the last character).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 3:18 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
Kannagi wrote:
If we rely on the hardware, no emulator is perfect on this point.
When I do something exotic with the material, I test on a real SNES
(but this is the case of all the consoles, I don't know who would emulate the hardware perfectly).
I find it more interesting an emulator that respects the cycles of instructions and transfers.

TASVideos uses an older bsnes core in their emulator to create input recordings that can be played back on real hardware. That sounds like it's quite perfect.

Kannagi wrote:
I thought everyone was using a Windows or Linux task manager to analyze CPU usage.

So, if you have 100%, it means that you are using your processor completely.

An emulator may use busy loops instead of Vsync to synchronize emulated time with realtime. This would show up as the emulator maxing out one CPU core (if it's pinned to one core). That doesn't make it better or worse, or anything...

Kannagi wrote:
My test shows that cycles are not respected on emulators other than SNES9x / mednafen.

What cycles exactly?

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 3:34 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 932
I think the reference to Windows or Linux task manager was meant as example to illustrate how to express CPU load in percents.
The 65% cpu load value is most likely meant to refer to the SNES CPU, not to your Windows or Linux CPU.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 4:34 pm 
Offline

Joined: Sun May 11, 2014 8:36 am
Posts: 94
Location: France
Quote:
TASVideos uses an older bsnes core in their emulator to create input recordings that can be played back on real hardware. That sounds like it's quite perfect.

It is not perfect, for example a strange bug that I had was that if you do not read the joypad at the right time you can have graphics glitch, I doubt that bsnes emulates this kind of bug ;)

Yes, as Nocash says, I am referring to the SNES CPU.

nocash wrote:
This demo, http://forums.nesdev.com/viewtopic.php? ... 68#p239768 ?
It's showing two percent values (the second one is the 65% value that you had mentioned?)
I don't see the vblank value anywhere in that version?

Looking at the cart header, it's supposed to be an NTSC game, right?
Hmmm, and, probably unimportant, the cart hdr title string seems to be a bit too short (with a 00h byte in the last character).

Yes I'm talking about this version (NTSC ) , I didn't put the VBlank because I rarely need to look at it (I create an automated system for transfers and that does not exceed a certain limit).

There are two percentages, the first is the% CPU now and the other is the max since the beginning of the game.
So I put new demo with VBlank, but it's not exactly the same, I made a big optimization and I'm at 56%
I let you see the difference with other emulator.

Yes you're right, the title was a bit short, I did not notice thank you ;)


Attachments:
SuperDan.zip [28.83 KiB]
Downloaded 24 times
Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 5:10 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4149
Location: A world gone mad
Summation for people who can't be bothered to sift through the bizarre above:

1. CPU usage percentages in initial post are measuring actual SNES/65816 CPU usage, not CPU usage of the emulator running on a system (despite what poster said here),

2. VBlank numbers in initial post are numbers of CPU cycles remaining after doing OAM updates + sprite update + BG3 screen map and/or CHR data; DMA is involved,

3. Numbers in question are all for NTSC.

How #1 is being measured is relevant, but I do not doubt the numbers -- 6% variance seems quite legitimate/realistic (that is to say: I believe these numbers).

I suspect some emulators just lack "absolutely precise timing", and I think that's perfectly OK as long as the trade-offs are worth it (e.g. an emulator not chewing up two cores of CPU time). I am a very, very strong proponent of the "just make emulators run most games (e.g. 95%), which is the same 95% the majority of the world cares about, and ignore the rest" emulation mindset; I generally refuse to use emulators that will result in me having an elevated electric bill (exceptions being when I need to test something for very short periods of time, i.e. not multi-hour-long debug sessions).


Top
 Profile  
 
PostPosted: Fri Jun 14, 2019 2:42 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1497
I once spent two weeks exhaustively ruling out every possibility to determine why rarely my timing was off by 1/10-millionth of a second during some IRQs but not others. By comparison, Snes9X is still an opcode-based emulator for the 65816.

Still, nothing is perfect. Make a minimal test case as proof of a bug in higan, and I promise I'll fix it ASAP.

Quote:
TASVideos uses an older bsnes core in their emulator to create input recordings that can be played back on real hardware. That sounds like it's quite perfect.


SNES TAS will always be risky by nature of there being two separate oscillators even in just the base system, and more in certain cartridges. The games that run okay with TASbot are not going to be all that extremely timing sensitive.

Quote:
It is not perfect, for example a strange bug that I had was that if you do not read the joypad at the right time you can have graphics glitch, I doubt that bsnes emulates this kind of bug ;)


Probably because that statement is utter nonsense. The joypads don't affect the rendering operation of the PPUs in any way.

In 2004 when I was writing about the inaccuracies of ZSNES, I explained a lot of theories as well. Looking back on it now, those theories were pretty silly, and were based on a limited understanding of the SNES hardware I had at the time.

When it comes to your demo, you should note that every SNES deck in existence runs at slightly difference oscillator rates. If your test is in any way whatsoever bound to CPU<>SMP communications, it could result in different values on different SNES decks.

In any case, if you and koitsu prefer Snes9X, that's awesome! It's a very good piece of software that I'd highly recommend.
But if you have any direct proof of a specific thing Snes9X gets right that I don't, please tell me. I'd love to get it fixed.
A CPU meter in a full-fledged game doesn't really show anything, unfortunately.


Top
 Profile  
 
PostPosted: Fri Jun 14, 2019 4:16 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4149
Location: A world gone mad
NOT wanting to derail thread: I suspect the "can't read joypads right after VBlank" claim (ref) stems from official documentation -- when $4200 bit 0 is set, you're not supposed to read joypad data from $4218-421F until roughly 4 scanlines worth of time have passed (or more specifically, 215 microseconds). I don't know the reasoning behind these numbers, but they're from the big N. Most people reading joypads in NMI do so at the end of the routine for this reason, often combined with loop: lda $4212/and #1/bne loop to ensure $4212 bit 0 is 0 before reading from $4218-421F/4016-4017. All of what I said in this paragraph only applies when $4200 bit 0 is set. I suspect $4016-4017 (the NES-compatible legacy MMIO regs) are no exception to this either.

In practise though, I've personally never run into a situation where this has been a problem simply because I delay joypad reads until the end of NMI as much as I can, as well as do the $4212 polling loop.

I have never heard any of the above -- either paragraph, nor the console itself -- in any way/shape/form causing a "graphics glitch" (ref). I imagine there could be other side effects like having invalid/bad joypad data, but in all my years I've never heard graphical issues stemming from it. As much as it still probably surprises people these days, I'm in full agreement with byuu on this: sounds like nonsense.

I was going to talk about the lack of people reading $4210 once in NMI to reset the latch, but I don't think it's relevant here. (And I'm an offender of this myself in the very early 90s anyways...). I just hope people are setting $4200 bit 7 to 1 and using NMI-on-VBlank + wai rather than the manual L1: lda $4210 / bmi L1 / L2: lda $4212 / bpl L2 / lda $4210 method.


Top
 Profile  
 
PostPosted: Fri Jun 14, 2019 5:59 am 
Offline

Joined: Sun May 11, 2014 8:36 am
Posts: 94
Location: France
I don't do CPU <> SMP communications at the moment.
And I doubt that there will be between two SNES a difference of 6% for the speed of the CPU.

I will try to do tests on bsnes / higan to see if certain instructions are respected for the cycles, but I don't use it for the reason that I find it difficult to use.

The famous nonsense bug:
Before:
https://image.noelshack.com/fichiers/2019/24/5/1560516240-sc1.jpg
After:
https://image.noelshack.com/fichiers/2019/24/5/1560516240-sc3.jpg
What is funny is that the bug is only if you use the right or left buttons.

PS : I just tested with the latest version of higan, and I have good values


Top
 Profile  
 
PostPosted: Fri Jun 14, 2019 11:14 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1497
Quote:
I don't know the reasoning behind these numbers, but they're from the big N.


Auto joypad polling reads from $4016/4017 (well, from the controller port lines, not actually going to the address bus for it) sixteen times, once every ~256 clock cycles from the SNES CPU. Each read will barrel shift in one more bit of joypad state into $4218-421f.

If you attempt to read from $4016/$4017 yourself while auto joypad polling is enabled, it will most likely (depending on timing) throw off the gamepad's clocking of its own shift register, and the values in $4218-421f will be invalid. If you read from $4218-421f before the process completes, you will get an intermediate state of values.

There is of course a possibility of a conflict if both your code and the SNES auto joypad poller access the same resource at the same time, but it is so far and away detached from the PPU rendering process as to be utterly irrelevant to graphics output.

What usually happens is people don't understand this, their game logic goes into some weird direction based on their input polling code (note how horrifically Zelda 3 goes when you press up+down or left+right at the same time), and it gets blamed on something that is in fact a coding bug, which is what is ostensibly happening here.

I'm probably being a jerk about it like always, though. I get too defensive.

(aside: kevtris confirmed this stuff with a logic analyzer while working on the Super Nt.)

Quote:
I was going to talk about the lack of people reading $4210 once in NMI to reset the latch


While we're at it, do not read $4210/4211 outside of NMI/IRQ! Not directed at you koitsu, but anyone reading this.

Those are acknowledgement bits only. Reading $4210 outside of NMI to detect that an NMI has occurred, can result in the NMI being suppressed entirely, the bit never being set despite firing, or in cases where the bit can remain set even though you read it as set once already. The same for $4211 and IRQs.

A small number of games unintentionally rely on this behavior and so we have to very painfully emulate it.

Quote:
I don't use it for the reason that I find it difficult to use.


bsnes / higan has been famously difficult since v074.

I tried to make bsnes v107 as easy to use as Snes9X. If you haven't tried it, you may like that version.

But certainly, you don't have to use them. It's my own fault for burning up all of the goodwill I gained from v001-v073.

If you do find a legitimate bug in bsnes though, my advance appreciation. I do want my emulator to be as perfect as I can possibly make it. I've put half of my life into this project, so I take this very seriously.


Top
 Profile  
 
PostPosted: Sat Jun 15, 2019 10:32 pm 
Offline

Joined: Sun May 11, 2014 8:36 am
Posts: 94
Location: France
So I tested the Higan v106
And good news for you, I have good values, I even feel that it is a little more accurate than other emulator;)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group