This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

My simple NES-development project

My simple NES-development project
by on (#93235)
I'm working on a simple NESDEV-homebrew-environment I'd like to show you guys. It's pretty basic and is currently aimed at smaller projects. I have alot more tweaks to do and is still pretty early in development but I'm getting pretty proud of it. :)

It's basically a frontend for a command-line assembler (currently DASM).
When you start the program you can create a new project. You currently select from templates depending on what kind of project (PRG-size, mirroring etc.) and a new main-assemblyfile is created based on your settings.

A unique thing is that you work with alot of different files instead of one massive .asm file (or perhaps a few includes-aswell).
One subroutine = one file.
To the right in the GUI, there's a list of all available subroutines. Clicking on them immediately brings you to it. Hovering the list also brings you a tooltip for each subroutine (which could be: "Clear RAM, uses X and A" for example).
All these subroutines are then linked when compiled.

The GUI is a little bit intelligent and it's checking for a newer version on disk when you want to edit a specific subroutine (all subroutines are loaded to memory when you open an existing project).
It's designed with Dropbox in mind. Imagine having your friend remotely coding new subroutines and you get them instantly visible in your project. :)

Check out the (super-early-alfa)-screenshot below. What do you think of my ideas?

Image[/img]
Re: My simple NES-development project
by on (#93236)
oRBIT2002 wrote:
A unique thing is that you work with alot of different files instead of one massive .asm file (or perhaps a few includes-aswell).
One subroutine = one file.

This isn't really unique as it is more of a programmers choice, or a coding style choice. I've worked on projects where the coding standards required one subroutine per file. It has its benefits -- easy to find a subroutine because the file name is generally required to match it. It has its drawbacks -- many many more files to manage. I can't render an opinion either way which is better or worse, but having a tool force one way might be a turn off for some. In fact, the original NESICIDE had this exact set-up.
oRBIT2002 wrote:
It's designed with Dropbox in mind. Imagine having your friend remotely coding new subroutines and you get them instantly visible in your project. :)

Throw a NESICIDE project folder in your Dropbox and you'd have this, too.
oRBIT2002 wrote:
Check out the (super-early-alfa)-screenshot below. What do you think of my ideas?

I can't see the screenshot now as I'm at work. What UI toolkit [if any] are you using? Plans for cross-platform? Plans for integration with other assemblers? [I don't know DASM at all]. I like the idea of sharing projects or pieces of projects.

by on (#93237)
I'm coding for my own needs at the moment, let's see if others find it interesting. :)
It's currently developed using Microsoft .NET framework so no other platforms I'm afraid..
I think DASM is the oldest 6502 compiler that exists (I've used it since stoneage or so.. :)), but the only one I've used. But adding support for other compilers wouldn't be that hard hopefully.

by on (#93239)
oRBIT2002 wrote:
I'm coding for my own needs at the moment

Funny, that's how I got started too. I still *need* to create a NES game. Probably won't ever get there...
oRBIT2002 wrote:
, let's see if others find it interesting. :)

By "others" do you mean other people not developing something similar with similar-but-not-identical-goals? 8)
oRBIT2002 wrote:
I think DASM is the oldest 6502 compiler that exists (I've used it since stoneage or so.. :)), but the only one I've used. But adding support for other compilers wouldn't be that hard hopefully.

Never heard of it. Actually maybe I have but I just always assumed the D meant DIS as in DisASseMbler.

Anyway, I am not meaning to sound like I'm dumping on your idea. :oops:

by on (#93241)
I meant if others find it interesting for NES development...

I think I got DASM back in the days when iNES still was "popular". :)

by on (#93242)
I've got my own NES development(/hacking) IDE, written in C#, with its own list of handy features. It was released to virtually non-existent reception.

I think when it comes to NES, people have historically pieced together their own collection of development tools. It's hard to create something they'll want to switch to. Everybody has different needs and preferences, and your tool only needs to lack one feature that they don't want to part with.

NESICIDE is a pretty solid piece of software, and I'd say that anybody looking for an IDE is going to look to NESICIDE for the foreseeable future.

Still, that doesn't mean it's a bad plan to put some effort into a development tool. I vastly prefer my own IDE and my own assembler, even though they may not be the best tools out there, because they were designed with the things I think are important in mind.
Re: My simple NES-development project
by on (#93285)
cpow wrote:
oRBIT2002 wrote:
A unique thing is that you work with alot of different files instead of one massive .asm file (or perhaps a few includes-aswell).
One subroutine = one file.

This isn't really unique as it is more of a programmers choice, or a coding style choice. I've worked on projects where the coding standards required one subroutine per file. It has its benefits -- easy to find a subroutine because the file name is generally required to match it. It has its drawbacks -- many many more files to manage. I can't render an opinion either way which is better or worse, but having a tool force one way might be a turn off for some. In fact, the original NESICIDE had this exact set-up.


A better compromise would be to have a tool that isolates this concern: it could save it in a single file, but display it on the IDE as multiple isolated subroutines, or have one subroutine per file but display it as if it was a single big file; there's no real need to tie one to another.

by on (#93292)
If there are custom preprocessors for the assembly files, the concern can't be completely isolated. For example, Concentration Room 0.02 uses a preprocessor to shuffle the order of variables and subroutines.