nesdev.com

There are two components to square wave phase: the state of the period divider (by 8+1 through 2047+1), and the state of the 8-step counter. As I understand it, a note-on on the Game Boy resets only the period divider, but a note-on ($4003/$4007 write) on the NES resets only the state of the 8-step counter. And you can't force a full reset of the period divider by setting the period to zero because the length counter logic treats periods less than 8+1 as note-off. Am I right?

I think I've managed to fix this - There were a couple of things wrong with the square channels' code.
I made a test build (download) with the fix, and I'm pretty sure I can hear different variations of the music loop now.
If you could test it out on your end and let me know if it seems to be fixed, that'd be great.

It's closer, but it's not there yet. It changes tone but only over a much longer time than the hardware does on average. Where the hardware sometimes alters the tone between musical phrases, Mesen sometimes keeps the same tone for the duration of an entire loop of the music for me (although in the recording I uploaded, the second half stays pretty consistent in tone, whereas the first half changes frequently. It went back to changing a lot on the third and fourth loops, which I edited out for length). FCEUX is closer, but actually not as good as I remembered when I wrote my initial post. It's still seemingly too slow about changing and the changes aren't nearly so tonally drastic. Bizhawk sounds to me like it covers a wider range of tone changes, but is still really slow about it.

Does anyone know of an emulator that does the effect like a real NES does? I tested puNES, Nestopia, FCEUX, Nintendulator, and Bizhawk. Maybe rainwarrior, tepples, or Quietust have some further ideas?

Does my NSF player get it right? Sorry for the plug, but you did ask, and I am aiming for OCD-level accuracy, so anything you have to say about it would interest me.

Sorry, but no. Yours has some phase cancellation but it doesn't change over time.

The relative square phase should not change over time when playing the NSF. The music writes both high bytes during the loop, and will leave the phase in a consistent position each time through the loop. (Triangle, on the other hand, will not be consistent, but its phase makes a relatively minor difference in the sound.)

Perhaps the phases of the square waves don't change individually, but do their timings relative to each other get changed at all? That could cause phase cancellations. I really don't have any education on or understanding of the details of how the NES works; I'm an amateur audio enthusiast so I'm limited to what my knowledge and analysis based on that can tell me, so I may be wrong about any part of my theories. But whatever is causing it, the effect is there on my NES and present to varying degrees in some emulators. It's also present in some officially released recordings of the Mario 3 soundtrack, but not all, mysteriously. Maybe those albums that don't have it used emulation or there's some other explanation. The best example I can find on an album is from the 30th anniversary Super Mario Bros. album released last year. I uploaded a sample because the second loop goes through such big tonal shifts in such a short time. Hopefully that helps demonstrate it's not me imagining things or something wrong with my NES. No emulator I've tested has produced the variety of sounds that my recording and that sample show is possible.

By the way, I forgot to mention that I also tested the Wii U and 3DS Virtual Console releases to see if they get it right. It'll probably be no shock to anyone here that they don't.

It'll be the same for every loop, since NSFs are deterministic (unlike actual game ROMs), but it should still vary within each loop. Is that what you meant, nothingtosay?

I actually wasn't really thinking about that before, but I would have thought you're correct, Rahsennor. However, I put it to the test and played the NSF in Nintendulator and Nestopia, and, to my surprise, in both emulators the sound will actually keep changing from loop to loop, never the same way twice, within reasonable listening lengths, anyway. Here's another interesting thing: I recorded two loops in Nintendulator, stopped it playing, then recorded another two loops (Nintendulator appears to have no WAV writing function, so I had to use an outside capturing program). I closed the emulator, opened it again, and recorded a further two loops. When I compared them, each instance had the same tonal shifts in the same places. Starting play, switching to another track without stopping, and then switching back still produces the same results as my other three recordings. But, with Nestopia, every play is different. I take it that means Nintendulator resets something before initiating every play, but Nestopia doesn't. Because Nestopia immediately starts playing when I load the NSF, I can't try playing the underground theme before anything else ever plays to see if it would still be different each time if playing it were the first thing the emulator did. Evidently what causes the effect is also something that's not wholly internal to the NSF as well, or, as Rahsennor says, it would presumably play the same way for every loop, no matter the player.

Anybody else can try this stuff too to see if they have the same results. Surely I'm not the only one who hears it, right?

In-game, the timing of the play routine, particularly with respect to whether a write hits before or after the period divider resets, may depend on the CPU load of the game logic. Sound effects also end up changing the channels' relative phase

Looking more closely at it:

1. Super Mario Bros. 3 writes $4007 and $4003 on every note, not just every loop.

2. The timing between this pair of writes varies by about 100 cycles (though with the same variation every loop). This might account for about ~2.5% difference in phase on the highest frequency notes used in the track. (Probably not the culprit, not strong enough.)

3. tepples suggested here that $4003/$4007 does not reset the state of the clock divider. This could account for much greater difference. If the pitch was the same, it could be up to 12.5% (1/8) off, but if the previous pitch was lower it could cause even wider variation (every octave down doubles the width here). This could potentially vary between loops.

4. Said before, but the triangle is free running and will have more or less random phase always, but I don't think it accounts for what you're hearing. (It's an effect, but not terribly strong compared to what the squares are doing.)


So, really if you're interested, I'd suggest digging into #3. The question I'd have for that is whether the clock divider eventually halts if it runs out while the channel is halted, or if it's always running, and thus every single note is subject to rather larger potential phase varation? The Visual 2A03 project might illuminate this. (Also, once determined, the information should be mentioned on the wiki, if it isn't already.)

This SMB3 track is an interesting edge case because it's using both channels identically; which is rather strange. Usually doublings have a a small difference in pitch for intentional chorus effect, or maybe a change of octave, but SMB3 is just doing the exact same thing on both.

You keep asking which emulators are accurate, which is not a fair question. Most likely nobody has tried to refine this very specific and subtle aspect of its behaviour against this very specific edge case. If you want to know the answer, make a test ROM that can expose the difference and test it on real hardware and emulators you'd like to know more about.


SMB3 itself is not a sufficient test. As mentioned, in-game there are a lot of variables, but even the NSF, which should be deterministic, can't have consistent timing between different hardware NSF players, or software NSF players. The NSF specification is not strong enough to specify exactly when the play routine should start like that. (You mentioned a test case by Blargg, but I'm not certain if it's supposed to be a test of this specific thing either.) You can't just record SMB3 from hardware and expect "accurate" emulators to sound identical, that in itself would probably be an unfair and incorrect test (similar to that strange pattern of memory initialization people used to use because it was measured that way on one particular NES). Even the idea that it should "change over time" is not necessarily correct for all reasonable timings-- things like this can often end up falling on some coincidental integer division of the timing loop, the change might be accidentally due to something else, etc.

Fixed a really goofy bug in my APU emulation, and now it sounds like this. Better?

This is definitely part of the solution - Mesen was resetting the clock divider on 4003/4007 writes, which is what caused SMB3 to always sound the exact same. Beyond this, I'm not quite sure what the problem could be (and it's really far outside my field of expertise!). I'm more than happy to implement a solution if someone figures out the cause, though.

I ran into issues with blargg's dmc-rates test and saw that subtracting 1 from the rate lookup table worked, but I don't understand why.
I'm putting this here because I see you did the same but with an explanation (DeltaModulationChannel.cpp - line 146), how does the real thing work?
Does the timer always decrement, even immediately after wrapping around? (I'd assume this goes for every other timer too, not just the dmc.)


Like this?

I didn't really ask which emulators are accurate overall, I asked if anyone knew of any that accurately reproduce the effect. I know that overall Nintendulator is less accurate than Mesen, at least according to the existing test ROMs, but Nintendulator handles this particular edge case better. And like I said, I don't know the first thing about programming so I have no capability of making a test ROM for this. If I were able, it's definitely the kind of project I'd devote some time to.

I assume you were talking to me in this paragraph, but Sour was the one who brought up the APU test ROM. I replied that if Mesen passes it, it just must not test what's necessary for the Mario 3 underground music effect.

I know there's no single correct sound. My own recording's first loop has several shifts in tone and then the second loop has little, so I know it doesn't necessarily change much all the time. But when an emulator's sound doesn't change much or at all over several loops, it's probably that the emulator is missing something.

Since I'm not a programmer and I'm entirely at the mercy of people who are to figure out and implement things I want in emulators, thank you for checking further into how Mario 3 works.


Sounds pretty correct to me, I'm happy to report! Please share what you did and any other information relevant to achieving this.