I spent a bunch of time trying to track down what I thought was a triangle channel linear counter emulation bug in the new APU that I'm writing, but I think it's actually a subtle music bug in Castlevania 2, but I can't actually verify on a real NES so I'm not sure.
What I *think* has happened is that CV2's linear counter, at least for the initial town music, was authored against frame counter mode 0, but the game actually initializes with mode 1. As a result, the length counters for the triangle notes are all just SLIGHTLY too long, and rather than having some rhythm to it, it turns into a bunch of long holds. Seems like it was clearly intended to have individual notes, and maybe they switched to mode 1 as a mistake or a last-minute change and didn't notice that this bassline got broken. Oops!
Basically, with mode 0 (i.e. "not what the cart clearly loads into $4017") you get a triangle channel that sounds like this: https://www.youtube.com/watch?v=H58lhgcc-nk
But with its actual mode 1, it instead sounds like this: https://www.youtube.com/watch?v=TaMP6l2UqLw
(note the held notes in the bass at the beginning).
The latter is definitely the behavior I see in both Mesen and Nintendulator (and my ancient emulator code that was using Blargg's awesome libraries, once I fixed it so that it actually sent writes to $4017 to the APU code instead of just not doing that, whoops). My new APU was doing it right, but I was comparing against my old code's output which was wrong. That's what I get for trusting code I wrote 10 years ago and assumed that the new code was wrong because, again, clearly authored to have pauses.
Anyway, has anyone else noticed this? Does this actually happen on a real NES or is there something weirder at play?
The NSF that I have for Castlevania 2 exhibits the same behaviour as in this video. Details of that NSF are below. I do not remember where I got it, possibly from Zophar's Domain or some other place:
Code: Select all
Castlevania 2 - Simons Quest.nsf Start track: 1 of 51 NTSC Speed: 60.002400Hz (16666) PAL Speed: 50.007501Hz (19997) Dendy Speed: 50.007501Hz (19997) Banks: 00 00 00 00 00 00 00 00 Load/Init/Play: 8000/BC0C/967D MD5: C06833E2A351BE71B8B5B2B6AD31B9DB
Code: Select all
Castlevania_2.nsf Start track: 1 of 9 NTSC Speed: 60.002400Hz (16666) PAL Speed: 50.007501Hz (19997) Dendy Speed: 50.007501Hz (19997) Banks: 00 01 02 00 03 00 00 00 Load/Init/Play: 8000/818C/967D MD5: A483E0263B6558704BDD121B8CFBF99F
So, to put an end to the nonsense, here's my own recording taken a few minutes ago. I did not care about the video output (re: deinterlacing etc.). Classic non-modded front-loading NTSC NES, composite/RCA out. If you want an HDMI-based recording from a RetroUSB AVS in comparison, just ask, but that's an FPGA-based system.
Please do not forget the fact that Castlevania 2 was originally a Famicom Disk System title, and its music "ported" to work on pure cartridge-based NES units. It would not surprise me if there was a mistake made in the process (example of similar mistakes).
rainwarrior or someone else more audio-savvy will probably comment on the more technical details of the counter and/or look into what's going on, if applicable.
The first video was definitely nsf playback, I only linked it as an example of the incorrect behavior I was hearing in my old buggy version (video was not from my emu, just one I found on YouTube), sorry if that wasn’t clear.
Anyway, I just thought it was an interesting bug(?) in CV2 that I’d never seen mentioned anywhere, and thought I’d mention it
(Also, that’s a good note on it being a port - I’d forgotten that - and this totally seems like the kind of subtle thing that could slip through during a port and not get noticed)