nesdev.org

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.

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.

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.

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.