This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Address Size Mismatch in CC65?

Address Size Mismatch in CC65?
by on (#215922)
Hello forums! I'm pretty new to NESDev. I inherited a codebase on a project, and it has been pretty rough going. I'm getting CC65 to actually compile, but it gives me a corrupt .nes file, and I'm assuming its related to these warnings.

I can see where these are defined in crt0.s under zeropage, but I'm not fully understanding what "absolute" means.

Can anyone shed any light on this? I'm just lobbing grenades into the dark here. Thanks for your time!

Code:
ld65: Warning: Address size mismatch for `_MUSIC_NUM': Exported from crt0.o, crt
0.s(85) as `zeropage', import in main.o, main.s(21) as `absolute'
ld65: Warning: Address size mismatch for `_MUSIC_NUM': Exported from crt0.o, crt
0.s(85) as `zeropage', import in title.o, title.s(23) as `absolute'
ld65: Warning: Address size mismatch for `_PRGBANK_LO_TMP': Exported from crt0.o
, crt0.s(82) as `zeropage', import in main.o, main.s(20) as `absolute'
ld65: Warning: Address size mismatch for `_SFX_CH': Exported from crt0.o, crt0.s
(90) as `zeropage', import in title.o, title.s(24) as `absolute'
ld65: Warning: Address size mismatch for `_edes_y': Exported from main.o, main.s
(231) as `zeropage', import in enemies.o, enemies.s(37) as `absolute'
ld65: Warning: Address size mismatch for `_spawn_list': Exported from game.o, ga
me.s(2030) as `zeropage', import in enemies.o, enemies.s(60) as `absolute'
Re: Address Size Mismatch in CC65?
by on (#215923)
I'm assuming those variables are declared in your zero page segment? (with something like
Code:
#pragma bss-name (push,"ZEROPAGE")
?)

When you declare them and use them elsewhere, you need to mark them as zero page in their declaration with a pragma:

Code:
extern char MUSIC_NUM;
#pragma zpsym ("MUSIC_NUM");


That said, I don't think that would cause a completely corrupt rom -- it would likely just use slower absolute instructions instead of the shorter/faster zero-page instructions.
Re: Address Size Mismatch in CC65?
by on (#215925)
Quote:
zeropage...absolute...but I'm not fully understanding what "absolute" means


a page refers to the high byte of a 16 bit address. If the upper byte is zero (zero page), the processor can refer to that address using 1 byte rather than 2 bytes, thus shrinking the required ROM space for that instuction.

a5 01 = load from 0001 "zero page"
ad 01 00 = load from 0001 "absolute"

Both of these are identical, but the first needs 2 bytes rather than 3.

What is corrupt about the ROM?
Re: Address Size Mismatch in CC65?
by on (#215926)
Oh I see, thanks for that! I wasn't sure that it would cause corruption, but I didn't know enough to say it wouldn't, so thanks!

I'll put marking them with pragmas in my todo pile, thanks for the tip.

So it turns out, Nestopia is terrible, and FCEUX loads the ROM without any issues. Thanks for your help!

edit: That's awesome, thanks for the great explanation of zeropage, not confusing after all.

Nestopia wouldn't give any more specific error message than Corrupt Rom.

Edit: I do not actually think anything bad about NEStopia! I realize of course that I am the terrible one :D
Re: Address Size Mismatch in CC65?
by on (#215927)
I bet the header indicates the wrong # of banks.

Also, the number of banks should be a power of 2. 1,2,4,8,16, etc
Re: Address Size Mismatch in CC65?
by on (#215930)
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.
Re: Address Size Mismatch in CC65?
by on (#215933)
theinfamousmrmeow wrote:
So it turns out, Nestopia is terrible, and FCEUX loads the ROM without any issues.

Nestopia is certainly not terrible, so if it says something is wrong with your ROM, there probably is something wrong with your ROM. FCEUX being able to "fix" whatever problem there is on the fly doesn't change the fact that the problem is there.

FCEUX is actually the least accurate among the most popular NES emulators, it just happens to have an awesome redeeming quality: its debugging tools. So, don't go around blindly trusting whatever FCEUX does and dissing every other emulator, because that approach will almost certainly get you in trouble when you move on to actual hardware.
Re: Address Size Mismatch in CC65?
by on (#216417)
@douggelf: I've been gone for a few days because I've been trawling your tutorials and resources, trying to further understand your advice with banks here. Thanks for those resources!

@goitsu: I apologize for my overflippancy! I did not mean it! NEStopia has been my emulator of choice for years. I foolishly assumed my intended tone came through. I absolutely would like to further my understanding of what is happening here. I do realize of course that if NEStopia doesn't like something I'm giving it, I am at fault.

This is some great information, thanks for putting this together.

I am assembling using a pretty crude batch file I wrote, and I am doing so very blindly, with really very little checking to see if anything has gone wrong. I will follow the train of thought you laid out here, thanks!

@toku: I apologize! I don't think anything untoward about NEStopia, it has always been my favorite emulator.
I am learning that FCEUX may be overly permissive, thanks for your insight.
Re: Address Size Mismatch in CC65?
by on (#216418)
By the way.

It occurred to me that you could remove all problems with linker labels by removing them entirely (from nes.cfg) and hard coding their values into the reset.s file (the only file that wants to know stack sizes).

Good luck.

Quote:
@douggelf


I quite like that. I wish I had called myself doug elf.
Re: Address Size Mismatch in CC65?
by on (#216419)
Sorry, just realized my typo, it is pretty dark in here. :shock:

I will continue to call you dougelf, then!
Re: Address Size Mismatch in CC65?
by on (#216420)
Oh wait, I'm confusing you with @robocop.

Sorry. My last comment maybe makes no sense. Moved it to the relevant topic.
Re: Address Size Mismatch in CC65?
by on (#216422)
I did call you doug elf, I fixed it as you were posting. I feel better that RoboCop did as well. We will petition to have your name officially changed.

Asynchronous communication is funny.
Re: Address Size Mismatch in CC65?
by on (#216424)
Either that or a furry version of your current avatar: Dig Dog.