Assembler Decision

[Memblers]

And the NESASM v3.0 is just an EXE, no docs or source, so whoever would want to fix any remaining issues/bugs will have to start back at v2.x.

Source has been at http://nespowerpak.com/nesasm/nesasmsrc.zip for at least 1.5 years. Others recompiled it for Mac etc.

Ah cool, so it is. And the docs even were updated. I only had grabbed the zip with the EXE (and that's what most people would link to), so it would make a lot of sense to have all that stuff together in one file. The history.txt file only shows one change in it though, regarding line length (I remember hearing about that now, but that's one bug I had never ran into myself).

[tokumaru]

The history.txt file only shows one change in it though, regarding line length (I remember hearing about that now, but that's one bug I had never ran into myself).

Yeah, I remember someone saying this problem was fixed... but what about the others? Looking at past threads I found that at least one version of NESASM failed to report branches out of range and invalid addressing modes, generating corrupt binaries instead. That's awful, and will have a person pull all the hair from their heads when trying to debug a program that still assembled under these circumstances.

Personally, even if these bugs were corrected, I'd rather stay away from an assembler with a history like this. It's almost like the default option is to not report any errors and let the user think everything is alright when this obviously isn't the case.

[3gengames]

Not sure about you guys but I have had branches out of are errors when I first started so I would think it's fixed in NESASM3.

[ibeenew2]

Looking at past threads I found that at least one version of NESASM failed to report branches out of range

Fixed many years ago, possibly a decade. v2.51 correctly reports the error and it is at least 5 years old. People using ancient versions instead of new ones is a reflection on the people not the tool. You can't say ASM6 is incomplete because the original version didn't have incbin when it does now.

and invalid addressing modes, generating corrupt binaries instead.

He was using the wrong syntax. Parenthesis are used for order of operations like 2*(label+1) so STA (tempAdd),x is correctly assembled to STA tempAdd,x. People using it wrong does not mean bugs.

[Memblers]

He was using the wrong syntax. Parenthesis are used for order of operations like 2*(label+1) so STA (tempAdd),x is correctly assembled to STA tempAdd,x. People using it wrong does not mean bugs.

What's weird though is that NESASM seems to be the only thing in the 6502-using world that replaces parenthesis with brackets. All other assemblers I've used also parenthesis for order of operations and they seem to do just fine. It breaks a tradition that seems to go back maybe 35 years (including lots of source code), for no real advantage. Then the brackets also are used for something else on 65c816, for long (24-bit) indirection, IIRC.

You probably know all this too, but here's an except from the history text that explains the 8kB bank size, and maybe the syntax differences:

Code: Select all

               - merged the code of the NES and the PCE assembler, now
                  there's only one program.

It's an HuC6280 assembler, primarily. And that system does have 8kB banks. The MagicEngine TG16/PCE emulator written by the same author was really great one (and was the only one at the time).

WLA-DX was another assembler that had syntax oddities that I complained about too when it was brought up. Basically for the same reason - it supports multiple CPUs, it's not designed around the 6502. Again I complained then, that the x816 assembler, as well as CA65, supported 6502/65C816 fully without any sort of weird pseudo-typecasting syntax being needed.

Things are a lot better when people are able to share their source code and let other use it. That's what is great about ASM6, CA65, DASM, and x816. You will have to change local labels, swap .byte for .db, easy stuff like that. Try that with NESASM, your bank is going to overflow, it might assemble and take guesses about what the parenthesis mean, it might run slower and be larger without adding stuff to specify zeropage vs absolute, and you're still going to have to change the local labels, heheh.

[blargg]

I was porting something to 2.51 today and found that it doesn't even warn when overwriting values:

.bank 0
.org $100
.byte $12

.bank 0
.org $100
.byte $34

The above acts as if the first .byte was never even done, without any diagnostics. That's a recipe for hard-to-find bugs.

And treating jmp ($1234) as jmp $1234 without even a warning is poor, given that (as far as I know) jmp ($1234) is the standard syntax for an indirect jump.

[Memblers]

And treating jmp ($1234) as jmp $1234 without even a warning is poor, given that (as far as I know) jmp ($1234) is the standard syntax for an indirect jump.

Yep, I've found myself using JMP ($FFFC) quite a few times. The reset instruction, heheh.

[clueless]

Disclaimer: I use ca65. I've never tried nesasm, neshla, asm6 or others.

I also use revision control. Extensively. Religiously.

I've recently read the posts about people making various changes to loopy's asm6. I humbly suggest that loopy consider placing asm6 into some sort of revision control system and granting approved individuals commit access.

Loopy, if you'd like, I can host a subversion project and "trac" system for your asm6 on my own server. I maintain source trees for 20+ projects (mostly private, the largest one is 250,000+ lines of C code). I have a few public source trees (one being my own aborted attempt a a NES game). I backup to tape, a second hard-drive, a second computer (all in my house) and to a server at work (it's good to be the network security guy there). Automated regression tests upon checking are also possible (eg, compile a source file that utilizes most asm6 features and md5 the resulting .nes file). But my server is x86, so I can't automate testing of a big-endian build.

You can also get SVN, CVS, Hg, git or other hosting from a variety of places for free. Or if you have no desire to do so, you could permit the nesdev community to do the same.

The alternative is for several people to maintain their own private branches (possibly using independent rcs systems) and not benefit from a shared repository, commit histories, bug tracking and ownership, etc...

[3gengames]

Something like someone said earlier, why don't you get NESASM3 and stop using 2.51 and taunting it's problems?

[koitsu]

I've actually had to to use NESASM. NESASM 2.x has that bug where label names have to be shorter than a specific number of characters (which bit me when I was attempting to reassemble a public Japanese game from source -- written with NESASM!), otherwise it starts spitting out vague/bizarre errors which you won't easily determine are caused by label names being too long. NESASM 3.x would just segfault or crash in some way (I forget). Garbage. :-)

[3gengames]

Are you running modern compter? 0_o XD

[blargg]

I had no idea there was a nesasm3. I just looked and the only important change is an increase of line length. The other addition seemed to be some kind of list of function addresses.

[3gengames]

I think so? I know I don't use it alot, but I've not really had any problems with it. Although the bank sizes differ from NES hardware is a dumb idea, indeed. If I knew more C I'd edit it but I don't, so I guess I have to suffer. Oh well.


Edited for sounding like an idiot.

[Memblers]

I guess I didn't mention this earlier either, which somewhat explains why I'm willing to rant a lot about it, but like koitsu I use NESASM because I have to. Sometimes it's teaching people (who are already using it), there's plenty of NESASM-assembled stuff in the Garage Cart #2 compilation, even an NBASIC game (it compiles to NESASM syntax). I can certainly congratulate people who've never had trouble with it, heheh.

MCK depends on NESASM also, it has been widely used. On my original Squeedo cartridge I had a show-stopping bug that I was never able to track down (having moved on to a better rewrite), I hacked MCK to play music through my synth (IRQ'd to the NES's $4011) but there was some terrible glitching. I wouldn't be surprised at all if it was something mundane and stupid slipping through NESASM's error-checking. Wasted a lot of time debugging my PIC and NES code (which worked fine by itself), but, shit happens. And it's totally worth it that I'm making it with the PIC32 now, instead.

NESASM is inescapable, so yeah that's reason enough to discourage it's use among newbies. With ASM6 one can use those macros posted recently to create an iNES header, and that's a good basic setup that's just as convenient. At least until someone rewrites NESASM's erroring system (and banking size selectable), I can live with the syntax difference because of the ever-handy search-and-replace function.