It Might Be NES

Cole · Post by **Cole** » Wed Jan 16, 2008 9:17 am

Gil_Hamilton wrote:Accuracy-wise, Nintendulator is the best.

Not necessarily true. Run blargg's test roms on the emulators and the result will speak for itself.

Snark · Post by **Snark** » Wed Jan 16, 2008 8:13 pm

Gil_Hamilton wrote: Accuracy-wise, Nintendulator is the best.

Do you know how it differs from Nestopia? (I mean, which part is more accurate than Nestopia that is)

edit:

Cole wrote:
Gil_Hamilton wrote:Accuracy-wise, Nintendulator is the best.
Not necessarily true. Run blargg's test roms on the emulators and the result will speak for itself.

And ahem, does said test pass on Nestopia?

byuu · Post by **byuu** » Wed Jan 16, 2008 8:20 pm

Accuracy-wise, Nintendulator is the best.
Last I checked, the interface was, shall we say, minimal, though.
It also pounds the CPU in the ass. Hard.

Yep, it supposedly requires around ~1.8GHz; as least, last I checked.
And the reason? It cycle steps the NES PPU.

... now imagine the much, much more powerful, dual-PPU SNES cycle stepped :P

bobthebuilder · Post by **bobthebuilder** » Thu Jan 17, 2008 6:31 am

franpa wrote:Rocknes status is currently on Ice. no one will help the author with a glitch in the video output so he has given up for the time being.

unless this very late update will fix said issue.... ill speak to him soon on msn and ask.

Not what I heard, he is still working on Rocknes and has fixed the frame rate issue.

franpa · Post by **franpa** » Thu Jan 17, 2008 7:47 am

Ah, thats absolutely ingenious.... i am extremely pleased that it has -finally- been sorted out and fixed

it was like a month or 2 when i last checked out the rocknes forums and had recently queried the new beta build that is to be expected fairly soon about this issue.

the audio sync bug will still be present tho -.- but at least i would get smooth frame rate.

Cole · Post by **Cole** » Thu Jan 17, 2008 9:28 am

Some of blargg's test roms can be found here:
http://nesdevwiki.org/wiki/index.php/Emulator_Tests

byuu wrote:
Accuracy-wise, Nintendulator is the best.
Last I checked, the interface was, shall we say, minimal, though.
It also pounds the CPU in the ass. Hard.
Yep, it supposedly requires around ~1.8GHz; as least, last I checked.
And the reason? It cycle steps the NES PPU.

If by cycle stepping you mean always executing the different processors in full parallel (on the code level), i.e do 1 CPU cycle, switch to PPU and do 1 cycle, switch to APU and do 1 cycle and so on and considering that to be more accurate. Why so compared to say, execute X CPU cycles until it does something to another processor that requires it to change its state and only then update it, keeping the context switches to a minimum?

Gil_Hamilton · Post by **Gil_Hamilton** » Thu Jan 17, 2008 9:39 am

Cole wrote:Some of blargg's test roms can be found here:
http://nesdevwiki.org/wiki/index.php/Emulator_Tests

byuu wrote:
Accuracy-wise, Nintendulator is the best.
Last I checked, the interface was, shall we say, minimal, though.
It also pounds the CPU in the ass. Hard.
Yep, it supposedly requires around ~1.8GHz; as least, last I checked.
And the reason? It cycle steps the NES PPU.
If by cycle stepping you mean always executing the different processors in full parallel (on the code level), i.e do 1 CPU cycle, switch to PPU and do 1 cycle, switch to APU and do 1 cycle and so on and considering that to be more accurate. Why so compared to say, execute X CPU cycles until it does something to another processor that requires it to change its state and only then update it, keeping the context switches to a minimum?

I'm not byuu, but I think the point is that both processors are running in parallel on the real hardware, and both are capable of making changes to the system at any step.

byuu · Post by **byuu** » Thu Jan 17, 2008 5:32 pm

If by cycle stepping you mean always executing the different processors in full parallel (on the code level), i.e do 1 CPU cycle, switch to PPU and do 1 cycle, switch to APU and do 1 cycle and so on and considering that to be more accurate. Why so compared to say, execute X CPU cycles until it does something to another processor that requires it to change its state and only then update it, keeping the context switches to a minimum?
I'm not byuu, but I think the point is that both processors are running in parallel on the real hardware, and both are capable of making changes to the system at any step.

Yes, this is correct.

On some processors, they only share a very small communication window. Eg the SNES S-CPU and S-SMP. They only share a two-bit bus (four registers), so whenever those are accessed, you can sync then only. This cuts down ~21MHz+~24MHz synchronization to ~20,000 context switches a second. You just need a way to break out of one processor's context to switch to the other, and vice versa. State machines (and optional enslavement of the slower / simpler processor) being the most common way of doing this.

But on other processors, we aren't so lucky. The S-SMP and S-DSP both share the 64kb APU RAM, and both can read and write to it at any time. There's really no way to know when one writes to RAM, if the other is going to read from that RAM location soon. The S-CPU and S-PPU1/2 at first glance only share a 5-bit address bus ($2100-$213f), but upon closer inspection, the PPU also outputs Hblank and Vblank pins, which the CPU needs to see transition immediately to control its NMI and IRQ interrupts. As I've learned, even being off by 4(!!) clock ticks here is enough to break some games.

Yes, there are hacky ways to get "kinda sorta the same" accuracy without cycle stepping these chips. For the SMP+DSP, you could keep a relative timestamped write buffer that you can rewind when you need an older value. For the CPU+PPU, you could duplicate the counter system in both the CPU and PPU, so that you only have to sync on CPU access to the 5-bit bus. Just pray that the PPU doesn't try changing interlace/overscan, as that affects how the counters wrap. Or add even more glue logic, and hope that the two counters never, ever desync. But all of my experience in emulation has shown that the more you try to hack your way around things and speed them up, the more bug prone you get. Personally, I'd rather require a 2GHz CPU than an 800MHz CPU with a list of 50+ open game bugs. I also take issue with the fact that these designs are not how the real hardware works. No, I'm not talking about getting stupid and emulating each and every transistor. I'm just talking about keeping each processor a completely separate module. The CPU shouldn't know anything about the PPU's counter system. A real S-CPU can run on its own without a PPU at all. The H/Vblank pins will just always be low. So too should an emulated processor be removable from an emulator and used in another system, if desired. This also gives you another benefit that you can easily individually overclock and underclock specific chips, which can be kind of neat.

At the end of the day, using the above speedup tricks is a personal preference, I guess. If you're smart enough to use the above tricks without introducing bugs (I am not), then you will certainly have a superior emulator which uses far less CPU resources. The code would also be more difficult for someone studying the system's architecture to understand, but that doesn't matter to 99.9% of end users of an emulator.

I believe the NES CPU and PPU share the same V/Hblank pin setup, where the PPU's signal triggers NES interrupts (although I believe NES only has one, either NMI or IRQ; and mappers do the rest). Apologies for talking about the SNES so much in this thread, but I'm obviously not as knowledgeable with the NES. Anyway, you seem to be well versed in this subject. Were you working on an emulator as well?

kick · Post by **kick** » Sat Jan 26, 2008 2:36 pm

Breaking news: A new (beta) version of RockNES has been released

- Fixed joystick support and modified the config window.
- Fixed an obscure bug, "file doesn't exist" error.
- Fixed backed battery save/load, it was broken.
- Fixed PPU state loading, somewhat.
- Fixed sprite overflow flag, somewhat.
- Usual optmizations and tweaks.
- Added a new saveblock tagged as PTB1, extended PPU savestate.
- Added a new saveblock tagged as CPU1, extended CPU savestate, fixes loading errors.
- ROM patching dialog improved.
- Config file slightly changed for accuracy.
- The program can run in background now, sweet.
- Fixed video refresh rate to be 60Hz.
- Fixed sound output and changed from 44100Hz to 22050Hz as default.
- Other fixes I don't remember

http://rocknes.kinox.org/

Bloody awesome!

That's some really great news this week: RockNES manages to survive the ice age,and straight from the horse's mouth we have the information that a new version of NEStopia is just around the corner

All we need now is revival of the Nintendulator and VirtuaNES 2.0 projects and once again we'll have a very healthy NES emulation scene.

xamenus · Post by **xamenus** » Sat Jan 26, 2008 8:18 pm

Another NES emulator release a few weeks ago that people may have overlooked is Jnes v1.0.

www.jabosoft.com/jnes

kick · Post by **kick** » Sat Jan 26, 2008 9:02 pm

xamenus wrote:Another NES emulator release a few weeks ago that people may have overlooked is Jnes v1.0.

www.jabosoft.com/jnes

Not really.It's been already mentioned before in this thread.See the third post from the bottom on page 1.

phonel · Post by **phonel** » Thu Mar 06, 2008 3:36 am

cool, yea Jnes did just get an update, there is now chat support during online play but it is horrible. The best NES emu to play online is nestopia which features chat support on kaillera.

And about It might be NES, there has been no progress for 3 years, i think the creator has stop working on it, i haven't tested it out yet, but will soon. I'm very curious on how well it plays NES games and if it plays them at full speed with sound

ZH/Franky · Post by **ZH/Franky** » Sun Mar 23, 2008 1:07 am

On IMBnes, Final Fantasy 3 battle graphics get all muffled. And I really do MEAN muffled.
I use it only so I can play Kirbys Dreamland in the downstairs living room.

ZH/Franky · Post by **ZH/Franky** » Sun Mar 23, 2008 1:11 am

If byuu, once he made bsnes so perfect that it couldn't be improved anymore, was also very knowledgeable about the NES and started working on NES emulation, that would be awesome.

King Of Chaos · Post by **King Of Chaos** » Sun Mar 23, 2008 1:41 am

Franky wrote:If byuu, once he made bsnes so perfect that it couldn't be improved anymore, was also very knowledgeable about the NES and started working on NES emulation, that would be awesome.

Well, after bsnes wouldn't he want more of a challenge instead of going backwards? If anything, I'd like to see an accurate N64 emulator (without plugins) someday (if not by byuu, then somebody else following in the accurate footsteps).

ZH/Franky · Post by **ZH/Franky** » Sun Mar 23, 2008 2:01 am

There's just one things though:
Exact SNES emulation (i.e. bsnes) requires a monster of a machine to run. I imagine a PS2 emulator in the same league of bsnes (in terms of accuracy) to require a computer where the processor is probably around, oh, 1000 ghz or more?

Here's how I see it:
At first, when no one has computers powerful enough for true accuracy, you have "hacky" emulators that aren't very accurate, but are totally compatible (using hacks and whatnot), then as the hardware most people have becomes more and more powerful, emulation quality can (in practise) be so much better.

Hell, imagine a PS3 being emulated to exact precision then. That would probably require a processor that runs at least 9999999999999999 ghz

Mind you, are consoles get more complex, I imagine exact emulation would be harder anyway (i.e. take a lot more time), to get right. So if the size of the amount of people working on a single project stays the same, emulators would either take longer to become perfect, or be made hackier. Or, larger amounts of people would have to work on a single emulator.

I wonder how powerful a computer would need to be, to 100% accurately emulate the brain...

mudlord · Post by **mudlord** » Sun Mar 23, 2008 2:13 am

If anything, I'd like to see an accurate N64 emulator (without plugins) someday (if not by byuu, then somebody else following in the accurate footsteps).

Closest thing your gonna see is MooglyGuy's work in MESS.

Though I am interested in the speed that is pulled off. Though, on odds that it is developed with MAME ethics in mind, I bet its slow (yeah, I hate MAME for several reasons).

I wonder how powerful a computer would need to be, to 100% accurately emulate the brain...

Don't even go there...And I bet people want it cycle accurate too. Oh hey, why don't we get the MAME team to do it, since they are so insanely obsessive with accuracy >.<

But hey, since we want 100% perfect accuracy, speed doesn't matter, right????

PS: Please don't take this as being against Marty, byuu and co. I just hate MESS/MAME. Thats all.

King Of Chaos · Post by **King Of Chaos** » Sun Mar 23, 2008 2:40 am

mudlord wrote:I just hate MESS/MAME.

Amen to that (no offense of course, I just don't like the mess, no pun intended).

I think in time the current issues with speed will slowly, but surely fade away once CPUs become more and more powerful.

Clements · Post by **Clements** » Sun Mar 23, 2008 2:44 am

King Of Chaos wrote:
mudlord wrote:I just hate MESS/MAME.
Amen to that.

Thirded. It's annoying when a game you care about gets broken in MAME and no one cares about fixing it. I just stick to an old version that works and forget about ever updating.

King Of Chaos · Post by **King Of Chaos** » Sun Mar 23, 2008 2:46 am

Exactly, the mess of MAME one could say.

mudlord · Post by **mudlord** » Sun Mar 23, 2008 2:52 am

I think in time the current issues with speed will slowly, but surely fade away once CPUs become more and more powerful.

I see your point, but I think things can still be accurate while having some speed. I do believe though cycle accuracy is just one way to be accurate and that its not a one size fits all solution.

Thirded. It's annoying when a game you care about gets broken in MAME and no one cares about fixing it. I just stick to an old version that works and forget about ever updating.

Same here, though I have a large list in addition to that why I despise MAME/MESS in its shape and forms (byuu summed up elsewhere some of my peeves with it)..

King Of Chaos · Post by **King Of Chaos** » Sun Mar 23, 2008 2:56 am

Well, the way I see it is, the developer(s) can do their best with what they have to work with today, and if something can't have a great deal of speed, then at least it's as hardware accurate as it can be. That's all that really matters.

mudlord · Post by **mudlord** » Sun Mar 23, 2008 3:01 am

Well, the way I see it is, the developer(s) can do their best with what they have to work with today, and if something can't have a great deal of speed, then at least it's as hardware accurate as it can be. That's all that really matters.

That I agree on. Though I admire when things have both (speed and accuracy), like blargg's audio engines (especially snes_ntsc and GME) and Regen.