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

What can I do about this error?

What can I do about this error?
by on (#29896)
The error: Out of range, bank offset > $1FFF!

I'm assuming this means I have too much code or something... But I thought I had a lot more space than what I have... A whole bunch of the nes rom has 0's in it...

One "fix" I've attempted:

Code:
.bank 0
.org $C000


That is basically above my constants section, which I have at the bottom of my code. Basically messages, palette defines, etc. Though that doesn't seem to work. Is there something I need to do when trying to reference that area?

by on (#29897)
expand your rom to 32k prg. i never figured out how to get past 16k with (i'm assuming) nesasm back when i used it. bunnyboy might be able to tell you.

by on (#29898)
$C000-$FFFF mirrors $8000-$BFFF, as far as I know; that's why you got that error.

by on (#29899)
Right now, the only "fix" I have done is to just comment out a bunch of my .db statements. Mainly the text ones in screens I don't need to see.

I also got rid of that .org $C000 as that makes it compile and not work. Heh.

So... Could it be that I have way too many .db's in there? I have quite a few messages I write to the player and use the .db to simplify the tasks. I'd be kind of amazed if I had too many instructions as the SMB1 disasm has like 4X the code my program does.

by on (#29900)
NESASM does everything in 8KB banks, so you just need to tell it to use more banks. If you have a section that is too big (for example if bank 0 had 10KB) then you can skip the next bank declaration (bank 1) and it should automatically overflow into there. I know that works for data, assume it works for code. Be sure to change your ines header to 2x 16KB prg too.


Code:
  .bank 0
  .org $8000
  (8KB code/data)

  .bank 1
  .org $A000
  (8KB code/data)

  .bank 2
  .org $C000
  (8KB code/data)
 
  .bank 3
  .org $E000
  (8KB code/data)

  .bank 4
  (8KB chr graphics)

by on (#29901)
Alright. We figured it out. I had used up my first 8KB bank from $C000 to $DFFF. I just needed to declare a new one starting at $E000

No problems now. :)

by on (#29912)
Hey, here's an idea.

Get a different assembler, preferably one that doesn't suck donkey balls.

by on (#29913)
I AM ERROR! lol :roll:

by on (#29914)
Quote:
Get a different assembler, preferably one that doesn't suck donkey balls.

You know, I get really tired of the non-technical content on this board. nesasm wins over others for a few reasons, two being that you can write examples as one source file, and that the source code is available to compile for any operating system. Until you, or any of the others who rip on nesasm every damn time it's mentioned, can offer an alternative, STFU.

Celius wrote:
You know, you should probably get a different assembler. NESASM is known for not being very good, so I reccomend getting one of the more common ones around here, such as WLA-DX or CA65.

Or even better, offer technical reasons about the best choice of assembler for a task. Saying that something is good/bad merely hides the technical reasons why that particular individual prefers one over the other. It's little use to know what you like/dislike, unless you share the reasons why. nesasm is apparently(?) hardwired for 8K banks, so if you are using larger banks/none, it will apparently require you to carefully separate your data. So if you're working on a larger project that doesn't use 8K banks, another assembler would be appropriate.

by on (#29915)
doppelganger wrote:
Hey, here's an idea.

Get a different assembler, preferably one that doesn't suck donkey balls.


Was the crude approach really neccesary? You could've said:

You know, you should probably get a different assembler. NESASM is known for not being very good, so I reccomend getting one of the more common ones around here, such as WLA-DX or CA65.

Also, the way you said it makes it sound like an attack or something, so the listener probably won't be thinking as much about how they should go get a different assembler as they will be about how they should ignore the vulgar post they just read.

EDIT:
blargg wrote:
Or even better, offer technical reasons about the best choice of assembler for a task. Saying that something is good/bad merely hides the technical reasons why that particular individual prefers one over the other. It's little use to know what you like/dislike, unless you share the reasons why. nesasm is apparently(?) hardwired for 8K banks, so if you are using larger banks/none, it will apparently require you to carefully separate your data. So if you're working on a larger project that doesn't use 8K banks, another assembler would be appropriate.


I'm actually starting to agree with you on the NESASM bashing. I know I've done my fair share of it, I will not deny that. I at least offered a little bit of an explanation why I don't prefer it. But bashing it every time it's mentioned is uncalled for. Saying you shouldn't use it because someone doesn't like it (or because it "sucks donkey balls") just is completely useless and uninformative.

And useless posts are getting rather annoying.

NotTheCommonDose wrote:
I AM ERROR! lol :roll:

by on (#29918)
blargg wrote:
nesasm wins over others for a few reasons, two being that you can write examples as one source file

I'll grant that. CA65 needs two source files: one .s file and one linker script file, but a sample linker script comes with the docs package.

Quote:
and that the source code is available to compile for any operating system.

So is CA65.

by on (#29920)
Well, the only reason I'm using NESASM is because I could get it to work and because it's my first program ever and the step-by-step tutorial on how to set things up was useful.

I took an assembly class last semester and we used MASM in there, so a lot of assembly-related concepts are similar here.

But anyway, as I had said, the issue's been resolved by using my second bank that spans from $E000-$FFF9. I didn't know about it until talking to bunnyboy.

by on (#29921)
Celius wrote:
You know, you should probably get a different assembler. NESASM is known for not being very good, so I reccomend getting one of the more common ones around here, such as WLA-DX or CA65.


Except as discussed in another topic, the only significant reason NESASM is not good is no temporary labels. Everyone claims it sucks, but have no technical reasons. WLA-DX and CA65 may be more common but using them would not have solved this problem. It likely would have created more problems related to code layout earlier, since setting those tends to be more tricky without examples.

by on (#29923)
bunnyboy wrote:
Celius wrote:
You know, you should probably get a different assembler. NESASM is known for not being very good, so I reccomend getting one of the more common ones around here, such as WLA-DX or CA65.


Except as discussed in another topic, the only significant reason NESASM is not good is no temporary labels. Everyone claims it sucks, but have no technical reasons. WLA-DX and CA65 may be more common but using them would not have solved this problem. It likely would have created more problems related to code layout earlier, since setting those tends to be more tricky without examples.


That was only an example of rewording a crude post, not actually what I wanted to let the person using NESASM know. I wasn't trying to establish that someone should switch assemblers, I was trying to establish that saying something "sucks donkey balls" is uncalled for, and that that person should've approached saying what they were trying to say in a more proffesional manner.

by on (#29924)
I am sorry, I missed your "what you could have said" part. I actually pulled it out of blarggs post, my bad!

by on (#29934)
I don't bash nesasm every time it's mentioned, I bash it every time it causes problems for somebody because of the weird way it handles things. Which is, coincidentally enough, most of the time I see it mentioned.

I can offer two very good choices over nesasm: x816 and ca65. Why? Because x816 doesn't have the weird habit of partitioning everything into 8k banks like nesasm does, which is only useful IF you're working with a mapper that does just that. Not only that, it also handles 65816 code, which is perfect in case you want to migrate over to the snesdev scene. One major disadvantage, though, is that it's apparently only available for DOS.

ca65 is probably an even better choice, despite the fact that it spits out object files (but the linker can make binaries out of those, anyway). It was written for a more general 6502 and 65816 crowd, and can handle not only regular and bankswitched code, but can easily handle other platforms that use 6502 or 65816 processors (perfect for me, since I also dabble with the Atari 2600 and the Commodore 64). Not to mention the fact that it doesn't impose limits on the end user except what his/her machine can handle (and the target platform's). And as someone pointed out earlier, it is available for many modern operating systems besides DOS.

You're right, of course, I probably could have worded my post more tactfully. But over the years, my tolerance for stupidity has reached an all-time low, and based on what I've heard, nesasm does a lot of stupid things, which is most likely why I went off and posted rudely. There's just this part of me that expects things to work the way they're supposed to. And nesasm, well...doesn't. And this is hardly the first time I've read about somebody having problems with it.

by on (#29940)
Quote:
I don't bash nesasm every time it's mentioned, I bash it every time it causes problems for somebody because of the weird way it handles things. [...] based on what I've heard, nesasm does a lot of stupid things.

Apparently it is hard-wired for an 8K bank size, which isn't weird, but is somewhat stupid given that many NES mappers use 16K and 32K banks. I bet it was originally written for another system whose bank size was always 8K (PC Engine?).

So a more informative reply would have been: nesasm is hard-wired for 8K banks, so you'll have to manually break your code and data into 8K or smaller chunks and manually set their addresses, or use a different assembler. I recommend ca65.