NESASM Bugs?

[FyberOptic]

Hiya folks, maybe somebody can shed some light on something for me. I had an idea today for running smaller roms via a single eeprom, using ram in place of the CHR rom, saving me from having to program two different chips. To test my idea, I've been patching a copy of the Japanese version of Galaga (16kb PRG) to include the CHR rom in the PRG rom, which will be copied into the CHR ram on execution by replacing the reset vector with my own. But along the way, I had a little hurdle.

The problem revolves around my use of: lda ($00),y

Whenever I use this in my code during the transfer process, the assembler generates the opcode $B9, when it really should be producing $B1. $B9 is "LDA $aaaa,Y", which obviously has a much different effect, and was the reason for my hour long head scratching!

Using ".db $b1,$00" works like a charm, btw, so this is how I know my code is good to go. The CHR rom transfered over and it jmp'd to the real reset vector, and I was playing Galaga from a single rom.

So as much as I like NESASM, does anyone else know of the problem I've come across? Are there other opcodes it generates incorrectly as well? Am I, unfortunately, going to have to use a totally different assembler? I haven't been using it for too long, and since I'm fairly new around here, I figured that made me newbie-qualified to ask in this section. Thanks in advance!

[Disch]

I know NESASM likes to use brakets instead of the standard parenthesis

so you probably want to be typing:

lda [$00],Y


But really -- NESASM is all around lame. I'd really recommend picking up ca65 or even x816. They're pretty much superior all around once you get used to them.

[Memblers]

That same problem was what stopped me from using NESASM years ago. When someone is learning 6502, and an assembler does stuff like that (without erroring or even warning), it really screws things up. I guess it'd do the same thing with all indirect opcodes.

I seem to recall also having big problems with little things like:

lda blah, y
Wouldn't work, it requires
lda blah,y
instead. But it gives some cryptic error message IIRC.

I think I normally don't add a space like that anymore, but that's another one of those things that can sneak up and frustrate an otherwise fine program in development. Most assemblers will just work either way.

[FyberOptic]

Well I'll be darned, the brackets work fine. I certainly wish it would have told me it didn't like parenthesis! And thanks for the info, fellows.

The last thing in 6502 assembly I did was with that DCC6502 compiler I think, but I believe there was something about it I thought was strange or lacking or I couldn't get used to right away, so I found out about NESASM and have been messing with it ever since, especially since it gave me a familiar feel of working in NASM (8086). Hopefully I haven't ingrained any of NESASM's tendencies into my brainmeats to the point that one of these others you mentioned would be hard to get used to.

Out of curiosity, is NESASM still being developed?

[CartCollector]

I'm having my own problem. I've coded my palette like this:

Palette:

.db #$0f ;black
.db #$00
.db #$00
.db #$00 ;Fill with BRKs because I don't need
.db #$00 ;the background (yet)
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00
.db #$00 ;Sprite start (transparency)
.db #$38 ;Light yellow
.db #$28 ;Dark yellow
.db #$30 ;White

NESASM says that each data byte is a "Syntax error in expression!".

[kyuusaku]

Try removing the #, .db isn't an instruction.

[commodorejohn]

Ha, that brackets/parentheses thing had me going for so long...

I think it stems from the fact that NESASM originated as a 65C02 assembler, and by the time WDC had gotten around to the C02, they'd come out with their new official syntax, which used the brackets for indirect instructions. Still, pretty silly not to include backwards compatibility.