I'm going to start development on a small game soon and think NESHLA looks very promising. I'm wondering what you guys are using to edit the source files.
I think hardly anyone uses NESHLA... =)
But to edit ASM fils I use Notepad++ with a custom syntax highlighting configuration for 6502.
I use an editor called ConTEXT, also with some 6502 syntax highlighting that I modified a bit (made branches a different color, and highlights a few CA65-specific commands).
tokumaru wrote:
I think hardly anyone uses NESHLA... =)
That's because it was windows only and the documentation was missing some key pieces. I have begun rectifying the situation. I fixed a ton of portability issues with NESHLA and ported it to Linux/Mac OS X/Cygwin. You can get it here:
http://bitbucket.org/wookie/neshla/downloads/
I have also ported all of the original documentation over to a wiki and filled in a lot of the missing pieces here:
http://bitbucket.org/wookie/neshla/wiki/NESHLA_Programming_Manual
-Wookie
tokumaru wrote:
But to edit ASM fils I use Notepad++ with a custom syntax highlighting configuration for 6502.
I do the exact same.
This is great info. I was hoping you guys were using something with a bit more features though. Visual studio has me pretty spoiled with intellisense and refactoring.
Do you guys think that making a more powerfull source editor that had some basic intellisense and refactoring features would be usefull?
I asked a similar question before. From my point of view, I say that it would be useful since you could have access to all you symbol more easily. But unless someone can really make that editor and work with all the flavor of asm that people uses, I guess it will not happen unfortunately.
tokumaru wrote:
I think hardly anyone uses NESHLA... =)
But to edit ASM fils I use Notepad++ with a custom syntax highlighting configuration for 6502.
Care to share those configs?
thefox wrote:
tokumaru wrote:
I think hardly anyone uses NESHLA... =)
But to edit ASM fils I use Notepad++ with a custom syntax highlighting configuration for 6502.
Care to share those configs?
http://nesdev.com/bbs/viewtopic.php?t=5288Maybe tokumaru would like to post his syntax definition file there, too?
EDIT: Oh, maybe it's the one Banshaku posted.
Banshaku wrote:
I made one with Tokumaru that support ca65 and other assemblers (nesasm I think and other one, asm6?)
I was just on the verge of posting that link
Tokumaru may be using a few different colors but they should be quite similar.
Wookie wrote:
tokumaru wrote:
I think hardly anyone uses NESHLA... =)
That's because it was windows only and the documentation was missing some key pieces. I have begun rectifying the situation. I fixed a ton of portability issues with NESHLA and ported it to Linux/Mac OS X/Cygwin. You can get it here:
http://bitbucket.org/wookie/neshla/downloads/I have also ported all of the original documentation over to a wiki and filled in a lot of the missing pieces here:
http://bitbucket.org/wookie/neshla/wiki/NESHLA_Programming_Manual-Wookie
I grabbed the source with interest but it's not obvious how to build it (Mac OSX)
I know that I was interested in the past by the coding style but I don't remember why I didn't go forward with it. Maybe the lack of documentation or the project seemed dead, don't remember exactly.
For now I'm so used to ca65 that I don't know if I would switch. If there is some life back in the project I may follow it to see what you can do with it.
I'm looking into the possibility of making an NESHLA editor with intellisense. It would be written in C# (.NET), so I don't know how portable it would be. If I get it working I'll make the source and binaries available to you guys.
If any of you guys that have experiance writing code in assembly/NESHLA have any suggestions or feature requests for such an editor I would definately be interested to hear them.
So far I'm planning on the following for the intial editor:
-Syntax highlighting
-Multidocument tab interface with a treelist of the file hierarchy
-Refactor option that allows for easy renaming of variables/symbols
-Intellisense that displays all the built in NESHLA options as well as any variables/symbols that have been defined.
-Go to definition option that opens the source file and takes you to the line where a function is defined.
-Ability to add descriptions to functions and display the description when a function is called.
Zack S wrote:
I'm looking into the possibility of making an NESHLA editor with intellisense. It would be written in C# (.NET), so I don't know how portable it would be. If I get it working I'll make the source and binaries available to you guys.
I you stop yourself just for portability than nothing will be done. If people want to use it they will find a way to run it.
I had the same idea to do it in dot net and wanted to integrate it with my current map editor. I just don't have the time to do it at all and can barely work on my map editor/nes project.
You should look for
Scintilla net, a .net wrapper for a code editing component made in C++ Many editors uses the native one for color syntax highlighting, intelisense behavior etc. I was going to use that.
Banshaku wrote:
You should look for
Scintilla net, a .net wrapper for a code editing component made in C++ Many editors uses the native one for color syntax highlighting, intelisense behavior etc. I was going to use that.
For my first attempt I'm just going to stick with a normal RichTextBox control. I have the syntax highlighting proof of concept working pretty good already. I'm glad you pointed me to that control though. If I hit too many problems with the RichTextBox it will be the next thing I try for sure. Thanks for letting me know about it.
Zack S wrote:
I'm looking into the possibility of making an NESHLA editor with intellisense.
Why re-invent the wheel. Do something that will advance the art of NES development instead of creating yet another IDE. Syntax highlighting can easily be added to all of the IDE's out there. Most of those IDE's will support intellisense and jump to tag type functionality.
Think of something more inventive like an integrated sprite/animation tool. Or a tool for organizing your sprite memory into different banks. A general tool for organizing ROMs would be great. Think of it as an interactive iNES builder that lets you take your compiled code bin and your sprite banks and build an iNES out of it.
That would be useful.
Sometimes I feel like people spend too much time making tools... And few games are ever made with those tools. I'd prefer that people were working on more games instead. We have so few good NES homebrews (by good I mean something that will keep people interested for more than a few minutes).
Wookie wrote:
Most of those IDE's will support intellisense and jump to tag type functionality.
If you could kindly point me to an IDE that is capable of syntax highlighting and intellisense for NESHLA, I would be happy to abandon my plans for making an editor. Then I could get to work on my nes game.
tokumaru wrote:
Sometimes I feel like people spend too much time making tools... And few games are ever made with those tools.
There is not that much tool that I find useful for nes these days. My map editor, even in it's current alpha state, saved me a lot of time to built my map content and test interlaved data. Imagine if I had to remake by hand the map data when I wanted to test normal data or interlaved one.. Converting from one format to the other would have been a pain. Just added a few lines of code in the exporter and I was able to test it with my current map data.
As for Wookie comment, I would like right now to have a tool to make my sprites. But with my current format, that would not be possible to use an existing tool I guess. I'm making them by hand and it takes time. I would like to built one in my editor someday but I don't have much time anymore for hobbies so oh well.
tokumaru wrote:
Sometimes I feel like people spend too much time making tools
Tools do not require as much aesthetic creativity as a game does.
Richard Stallman, head of the Free Software Foundation, has drawn a distinction between tools (utilitarian works, like a kernel or CC65 or OpenOffice.org) and aesthetic works (like paintings, sculptures, and most games' data files). Publishers of tools (like Red Hat and Sun) can use the business model of selling associated services; publishers of aesthetic works designed to be enjoyed apart from a network cannot. Stallman would have no problem with a video game that uses proprietary scripts (as long as they're interpreted), proprietary dialogue, proprietary maps, proprietary meshes, proprietary textures, and proprietary audio, as long as the engine is free software.
tepples, sometimes I have no idea what you're talking about...
Then let me put it more simply:
Tools need only code. Games need code, art, and several other skills. So people who feel most comfortable with code concentrate on tools.
tepples wrote:
Tools need only code. Games need code, art, and several other skills. So people who feel most comfortable with code concentrate on tools.
I agree. The better the workflow and "WYSIWYG-ness" of a tool, the easier and faster it is for me to get good results with it, at least when it comes to creative work.
It's all about instant feedback, instead of having a detailed picture in mind from the beginning I let the idea evolve during the process of creating art itself. E.g., I've been using MML way longer than FamiTracker, but could never finish any tunes using it. With FamiTracker it's easier, you can hear the results of your input immediately.
However, I can say for sure that, for programming, I'd prefer a simple Notepad-type editor over a complex IDE anytime.
Sorry if that was too much of a rant, but I hope what I said makes sense, maybe other people feel the same.
Yeah long live notepd
Altough more complex programs with improved find features and less crazy tab handling can be better.
And yeah I should definitely get more into programming tools. I've written a few tools in java to generate large binary tables, but that's all. When I had to code a tool to test huffman compression, I did it on the NES because no implementation in high-level languages poped up in my head.
And some tool developpers can end up writing great games when they have free times, like Inteligent systems who did Nintendo Wars and Fire Emblem series.
Zack S wrote:
If you could kindly point me to an IDE that is capable of syntax highlighting and intellisense for NESHLA, I would be happy to abandon my plans for making an editor.
http://www.contexteditor.org/
Making a syntax highlighting rule set for context is trivial. You could also try vim, it's easy to do there.
By saying that you *must* have syntax highlighting and intellisense before you can make your game is a bit namby pamby. Just get going on your game.
The tools work I've been doing is to make it possible to use the CopyNES with Linux
http://www.bitbucket.org/wookie/libcopynes and to write my games in NESHLA on Linux
http://www.bitbucket.org/wookie/neshla. I did this work because I *only* use Linux.
Now I'm working on a game, but it's not for the NES, it's for the Lynx.
I have a version of NESHLA that targets the Lynx as well as the NES that I'm currently testing. I plan to use that to write my game for the Lynx. Maybe I'll port it to the NES later.
The ConTEXT editor has a ton of syntax highlighter rules file here:
http://www.contexteditor.org/highlighters/ There is even one for 6502 assembler that will get you 90% of the way to NESHLA syntax highlighting. Just add support for the preprocessor directives and simple C function declarations and you'd be 99% there.
tepples wrote:
Then let me put it more simply:
Tools need only code. Games need code, art, and several other skills. So people who feel most comfortable with code concentrate on tools.
Exactly why I stumbled into tool land.
As for myself, I like making tools since I have to do sometime at work and like making games because it always interested me to try to do some. So it's hard to put priority on which one to do first. These days, I'm on coding the game but sprite editing by hand... It sucks. When I get too tired I may just add it to my tool.
Banshaku wrote:
As for myself, I like making tools since I have to do sometime at work and like making games because it always interested me to try to do some. So it's hard to put priority on which one to do first. These days, I'm on coding the game but sprite editing by hand... It sucks. When I get too tired I may just add it to my tool.
Help me here...what do you mean by sprite editing by hand? I picture you with a pen and paper. Surely there are plenty of tile editing tools that work for sprites?
I'm pretty sure he means ordering the individual sprites to form the actual characters of the game, and possibly their animations as well. I can see why this takes a long time... finding a center point, aligning each sprite, calculating where each one is relative to the others, testing the animations, the timing, and so on.
At work we program using visual studio. Now it's not required. You can write C# code using notepad if you want. They even ship a command line compiler for it with .net. If you wrote even a small application using notepad and the command line compiler it would take you a week or more. That same application would take 10 minutes in visual studio. So by spending a little time to make a decent source editor. You save a much greater amount of time down the road when it's time to write some NES code.
Besides my game is still in the early stages of the SDLC. So it's not like I'm ready to start coding anyway.
I agree it's hard to find the right balance between writing the tools and working on the game/demo itself. Personally I like IDEs, I would really like to see a Visual Studio -like IDE for NES development with integrated assembler (so the editor "understands" the code, can display helpful tooltips and so on) and features like automated cycle counting (where possible) etc. And of course symbolic debugging directly in the IDE
But I'm not too hopeful about there ever being one, as it's a very big project to pull off the way I would like.
Can you give me some details/requirements on an automated cycle counting feature? It sounds like something I want to add to my backlog.
Symbolic debugging in the IDE would be awesome. It's beyond the scope of my current project. Maybe there will be a 2.0 after I release a couple games.
Well, I wouldn't ever want to write a GUI-program without a dialog editor (like the one found in Visual Studio). It sure helps.
As for NES development... not sure.
For symbolic debugging I wrote a command line tool to automatically convert cl65's VICE label files ("-g" switch on ca65, "-Ln xyz.lbl" on cl65) to the romname.nes.ram.nl format used by FCEUX's debugger.
Automatic cycle counting sounds cool, but why not extend FCEUX or any other existing emulator to support it instead of completely re-inventing the wheel?
Zack S wrote:
Can you give me some details/requirements on an automated cycle counting feature? It sounds like something I want to add to my backlog.
I was thinking either having it in the assembler, so you can do something like ".startcount" and ".endcount" and then read the amount of cycles used by the instructions between that block from some magic label. Or if it's in the IDE, select a block of instructions and click a button and it'll tell how many cycles it takes. Of course this is not always possible if loops are used unless some more magic is used to hint the assembler/IDE how it should be calculated.
miau wrote:
For symbolic debugging I wrote a command line tool to automatically convert cl65's VICE label files ("-g" switch on ca65, "-Ln xyz.lbl" on cl65) to the romname.nes.ram.nl format used by FCEUX's debugger.
I thought about doing the same thing, the only problem is that there's really no way to do this when using banking, is there? FCEUX does support multiple symbol files for different banks but there's no way to get that information from VICE label files. I guess modifying the CC65 linker to write that information out should work though. Unfortunately AFAIK CA65 doesn't export line number information in object files (only the C-compiler does) so it's not possible to debug with the original source code visible even if a debugger supported it (this would be really cool IMO).
miau wrote:
Automatic cycle counting sounds cool, but why not extend FCEUX or any other existing emulator to support it instead of completely re-inventing the wheel?
By automatic cycle counting I meant what I said above, i.e. it should be an assembler feature. I think you're talking about profiling here (timing which parts of the program take the most time, which again, I think would be very useful). And I agree completely that existing code should be reused, writing an accurate and complete emulator just takes too much time.
I think the most flexible way to go about this would be add a debug API in one of the existing emulators (I'm thinking Nintendulator). So the IDE doesn't care where it gets its data from, it's all about presentation. Emulators can also be easily switched as long as they implement the API.
I know, I know. This would all be a lot of work. But one can always dream...
@NESICIDE:
What I meant is exactly like Tokumaru said. Preparing the attributes for your sprite by hand then compiling to see if it goes well is a pain. Especially in my case I'm using meta-meta sprite. This mean for one frame of animation, more than 1 meta-sprite is required to built the final animation frame. This is a way to reduce the size of the data since some data repeats itself. And another reason is because I want to do sprite on both way (left/right) since I cannot easily flip the meta-sprite because of their shapes. A the least I can save a few bytes here and there that way and don't need a method that will require to flip the animation frame since I have both side. I will just change a pointer for left and right animation frame based on the direction the player goes.
thefox wrote:
I think the most flexible way to go about this would be add a debug API in one of the existing emulators (I'm thinking Nintendulator). So the IDE doesn't care where it gets its data from, it's all about presentation. Emulators can also be easily switched as long as they implement the API.
I know, I know. This would all be a lot of work. But one can always dream...
This is what I had in mind. Instead of making an Ide with an emulator inside to test your code, you would "remote debug" by connecting to a specific emulator, similar to when you attach to a process in visual studio. Of course the emulator would requires to be extended like you said to support this method.
I had that in the back of my mind since last year. But this is such a huge task that I will first focus on finishing one project before I even touch this one. I started to investigate a little bit for finding a component for editing code. Scite seemed a nice one and someone did a dot net wrapper (Scintilla.net).
I started to make my map editor with a multi-tabbed environment like visual studio in the hope of adding extra functionality later with some kind of plug-in architecture. The code editor+debugger was one of my ideas I had. The reason I was thinking about that is because I wanted to have an editor with online help for the 6502 instructions, to be able to see my symbols by starting to type and a windows would pop-up like VS intelissence, to have online help for specific nes related topics etc. Then if I could debug and put some break point on specific line in my original code, that would be great. To see your own code with comments in an editor you know well while debugging is such a good thing.
I would like to do it someday but I guess that I have to either focus on my game/map editor or this code editor/debugger. With a family, I cannot but as much that like I could long time ago.
thefox wrote:
miau wrote:
For symbolic debugging I wrote a command line tool to automatically convert cl65's VICE label files ("-g" switch on ca65, "-Ln xyz.lbl" on cl65) to the romname.nes.ram.nl format used by FCEUX's debugger.
I thought about doing the same thing, the only problem is that there's really no way to do this when using banking, is there? FCEUX does support multiple symbol files for different banks but there's no way to get that information from VICE label files. I guess modifying the CC65 linker to write that information out should work though. Unfortunately AFAIK CA65 doesn't export line number information in object files (only the C-compiler does) so it's not possible to debug with the original source code visible even if a debugger supported it (this would be really cool IMO).
Ah, that sucks. Never tried it with bank-switched code. Would have been too easy if it just worked.
thefox wrote:
miau wrote:
Automatic cycle counting sounds cool, but why not extend FCEUX or any other existing emulator to support it instead of completely re-inventing the wheel?
...I think you're talking about profiling here...
Yeah, I misunderstood. Cycle counting of code blocks from within the editor would indeed be a great help when writing timed code.
I'm currently using a lot of separate apps to achieve the comfort I need - depending on the project I'm working on. It works pretty well (God bless makefiles). If someone can compile all this into one big, but usable IDE that is customizable enough, then sure, why not? The amount of work involved is just really big. Hence the argument about to improving and re-using the existing tools as much as possible, quite a lot of research has gone into them already.
Banshaku wrote:
Of course the emulator would requires to be extended like you said to support this method.
That is exactly why I started down the path of embedding my own emulator in NESICIDE. I didn't think people would be interested in the exported API approach in other already 'done' emulators. Of course, that has led me down the rabbit hole of having created the emulator and now wanting to make the emulation perfect at the expense of spending the time focused on making the IDE part of the darn thing what I envisioned it would be way back when I first started [over five years ago!]. That being said, I sure am having a LOT of fun implementing debug tools that work with the emulator. Hopefully someday I'll get back to the IDE side of things more forcefully. This IDE talk is exactly what I like reading...what do people want/need from and hate/love about existing tools.
The productivity gains you get from VS isn't limited to GUI programming. I find it just as helpfull when writing windows services and database access layers.
I completely agree that using components that have already been created and refined is a much better approach than writing from scratch. This is exactly the reason I'm starting with an editor for NESHLA. All my program has to do is call the NESHLA compiler with the correct command line parameters and then open a new instance of whatever emulator you choose with the .nes file that was created. Once you're done with the emulator you close it and the editor automatically brings itself to the front of the z order and puts you right where you were before you clicked run.
Zack S wrote:
The productivity gains you get from VS isn't limited to GUI programming. I find it just as helpfull when writing windows services and database access layers.
I completely agree that using components that have already been created and refined is a much better approach than writing from scratch. This is exactly the reason I'm starting with an editor for NESHLA. All my program has to do is call the NESHLA compiler with the correct command line parameters and then open a new instance of whatever emulator you choose with the .nes file that was created. Once you're done with the emulator you close it and the editor automatically brings itself to the front of the z order and puts you right where you were before you clicked run.
Yeah I finally managed the right incantation of CreateProcess() and WaitForSingleObject() calls to get NESICIDE hooked to an external assembler/compiler and NOT have that annoying command prompt window pop up. I'm very, very close to what you describe above, except the emulator is built-in.
What you describe is great for just building/executing but you'd still need to have the modified external emulator in order to interactively debug the running .nes image. That, to me, is where it gets hairy. When interfacing to an external compiler/assembler it isn't so very necessary to worry about the appropriate tooling versions. To be able to interactively interface with an external emulator you'd need to build smarts into your tool to know what versions of emulators it can work with. Although, I suppose something like a COM interface might come in handy...? Still...requires work on the emulator side.
I thought about implementing my emulator as an ActiveX control or some sort of embeddable object. Never got around to researching what would be necessary to do to support that, though.
thefox wrote:
I was thinking either having it in the assembler, so you can do something like ".startcount" and ".endcount" and then read the amount of cycles used by the instructions between that block from some magic label. Or if it's in the IDE, select a block of instructions and click a button and it'll tell how many cycles it takes. Of course this is not always possible if loops are used unless some more magic is used to hint the assembler/IDE how it should be calculated.
Profiling loops should be as easy as breakpoints. Just have a debugger log the elapsed cycle count whenever execution goes in or out of a .startcount/.endcount pair, and then keep a histogram of (endTime - startTime) values for each pair.
Quote:
miau wrote:
For symbolic debugging I wrote a command line tool to automatically convert cl65's VICE label files ("-g" switch on ca65, "-Ln xyz.lbl" on cl65) to the romname.nes.ram.nl format used by FCEUX's debugger.
I thought about doing the same thing, the only problem is that there's really no way to do this when using banking, is there? FCEUX does support multiple symbol files for different banks but there's no way to get that information from VICE label files.
Does the label file tell you what segment each label is in? If so, translate segments to MEMORY areas to banks.
Quote:
I think the most flexible way to go about this would be add a debug API in one of the existing emulators (I'm thinking Nintendulator).
For example, the GBA emulator VisualBoyAdvance implements a protocol that GDB can talk to.
miau wrote:
thefox wrote:
miau wrote:
For symbolic debugging I wrote a command line tool to automatically convert cl65's VICE label files ("-g" switch on ca65, "-Ln xyz.lbl" on cl65) to the romname.nes.ram.nl format used by FCEUX's debugger.
I thought about doing the same thing, the only problem is that there's really no way to do this when using banking, is there? FCEUX does support multiple symbol files for different banks but there's no way to get that information from VICE label files. I guess modifying the CC65 linker to write that information out should work though. Unfortunately AFAIK CA65 doesn't export line number information in object files (only the C-compiler does) so it's not possible to debug with the original source code visible even if a debugger supported it (this would be really cool IMO).
Ah, that sucks. Never tried it with bank-switched code. Would have been too easy if it just worked.
I haven't yet tried this with bank-switched code either. At the moment my namelist generator takes the --dbgfile and all .lst's for each object file, combing these for comments. When I create the final namelist files I check each address for being between two ranges, 8000 to <C000 and C000 to < 10000. Every time the address is in a new range, I increment the bank number and create a new namelist file. It seems like this ought to work for bankswitched code, since a ROM is just a big list of blocks all in a row starting from 0. I won't know if it works til I introduce bankswitching to my game engine. *edit* I was just playing around with adding an additional bank to my game... I think I may have to parse the MEMORY section in my .cfg file to get it right for bankswitching.
With that generator, it is possible to see all my original source code, labels, comments and all, right in FCEUXDSP.
What do you guys think I should include in the hover text for the 6502 instructions? Here's a preview of what I have for LDA right now.
I don't know what other would say but after you write LDA, usually in visual studio it will show what you can do with that function (possible parameters and description etc). In the case of LDA, the possible addressing mode could be useful. Then later if it could validate what you wrote, that would be even better but in that case, the editor requires to know about every symbols that this instruction has access. Adding intellisense for the possible symbols that can be used after that instruction would be good too.
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.
tepples wrote:
Profiling loops should be as easy as breakpoints. Just have a debugger log the elapsed cycle count whenever execution goes in or out of a .startcount/.endcount pair, and then keep a histogram of (endTime - startTime) values for each pair.
Yeah, I was talking about static analysis though.
Quote:
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.
thefox wrote:
Quote:
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:
Quote:
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.
Memblers wrote:
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.
That's the version I downloaded and it still sucks. Anything that's not a label has to have at least 1 leading space on its line or the source won't compile. Doesn't really matter though since I need to rewrite it in C# to integrate it into my editor properly.