nesdev.org

thefox wrote:

Does the label file tell you what segment each label is in? If so, translate segments to MEMORY areas to banks.

It doesn't. It's very basic file specifically for use with VICE, but the linker source should be pretty easy to modify to spit out the segment info too.

It you use the --dbgfile option on the linker, it will spit out some extra information and the segments are listed at the begining with some address. Since I didn't test it with a multi-bank program yet, I don't know how useful this information will be.

Banshaku wrote:

thefox wrote:

Does the label file tell you what segment each label is in? If so, translate segments to MEMORY areas to banks.

It doesn't. It's very basic file specifically for use with VICE, but the linker source should be pretty easy to modify to spit out the segment info too.

It you use the --dbgfile option on the linker, it will spit out some extra information and the segments are listed at the begining with some address. Since I didn't test it with a multi-bank program yet, I don't know how useful this information will be.

From what I can tell, the only thing available with CA65 for telling you the order of the segments (*edit* excuse me, PRG blocks) as they appear in the ROM is your own config file where you define your memory areas. I was playing around with this the other night. the --dbgfile, the VICE file, nor the map file seem to display the SEGMENTS in the order in which they appear in the ROM. Thus, the only way to support a bankswitched rom (in your fceuxdsp namelist file generator) would be to parse your own config file. I tested this quickly by setting my game ROM up with UnROM, and then putting different PRG banks as the "last" one (C000) in my memory area in the config file. Sure enough, my ROM only worked when my game code was the last of the PRG banks defined in the MEMORY{ part of my config file.

I think the relative awkwardness with generating good namelist files with CA65 is the only thing I don't like about it. With ASM6, it was a snap. Its listing file told you everything that was in the final rom, address by address. Thus, you could always know when to generate a new namelist file. You know you start out < 8000 in RAM, so you generate the ram.nl file. After that, you're either between 8000 and C000 or C000 and FFFF. If your address ever suddenly "decreases" you know you've switched to a new PRG bank. If its ever less than 8000 again you know you're spilled over into CHR rom, and unless you're nuts you can stop generating namelist files there =)

I guess the only option left is to just add it directly into ca65. You could add an extra command line option to make a file formated for fceux. Since the code already exist for the vice version, that should be easy to use it as a base and make the one for fceux. This could be interesting to make some day. For now it's not on my priority list but it will become one once I need to debug my project more.

I will put it on my todo list unless someone beats me to it

Banshaku wrote:I guess the only option left is to just add it directly into ca65. You could add an extra command line option to make a file formated for fceux. Since the code already exist for the vice version, that should be easy to use it as a base and make the one for fceux. This could be interesting to make some day. For now it's not on my priority list but it will become one once I need to debug my project more.

I will put it on my todo list unless someone beats me to it

I don't see why one would need to add this to the CA65 source itself. It seems like what you need is:

1) Your config file, so you know how all your segments/PRG banks will be spit out in the final rom
2) Your --dbgfile, so you can know the address of each of your labels
3) The .lst files of each of your object files, which give you offsets so you can calculate addresses for comments etc.

Parsing these should be a snap, they have very consistent formatting and syntax. My namelist generator only uses 2) and 3) right now, but I'm pretty confident at this point if I add 1) it will support multiple PRG banks.

Banshaku wrote:Another comment, if you could make a generic handler for 6502 instructions then have many different derived class for specific assembler, that would be nice too. Right now, not many people uses neshla so either people would convert to neshla to use your editor or they will just ignore it. I would keep that in mind while making it.

After spending some more time with neshla I have decided against using it. So the question is what compiler do I use instead? Banshaku has a really good point and I'm leaning towards using whatever compiler is most widely used right now.

Is there a general consensus on which compiler to use for NES dev or should I start a new topic with a poll?

I think the most used ones are CA65, ASM6 and NESASM. The pros like CA65, the newbies like NESASM. I like ASM6.

Am I the only TASM user here?

Dwedit wrote:Am I the only TASM user here?

I haven't heard of it for a long time, but maybe it still has users. I assembled my very (crappy/bugged) first program with it, IIRC... =)

I used TASM for the SPC-700 portion of my SNES NSF player (but it was the only option at the time). Pretty cool how it can support anything, with the right table file.

I use CA65, but I tried out ASM6 to get a quick start on a small project recently and found it to be pretty good.

I checked them out and think I'll start with nesasm.

Once I have a stable version for nesasm I'll either make a branch for ca65 or make the source code available so someone else can.

Thanks again for the recommendations.

None of them is better than the other. All of them have their goods and bad parts so you have 2 possibilities:

- You focus on one that seems popular and that you like or
- You go generic and cover the most popular one with a plug-in approach

The first one is the easiest to do. The second may give you a hard time but would cover more users along the way. It all depends on how much time and effort you can put on it. My hobby time became almost non existent recently so I had to put that project on indefinite hold.

tokumaru wrote: I like ASM6.

Me too

I tried CA65 but couldn't be bothered with the extra level of setup required. ASM6 is much more immediate.

neilbaldwin wrote:

tokumaru wrote: I like ASM6.

Me too

I tried CA65 but couldn't be bothered with the extra level of setup required. ASM6 is much more immediate.

So is nesasm. It's all a mater of taste. At first ca65 was a pain but the more I use, the more I find new way to improve my code and I like it. I found interesting ways to use structures and it's quite helpful to make my code clearer. Mileage varies I guess.

I really dislike nesasm. First assembler I used was P65, because of Michael Martin's tutorial using it. I translated my code to nesasm, and shortly became annoyed at how many quirks that assembler has. For example, if you have a line of .db $00, $00 etc. etc. that is longer than 80 or so characters, nesasm just plain ignores them. I remember finding some other quirks so I translated my code to ASM6.

Problem with ASM6 is the relative difficulty of splitting your code into seperate files (using .include forces you to think about dependencies between files...CA65 solves this with object files and symbol exports/imports and a linker). I wanted to do this so it would be easy to browse code. I don't want to constantly be using bookmarks and using the "find" box in an editor. I'd like to just click on a tab and see a particular module all laid out. This is what CA65 gains you. The extra setup isn't that bad. It took a few hours of teeth gnashing on a saturday, and now I don't have to think about it anymore.

Finally, CA65 makes it a heck of a lot easier to understand how your ROM is laid out, via the config file. With most other assemblers, you use .org or .base spread throughout one monolithic source file, but with the config file you just have clearly named segments that you can fill anywhere, and a concise "memory" section that says how to lay it all out in the ROM.

The only clunky thing about it is if you want to use symbols in multiple places you must do .import and .export (which is arguably a good practice anyway, encourages modular thinking), plus you must contend with how to build your project but this is easily solved with a simple makefile which you only need to write once.

Also, it is more difficult to write a good namelist file generator for FCEUXDSP with ca65's debug output files and listings, but not impossible. ASM6's listings are excellent--they contain everything in one file, in the order it appears in the final ROM.

For starting out, I'd reccommend P65 (especially in conjunction with Michael Martin's NES101 tutorial) or ASM6...but for making a big project, I'd reccommend transitioning to CA65.

Credit to Banshaku for originally encouraging me to use CA65.

ZomCoder wrote:I really dislike nesasm. First assembler I used was P65, because of Michael Martin's tutorial using it. I translated my code to nesasm, and shortly became annoyed at how many quirks that assembler has. For example, if you have a line of .db $00, $00 etc. etc. that is longer than 80 or so characters, nesasm just plain ignores them. I remember finding some other quirks so I translated my code to ASM6.

I'm really not a fan of nesasm either. It was the first assembler I used. But the worst thing about it is that certain error conditions that will cause other assembers to say "hey, we've got problem X at line Y, aborting", nesasm in some cases will just assemble a faulty ROM and act like everything is fine, like you said. I can't stand that, it's unhelpful and drives me nuts. Older versions if you made a typo in the source would just outright crash sometimes (!), but I haven't seen that in v2.51 that I can recall.

But if anyone insists on using nesasm, try out the version that bunnyboy had updated: http://nespowerpak.com/nesasm/ I guess it fixes the line length problem at least, maybe some other things too, but that's just one of many potential pitfalls.