nesdev.org

When I mentioned ToP I was thinking about how it "bloops" "burps" and "clicks" a lot on these small BRR samples during the music playback. And that seems to come from inaccuracies on the CPU emulation.

I don't know what it's supposed to sound like since I don't have an NTSC console, but here's what ToP sounds like on my PAL SNES, where it has clear artefacts.

mic_ wrote:I don't know what it's supposed to sound like since I don't have an NTSC console, but here's what ToP sounds like on my PAL SNES, where it has clear artefacts.

Yes that's broken (quite obvious) but emulators have it way worse, even while emulating a NTSC machine... O_O

Mmh, really ?
I remember Snes9x emulating it more or less properly, even tough this emulator is quite inaccurate. Maybe ZSNES is even more inacurate though.

Aside of that I have another idea for practical BRR streaming synchronization.
At all times, one of the communication regs would tell the CPU how many BRR blocks it's supposed to send to the SPC.

This way, the SPC increment this number automatically as the streamed audio plays. Then it's up the CPU to respond by sending its data, then the SPC acknownledge data, overwrite the old buffer and the count reset to zero.

This would also work on both PAL and NTSC consoles (and probably emulators) without changing any line of code. and it would be simpler than my previous solution.

Slightly off topic, but since this is an SPC700 topic I'll ask this question.

How fast does the SPC700 respond to changes in it's DSP registers? I was thinking of doing FM-synth by manipulating the channel frequency registers.

How fast ? I don't think there is any kind of Delay - that is a write will take effects immediately.
Maybe you should check out anomie's docs for details.

Bregalad wrote:Maybe ZSNES is even more inacurate though.

In ZSNES, the 12-cycle DIV instruction takes the same time as the 2-cycle NOP instruction, because a cycle-table lookup was slower than just using an average constant cycle value for all opcodes.

So yes. Yes, it most certainly is.

ZSNES is a relic of the past from when PCs could not hope to emulate the SNES very accurately and still run at full speed. Plenty of liberties were taken for performance and other things probably just because many details were unknown. This should sound familiar to NES emulation.

> Plenty of liberties were taken for performance and other things probably just because many details were unknown.

SMP opcode cycle counts were known before ZSNES was started on. We even had the WDC CPU documentation on per-cycle operation. Many of its decisions were deliberate. And for the time, wise.

What's worse is that even knowing the information now, and even with faster computers, simple one-line fixes are still not added.

> This should sound familiar to NES emulation.

The NES was much more timing-sensitive, and the SNES alleviates a lot of that through HDMA and IRQs. But make no mistake, having emulated both systems myself: NESticle was a more faithful NES emulator than ZSNES is an SNES emulator.

Imagine if NESticle were given a crude Win32 windowed-mode port, and a new minor release every 3-5 years. And saying anything at all bad about it invoked ridicule on most emulation forums. Wouldn't that be a treat? :P

What you say is true of ZSNES, or at least it was when ZSNES relied on x86-only assembly language code. (Does it still?) Snes9x might get a free pass because its pure C++ code allows ports to Wii consoles and Android phones, which aren't especially "faster computers".

> What you say is true of ZSNES, or at least it was when ZSNES relied on x86-only assembly language code. (Does it still?)

Yes, the parts ported to C were mostly the GUI and path loading code.

> Snes9x might get a free pass because its pure C++ code allows ports to Wii consoles and Android phones, which aren't especially "faster computers".

I don't really mind emulators based around speed hacks aimed at older/slower hardware. Although in most cases it's the owners being penny wise, pound foolish; there are legitimate cases where faster hardware can't be easily obtained. I just wish the people who did have faster hardware cared a bit more about quality. Improving ZSNES would be addressing the symptom rather than the cause, but it'd be better than nothing.

I've had enough of trying myself, but it'd be nice if we had someone like Marty to make a compelling, user-friendly UI and worry about accuracy and worry about making it as quick as possible. I could certainly lend my assistance toward the first two.

byuu wrote:Although in most cases it's the owners being penny wise, pound foolish

Penny wise? What a bozo.

In the case of the Wii, there are a few issues in play, apart from end users' mental set against the home theater PC.

• A HBC'd Wii is a lot cheaper than a second PC, despite that the PC can do more.
• Most PCs don't come bundled with input devices meant for 10-foot use.
• Full-width PC towers look out of place next to a "consumer electronics device", and a lot of people don't know about smaller models such as the Aspire X1.
• Wii supports SDTV output. PCs generally don't. Though VGA to composite adapters exist (such as those sold on SewellDirect.com), they're sold online, not in stores.
• Some HDTVs have trouble with VGA or DVI/HDMI video signals from a PC. They might not support the exact resolution that the PC outputs, for instance, and might insist on scaling the image wrong, such as cutting off the menu bar and taskbar.
• Most gamepads not made by Sony or Nintendo have dodgy directional pads. Even Microsoft's. Adapters like the EMS Dual Shooter are sold online, not in stores.

But make no mistake, having emulated both systems myself: NESticle was a more faithful NES emulator than ZSNES is an SNES emulator.

See guys : I've always said Nesticle weren't THAT bad.

I think the NES needs some accuracy because about half of the game library relies on cycle timed code and midframe register writes somewhere.

However SNES emu can get all the timings wrong, emulate IRQs that firest at the wrong time of the good scanline and emulate HDMA that doesn't interrupt the CPU and 99% of games will still be working fine.

Bregalad wrote:However SNES emu can get all the timings wrong, emulate IRQs that firest at the wrong time of the good scanline and emulate HDMA that doesn't interrupt the CPU and 99% of games will still be working fine.

Yes, that is all very true. And the games that require the timing are titles such as:
* Mecarobot Golf
* Jumbo Osaki no Hole in One Golf
* Street Racer
* Power Rangers (one of them, anyway)
* Sink or Swim
* Speedy Gonzales
* Battle Blaze
Not exactly A-list games here, so it's no wonder when people play Zelda and Mario alone that they think things are perfect. (Even though there are obvious problems even in both of those, heh.)

In most cases, you can get away with murder by running too fast. Mortal Kombat II breaks completely if you have one extra I/O cycle on WAI (as little as one ten-millionth of a second per frame), but you can run it twice as fast as you should and it works fine.

I think it's really just the PPU that scares people off the SNES. The PPU is a nightmare: 64 registers versus 8, and every one is packed full of flags that all interact and blend with each other. That, and CPU hell. SMP, SuperFX, SA-1, uPD96050, HG51B169 ... unlike mappers, these are full-fledged processors with lots of auxiliary functions built-in. And unlike obscure NES mappers, support for all of these is basically mandatory if you want anyone to use your work.

These last few posts discussing emulator (in)accuracies made me think of this great email sent to the Nesticle developers back in 1997:

Hello, this is a question.

you do nots think to make a SNESTLICLE or think to make it?

if make it make please it but that they could so that run to a speed 100 % in a pentium to 133 MHz with 16MB of RAM, make it it but similar to nesticle that for my the best emulator.

Ahh and that good has sound as nesticle.

Thanks and I wait a good response.