Value constants in NESASM3

[sempressimo]

I can create constants in NESASM3 with no issues when they are pointers:

SPRITE_RAM = $0200
SPRITE_RAM_ITEMS = $0210
SPRITE_RAM_ENEMIES = $0218

But values are failing like this:

DIR_LEFT = #$01

How can I do those?

[tokumaru]

How can I do those?

Normally you don't, because when you look at the code you can't tell whether instructions are using immediate addressing or not, and this can be confusing as hell to debug. The common thing to do is:

Code: Select all

DIR_LEFT = $01
;(...)
lda #DIR_LEFT

That being said, it may be possible to do what you asked (but let me say this again: you shouldn't do it!) for with EQU, but I haven't tested.

[sempressimo]

Got it thanks!

Anyhow I see you are saying using constants for values is not recommended even when using the proper syntax?

[tepples]

There's nothing wrong with doing, say, lda #PLAYER_JUMP_SPEED.

[sempressimo]

Great got that working now, thanks all.

[tokumaru]

Anyhow I see you are saying using constants for values is not recommended even when using the proper syntax?

The problem is, if you're declaring pointers and values (as you call them) that look exactly the same, you won't be able to tell them apart later on when debugging the code you wrote some time before. You'll have to constantly go back where they are defined to see what you're dealing with.

The truth is that to the assembler, all symbols are numbers, there's no such thing as pointers or values, it's how and where you use those numbers that makes a difference. If EQU does indeed allow you do CONST EQU #$01, and NESASM is anything like ASM6 (the assembler I'm most familiar with) in this regard, it will not actually be storing the number $01 into CONST, it will actually be replacing all instances of the text "CONST" by the text "#$01", which will be evaluated in place as if you were writing "#$01" each time.

So, in my opinion, it's better to treat all symbols like what they actually are: numbers, and apply modifiers and such in the place where you're using them, like you would with literal numbers.

[rainwarrior]

Forgetting the # is such a common problem with 6502 beginners. I still do it on rare occasions, myself.

I try to mentally think of the # as part of the instruction, rather than the operand, i.e. I pretend it was LDA# value, not LDA #value. (Similarly in C/C++ I like to write void* p and not void *p.)

In some assemblers, like ca65, you could do something like .define VAL #25 and then use it like LDA VAL, and it would be including the #, but IMO this hides the real nature of the instruction and makes the code harder to follow, so I don't recommend it.

[DoNotWant]

(Similarly in C/C++ I like to write void* p and not void *p.)

Isn't void* p the correct thing to do in C++?

[rainwarrior]

Both are considered valid styles. I prefer to keep * with the type, but I most often see it with the variable name. I think the main reason people tend to use the latter is how the * type modifier doesn't persist across multiple variables declared on the same line, e.g.

Code: Select all

void *a, *b;
void* a, *b; // looks weird
void* a, b; // bad: b is not a pointer

Edit: Stroustrup has something to say on the matter: http://www.stroustrup.com/bs_faq2.html#whitespace

[thefox]

"int *foo" is more idiomatic in C, I find, and "int* foo" is more idiomatic in C++. But as has been said, they're functionally equivalent.
[/ot]

[zzo38]

In C, due to such confusion, I never declare more than one pointer on the same line like that, nor declare a pointer and non-pointer together. I put spaces on neither side. Note that if you write something like int*x=y; then it is the value of x that is being initialized, not the value of *x, so putting a space before the asterisk looks wrong due to that.

The # is a part of the instruction, kind of; the addressing mode is a part of the instruction so if it is ,X or ,Y addressing that would really be the part of the instruction too. Whether or not the assembler needs a space before # may depend on the program you are using.

[hackfresh]

If the assembler is case sensitive then then a style convention would always make it obvious but bit more tedious to type I guess.

You could use post-fixes like so to make it obvious.

CONSTANT_C = #$01
MYVAR_Z = $01
MYVAR_M =$0400


or

CONSTANT = #$01
zeropage_z = $01
memory_m = $0400


But I guess this still has the problem of if you messed up the initial definition of the variable you might get stuck debugging for longer.