For a while I've been thinking about how a 65xx IDE should look like.
I would like to start a discussion about such an environment, to see what should it contain, and what would it take to make it.
Please post ideas and comments.

I'd have to start by reiterating a point Garth has made - you probably won't get a consensus and you probably won't recruit a team effort. You will probably get ideas, but for a project to happen it almost always takes a single person to get started with some code - that person defines what is in and what is out. With tools like github, you can of course have complementary forks of a project (which is more or less what we saw with 65Org16)

It helps in discussions like these to frame the project you'd like to discuss.

Should I add that it won't be productive to hear any opinions that such a project is not a good idea? If you don't like the sound of this project, please leave the thread alone. If you like, set up a blog to voice your opinions, or start a constructive thread on a project you like better.

Good luck!

Cheers
Ed

The ide should be more of bringing an assembler, simulator, and cc65 compiler in one package. All of the things that an proper 65xx ide needs already exists, we only need to put them in a single program.
The only tool i used is the Kowalski simulator, so i don't have much experiences with simulators and similar tools. But i could contribute with writing the ide code that bonds the elements including gui and editor. Java would be my choice, since it is cross platform.

How about using Eclipse ?

Like WUDSN, that might do just fine, but i have no idea how to make eclipse mods/plugins, so i can't contribute with that.

I haven't used Eclipse myself, but maybe figuring out how to modify it for 6502 is easier than creating an alternative. It's at least worth some attention.

I since i learned Java i use Eclipse a lot. I googled about that when i saw WUDSN, but i didn't find much. Ill give it another try.

You should ideally make it pluggable for different specific 65xx-oriented toolchains. While I use ca65 the most, there are legitimate features that other assemblers have that change the syntax and would be nice to have IDE support through.

Eclipse might be a good starting point if you're already into Java, but I think for the specifics of what to configure for the 65xx world you'd need to create your own abstractions anyway.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

My assembler should need minimal wrapping to call from within an Eclipse environment.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Agree. Another thing that would require attention, is that it should not be fixed for specific systems, like c64, or apple2, but that you can describe i a way your custom system.

I would love a simple interface. I understand that lots of us here use Eclipse but for me it's everything but simple.

Its really not that difficult to use. You pick it up very quickly.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

My 6502 IDE is NetBeans running my simulator and my assembler.

I have breakpoints in my simulator that can stop on memory and register access and change. It can also trace instructions and such, I can step etc. Most of that is just in the output window or the IDE and not in windows maintained by the simulator, it runs outside of the IDE -- but it's probably not a great leap to get it to run inside of it. These are useful, but surprisingly less than useful when debugging high level Forth code (since all of the work happens mostly in the same core runtime). Need a better Forth debugger than a 6502 debugger.

It's a hodge podge of tools, but most of the files live open in the IDE. Of course, I can also put breakpoints in the simulator itself, but I have to do that less and less (which is a good sign). It could certainly be more elegant and flow better.

I think an IDE makes little sense for real hardware unless you have actual, on board debugging and inspection resources available (is that what JTAG does?). Perhaps a better editor that's more aware of the structure of an assembly file (click on a label, jump to its source). That could be nice, but then you have to settle on an assembler.

It would probably be straightforward to convert my assembler to an ANT or MAVEN task and change the output to be most satisfactory to the IDE to be a better citizen. Emacs has a format it likes in compiler output that it automatically accepts out the gate, I could convert it to that. Then I could click on error messages in the IDE and go to the source lines easily -- "for free".

Having the editor aware of cross file symbols for the assembler would perhaps be the most useful. Find definition, show usages. But it's assembler specific since each assembler has it's own syntax.

I'm still working on adding better expressions to my assembler so that I can add macros. Then I want to run that verification test suite we have posted in the other forums to check my CPU. I kind of want to redo the assembler in general. I don't have a linker or anything like that yet, haven't really needed it.

The biggest issue was that simply my goal was to get my simulator working, and all this tooling around that I found as a distraction, so I get it to be borderline acceptable and then just leave it.

Back in the day when I did a lot of 6502 assembly programming I wanted a feature that showed branches and looping and I drew lines by hand on the printouts. Something that draws a blue line for backward branches, amber for forward branches, (perhaps also red for JMP and green for JSR ) was something I wanted then.

Specific for 6502 is the zero page and pressure here was always big; you never had enough RAM and certainly not enough room in the zero page. Result was time sharing and a high probability of bugs. My suggestion here is a tool that indicates pressure by number of places in code that writes and number of reads. Also useful is a tool to go from address to code (readers and writers). Statistics from a simulated run is even better.

I have, countless times, printed out confusing routines on fanfold paper to spread on out the floor and draw the arrows just as you're saying, from the various branch instructions to the labels they branch to. My ideas of structure improved dramatically in Forth, but it was only recently that I realized there's a way to do this and be able to nest structures in assembly with common assemblers. It becomes much more clear what you're doing, reduces bugs, makes the code more maintainable, gets rid of most of the local labels, and in most cases there's absolutely no penalty in program length or execution speed. I wrote about it at http://wilsonminesco.com/StructureMacros/index.html and included source code. BitWise offers the As65 assembler which has nestable structures built in also, without the user having to add macros to accomplish the purpose.

Forth tends to be its own IDE, including for portions you might want to write in assembly.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?