Originally, I owned the PRG0 version of "Castlevania". Both times I played it, it crashed in the Grim Reaper stage.
I found out that this is a glitch in the PRG0 revision:
https://tcrf.net/Castlevania_%28NES%29So, I got the PRG1 version.
However, this game crashed as well. Not in the Grim Reaper stage, but right before I could enter the door to the hallway that leads to Frankenstein.
It was basically the same effect as in the PRG0 version, only in another stage.
So, is there any knowledge on
this glitch?
(It didn't happen right away. I've lost to Frankenstein several times, so it was probably the fifth time or so that I entered the door.)
First make sure it really is the PRG1 version, and not just a misnamed copy of the PRG0 version. Getting the SHA1 hash of the PRG data can help here.
A misnamed copy? Something like that actually exists?
How shall I check the hash?
Grab a good hex editor, like
HXD.
Cut off the iNES header, which is the first 16 (0x10) bytes of the file, then save the rest as a .PRG file.
Use your favorite hash checking tool, such as
HashCheck (site down at time of post), or unix command line tools like "sha1sum".
According to Bootgod's database, PRG0 should have a hash of EE09B857C90916EDD92A20C463485A610B0A76FD, and PRG1 should have a hash of 3DCB69A8C861C041AEB56C04E39ADF6D332EDA3A.
If you're already using HxD, you can also use it to generate hashes and compare files.
Dwedit wrote:
Grab a good hex editor [...]
Erm, you do realize that I'm talking about the actual physical cartridge and not just the ROM file, right?
The bug happened when I actually played on an NES. So, unless you know of an instance where the actual PCB had a wrong label, we can be 100 % sure that my cartridge is the PRG1 version since I opened it and checked it specifically for that very reason.
There's lots of things that can cause a NES to crash, such as problems with the cartridge slot and stuff. People have seen all kinds of glitches on a real NES. For example, I've seen Gremlins 2 have CHR glitches, and fail to play the ending animation correctly (probably due to a failed sprite 0 hit).
Maybe the game was still buggy even after one revision. Did you get a photo of the crashed game? What the screen looks like gives clues as to what happened.
But anyway, back to PRG0 vs PRG1. The other way to identify PRG0 vs PRG1 is by Game Genie. If the game won't boot with the code ATOKIOOZ, you have PRG0, otherwise if it works fine, you have PRG1.
I have PRG1 because it says so on the board. I don't need a Game Genie or anything like that. I opened the cartridge and had a look. It is PRG1.
So, about the glitch:
I know that the graphics might be garbled if the game's contacts don't connect properly. But is it actually possible that the game just stops playing, with the still screen visible and the sub weapon in the inventory slightly relocated, after it has played fine for an hour without the game itself having a glitch and just this one cartridge being faulty? Also, no other game ever did this. And the crash looked suspiciously similar to the problem in the PRG0 version which is officially declared a glitch.
Is this crash reproducible, or might it have been the result of dirty power? Super Mario Bros. would crash on me if I bumped the controller connector wrong. Years later, when I was working on hot-swap to test a dual Zapper game on a PowerPak (whose menu software doesn't support the Zapper), we ended up concluding that this was due to a voltage sag related to inability to handle inrush current.
I once had a Pulseman cartridge where stage 1 worked just fine, stage 2 was glitched up and stage 3 was fine only in the initial battle (then went glitched afterwards). So yeah, you never know what can break.
In my experience these kind of crashes most commonly happens due to loose/oxidised cartridge connection nowadays. Just bumping the main unit is enough to crash the more dirtier carts I have, while I can play football with my Famicom without my NIB carts to be affected.
I would try scrubbing away on the cart pins at least.
So, you all think that it's the cartridge? Unlikely that it's the programming code?
You could buy a Kazzo and dump it to see if it's identical to the [!] version.
Erm, o.k., now it gets really strange.
I understand the necessity to check a ROM file against the hash value to see if I actually have the good version.
By why on earth should I check if my original cartridge has the contents of this very cartridge? What do you expect? That my physical cartridge turns out to have the code of overdump number 3 or bad dump 1?
Or do you think that the chip label is wrong and that I actually own version PRG0?
In this case, I must ask: Has this ever happened? With all the cartridges that were collected by the GoodNES guy, Bootgod or any collector on this board or any other NES community in existence: Has there ever been a case where the chip on the game says PRG1, but it turned out that the code inside is actually the version for PRG0?
If yes, please show me where this instance is documented.
If no, what revolutionary things do you think I will discover when I dump an original NES cartridge of a well-known game?
DRW wrote:
If no, what revolutionary things do you think I will discover when I dump an original NES cartridge of a well-known game?
That your ROM is damaged.
And this is actually a likely thing? The ROM?
I've heard of dirty or damaged contacts, but you really think the ROM might be damaged in a way that it works fine for 99.9% of the time, but then it creates a glitch that looks exactly like a glitch that was actually part of the regular ROM code of PRG0?
I have a Super Mario Bros. 2 cart that's damaged either in the ROM or in the RAM, I'm not sure which, but it has garbage blocks at various places in the level.
And you're sure it's not the contacts? I remember one cartridge that showed garbled graphics and when I temporarily corrected its location in the NES, i.e. established a better connection between cart and NES, the graphics were o.k. until I removed my finger again.
I'd say if you used a frontloader NES it's probably the contacts. I've had issues frequently where graphics became garbled suddently or the game would crash, even though it worked fine for 20 minutes. The frontloader NES connector is just really, really terrible. This do not happen with toploaders or famicom (even using a NES->FC adapter).
It's also likely some bugs were left in PRG1.
I'd say it's extremely unlikely that your ROM chip god damaged.
The thing is that this never happened with any game ever on my NES. Only with "Castlevania", the game that has such a bug hardcoded into its PRG0 version. But on the other hand, there's no single report about this bug appearing in the PRG1 version.
I've never seen this glitch and I played many versions of the game many times. SCN PAL version as a kid (I'd guess it was based on US PRG1 since PAL releases generally come out later than USA), Japanese re-release (the one with easy mode, probably also based on US PRG1) and FDS version (I guess the bug isn't applicable in that one though). I'd say it's unlikely that it's the glitch, but who knows.
Even if all other of your other games are fine it could still be bad pins on that particular cart. Happens all the time for me when I get new carts.
O.k., if the issue happens again, I'll make a photo. Maybe this will show whether it's a glitch or contacts disconnection.
DRW wrote:
O.k., if the issue happens again, I'll make a photo. Maybe this will show whether it's a glitch or contacts disconnection.
I'll be impossible to tell: If the miscontacts affects only PRG lines this have no graphical effect. Just one miscontact on one single PRG line for a very short time is enough to crash the game. Unless we could spy the PRG bus somehow, but on real hardware this is very hard to do.
However, it is not unlikely at all some bug remains in PRG1 and was fixed for the PAL and newer JAP release. Just saying.
Bregalad wrote:
I'll be impossible to tell
As far as I remember, the sub weapon was dislocated when the game crashed. I.e. it wasn't in the red border anymore, but some pixels to the left. Maybe anomalies like this are enough for an expert to confirm that it's a programming glitch and cannot stem from incorrect contacts.
DRW wrote:
As far as I remember, the sub weapon was dislocated when the game crashed. I.e. it wasn't in the red border anymore, but some pixels to the left. Maybe anomalies like this are enough for an expert to confirm that it's a programming glitch and cannot stem from incorrect contacts.
Then it's definitely a bug (assuming other sprites weren't affected). Bad contacts can corrupt graphics, but they cannot move sprites on the screen, as OAM is internal to the PPU and not affected by cartridge contacts in any way. Only if the program does sporadic $2004 writes due to bad PRG contacts could such a thing also happen, but it's much less likely to work without corrupting other sprites.
But wasn't other sprites affected as well?
I suppose it could be the glitch after all. How often does it happen for you?
Bregalad wrote:
Bad contacts can corrupt graphics, but they cannot move sprites on the screen, as OAM is internal to the PPU and not affected by cartridge contacts in any way. Only if the program does sporadic $2004 writes due to bad PRG contacts could such a thing also happen
Or if the game does a scroll split for the status bar and fails to keep doing the split after it, and the sprites are no longer aligned with the new incorrect status bar position.
Bregalad wrote:
DRW wrote:
As far as I remember, the sub weapon was dislocated when the game crashed. I.e. it wasn't in the red border anymore, but some pixels to the left. Maybe anomalies like this are enough for an expert to confirm that it's a programming glitch and cannot stem from incorrect contacts.
Then it's definitely a bug (assuming other sprites weren't affected). Bad contacts can corrupt graphics, but they cannot move sprites on the screen, as OAM is internal to the PPU and not affected by cartridge contacts in any way. Only if the program does sporadic $2004 writes due to bad PRG contacts could such a thing also happen, but it's much less likely to work without corrupting other sprites.
No, that means the screen was no longer split, and it hadn't updated the horizontal scroll at any time since it last rendered the playfield. Any crash would do that.
No, since he said the subweapon was outside of the red rectangle, and both the subweapon and the red rectangle are sprites. He might have described it badly, though.
Quote:
How often does it happen for you?
He said this happened once, so definitely not "often".
Oh, I was thinking Castlevania 3, where it's a background and not a sprite. You're absolutely right.
Castlevania would crash on me if I had the potion invincibility item and going through a door at the same time. This most frequently happened in the door before Frankenstein, probably because that item drops there. If you timed it right the game consistently locks up while you are going through one of the stages of invincibility.
Yes, in my case, it was the same door.
I don't remember if I had the invincibility item, though. How can you get it right before that door?