Rather than insult an emulator and blow it off, why not figure out why this situation is happening? Odds/chances are it's something with your ROM (header information being wrong is likely), so just because it works in one emulator doesn't mean it's going to work in others, or even on actual hardware. There are people here who can look at the source to Nestopia (e.g. me) and provide insights. I can also provide actual references to Nestopia code if necessary.
The "Corrupt file" or "Corrupt or Missing file" messages can come from several different places in Nestopia depending on what you're trying to load; the actual const name for this is RESULT_ERR_CORRUPT_FILE. I'll cover cases in the code that I can read:
* If using Options -> Database -> External, and the external .xml database file can't be read or parsed properly. Source: source/core/NstImageDatabase.cpp
* If there's a corrupted save state file associated with the ROM you're opening/loading. Source: source/core/NstMemory.hpp
* If there's a .UPS patch being applied alongside the ROM you're opening/loading, and the UPS file is corrupt in some way. Source: source/core/NstPatcherUps.cpp
* If there's an FDS BIOS file provided via Machine -> External -> Disk System -> BIOS ROM File that can't be properly used. It supports both raw binary BIOS dumps as well as .NES-based dumps, so this would be in the case where NES header auto-detection fails *and* there's something anomalous with the PRG (hard to explain from the code). Source: source/core/api/NstApiFds.cpp
* If there's a corrupted save state file associated with the FDS game you're opening/loading, particularly if the number of disks, or sides of disks looks corrupted/wrong. Source: source/core/NstFds.cpp
* Some stuff relating to a "Tracker Rewinder", which doesn't mean anything to me. Maybe some unique expansion device? Source: source/core/NstTrackerRewinder.cpp
* Some stuff relating to a "Tracker Movie", which doesn't mean anything to me. Source: source/core/NstTrackerMovie.cpp
* Some stuff in NstStream.cpp -- this looks like it pertains to file I/O -- where on read, seek, length calculation, and write operations such an error can happen. My guess would be situations where reads failed due to hitting EOF early (i.e. file is too short), etc. Source: source/core/NstStream.cpp
* If loading a .UNIF file, the 32-bit ID number/tag/field in the file is numerically less than the 32-bit length field in the file. Source: source/core/NstCartridgeUnif.cpp
* Some stuff relating to "Savers", which I don't quite get either; maybe save-state related, but not really? I don't know. Source: source/core/NstState.cpp
* If there's an .IPS patch being applied alongside the ROM you're opening/loading, and the IPS file is corrupt in some way. Source: source/core/NstPatcherIps.cpp
* If when loading a .NES file,
the 16-byte NES header is incorrect/wrong. There are several scenarios that can trigger this, apparently. I'll outline them below. Source: source/core/NstCartridgeInes.cpp
a) If the file being loaded can't be read from disk properly (i.e. a hardware issue, corrupt filesystem, OS problem, file permissions, major software bug (corrupt memory), etc.) ("invalid param")
b) If the file header is less than 4 bytes in length, or the "N", "E", "S", or 0x1a NES header identifier bytes are wrong ("invalid file")
c) If passing (b) above, yet the file header is less than 16 bytes in length ("corrupt file")
d) If the original NES file format is used (this is the most common format, i.e. not
NES 2.0), and any header bytes 10 through 15 (i.e. the last 6 bytes of the header) contain non-zero values ("bad file header")
Most likely your situation is one of the above (a through d), as a direct result of your resulting ROM file not linking/being generated properly due to previous warnings or other errors. Alternately, if you're assembling your binary using a batch file and you blindly do something right after assemble-time like
copy /b header.bin + mygame.bin > mygame.nes and mygame.bin is empty or non-existent, then it's possible you could end up with a 16-byte file containing just a NES header and no other content. There are tons of possibilities, I can't cover them all here. In that example, though, you need to make your batch file honour exit code (in batch files this is called
ERRORLEVEL) statuses so that if the assembler or linker fails with a non-zero exit code, the script stops executing immediately + tells you something went wrong.
There also may be other scenarios/error conditions I missed (I was doing
grep -r -i corrupt . in the source), but honestly I'd have to see the actual file to be certain.
dougeff's point about PRG/CHR bank counts needing to be a power of 2 is valid, however I don't think this would cause a "corrupt file" error in Nestopia. I believe instead the result would just be general breakage (game doesn't load or crashes due to wrong bank being loaded last, resulting in wrong vector locations, etc.). There's no easy way to debug this situation, though sometimes View -> Image Info or View -> Log File can help. If it's 6502 code crashing or misbehaving, FCEUX makes this easier given its debugger capabilities. FCEUX is a better emulator overall to use for development, but once you get that working, you should make sure your game loads on several emulators -- including Nestopia. We can help you with all of that if asked.
