It is currently Thu Dec 13, 2018 9:54 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Wed Mar 28, 2018 12:44 pm 
Offline

Joined: Sun Mar 25, 2018 9:02 pm
Posts: 11
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'


Top
 Profile  
 
PostPosted: Wed Mar 28, 2018 12:49 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 518
Location: Central Illinois, USA
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.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Mar 28, 2018 1:57 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2354
Location: DIGDUG
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?

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Mar 28, 2018 2:47 pm 
Offline

Joined: Sun Mar 25, 2018 9:02 pm
Posts: 11
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


Last edited by theinfamousmrmeow on Thu Apr 05, 2018 7:56 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Wed Mar 28, 2018 3:03 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2354
Location: DIGDUG
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

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Mar 28, 2018 5:19 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3725
Location: Mountain View, CA
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.


Top
 Profile  
 
PostPosted: Wed Mar 28, 2018 6:34 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 6:53 pm 
Offline

Joined: Sun Mar 25, 2018 9:02 pm
Posts: 11
@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.


Last edited by theinfamousmrmeow on Thu Apr 05, 2018 7:55 pm, edited 5 times in total.

Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:00 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2354
Location: DIGDUG
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.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:03 pm 
Offline

Joined: Sun Mar 25, 2018 9:02 pm
Posts: 11
Sorry, just realized my typo, it is pretty dark in here. :shock:

I will continue to call you dougelf, then!


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:04 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2354
Location: DIGDUG
Oh wait, I'm confusing you with @robocop.

Sorry. My last comment maybe makes no sense. Moved it to the relevant topic.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:09 pm 
Offline

Joined: Sun Mar 25, 2018 9:02 pm
Posts: 11
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.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20870
Location: NE Indiana, USA (NTSC)
Either that or a furry version of your current avatar: Dig Dog.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group