Castlevania random pause glitch

I've noticed a few instances in Nintaco where Castlevania will randomly pause as if the Start button were pressed. Google search results seem to suggest that it might be a bug in the actual game (see here and here). Might this be APU DMC related? I currently do not have an easy way to reproduce this, else I would have done some debugging.

If a game doesn't compensate for the NTSC DMC DMA clock glitch, Up occasionally leaks into the previous button, which is Start. Are you holding Up when this occurs? Do you occasionally get random right presses out of nowhere?

That's a good question. I vaguely remember this happening while walking up stairs, but I'm not 100% sure. I'll pay more attention to what I was pressing at the time if and when it happens again.

BTW, what can a game do to safeguard against this issue?

Read joystick twice, and if they don't agree read it again

Clever.

Or use this recently discovered method (which in hindsight is quite obvious, but nobody had figured it out before Rahsennor): viewtopic.php?f=2&t=14319

However, It's highly unlikely that any commercial game from back in the days would be using this method, although it's plausible that some might depend on it unintentionally (I think Rainwarrior mentioned some ROM of his where he didn't get the DMC glitch even though he didn't prepare for it.)

Also, ironically, because some emulators attempt to emulate the DMC glitch but don't do it 100% correctly, you may lose some emulator compatibility by using this method (you'll get the glitch even though it would never occur on real NES).

Yes, I accidentally used it in the original release of the 2A03 Puritans album compilation. Worked by luck because the NMI was simple and deterministic enough, and the controller poll happened to be done in there as well.

In fairness, though, it was hardware tested before release. I would have seen the "spurious right press" behaviour if it was happening, cause it'd cause the track to skip. When I noticed I'd forgotten to (intentionally) DPCM-safe my controller code though I was flabbergasted. I looked over and over for logic that might somehow suppress it, but I couldn't find any. (I updated the ROM and code on that website though, subsequently.)

Anyway, here's SMB3's version of the simple/standard version:

Though, due to some lack of thread safety on SMB's part with the NMI, a robot can keep changing the gamepad bits for every read to lock up the polling thread until the NMI crashes into it, allowing a very short TAS. (TBH given that you need a machine to do this input I wouldn't really even call it a bug.)

If zeroone didn't know about the DMC glitch, why would it be implemented in nintaco?

You have to specifically code the glitchy behavior in, no?

Yeah, unless you do the emulation at an extremely low level (not really practical except in FPGAs and such), at which point it should happen naturally.

I coded those parts so long ago that I simply don't remember the details any more. I mentioned the DMC glitch in the OP, which demonstrated that I had a vague recollection of it. And I didn't know if that was the cause or if it was an emulation issue, and it still might be the latter.

When I get a chance, I'll study how Castlevania polls for input to see if it is performing a double check.

If I recall correctly, wasn't Castlevania a port of an FDS game. Did the FDS hardware also suffer from this issue?

Also, I reviewed the Nintaco source and it is indeed emulating the glitch. But is there really any reason to do so? Do any games actually depend on this glitch being present?

FDS runs on a Famicom, which is NTSC and therefore has this clock glitch issue.

But I imagine that some FDS games later ported to cartridge might double-check on cartridge but not on FDS, particularly if the cartridge version used the DMC to replace the FDS wavetable channel. The first place to look for these differences is four well-known ports: Metroid, The Legend of Zelda, Kid Icarus, and Doki Doki Panic (which became Super Mario Bros. 2: Mario Madness).

I doubt it could be desirable for anything, but there's a pretty wide library of stuff, so it's hard to say for sure. I was about to make a smart-ass remark about games not caring if sprite DMA takes only 1 cycle to complete, but quickly realized that's wrong, but rare.. only Bigfoot and Garage Cart menu come to mind as doing a mid-frame DMA.

I wouldn't rule out a game relying on DPCM clock glitch for something, but as far as I can tell it's just a useless annoyance. Re-reading the controller though does take extra CPU time, and that certainly could affect something, if the game was that close to overflowing some kind of CPU time limit. Weird corner cases, stuff like that.

On a side note, I remember when I first heard about the DPCM clock glitch, Castlevania was one of the first games I wondered about. First because it's an early 3rd-party game using DPCM, and second because when you get hit, the game plays the HUP! sample and you lose control for a moment. While the sample is playing, the game doesn't care what button you're pressing (though I haven't tried pausing it then, maybe I'm wrong). I see 3 possibilities: 1) Konami knew exactly what they were doing, 2) the glitch affected the game design (wouldn't that be funny), or 3) they thought to use DPCM because they're ignoring the controller anyways. At any rate, I would be surprised if it did multiple reads of the controller.

If anything, a ROM misbehaving in an emulator the same way it misbehaves on hardware is good for indicating to the ROM's developer that the ROM needs to be fixed.


Does it care what buttons are pressed while drum samples are playing?

There were also two versions/revisions of Castlevania. Linear binary file compare isn't helpful for this, too many changes, so disassembly + manual comparison would have to be done.