6502.org

Welcome to WUDSN IDE, the free integrated Atari 2600, Atari 7800, Atari 8-bit, C64 and NES development plugin for Eclipse. It combines the powerful capabilities of Eclipse with the speed of native 6502 cross compilers & built-in graphics and sound tools.



https://www.facebook.com/wudsn?sk=timeline

Yes, I know. Facebook. But it does look exctiing, let me get other pages of it linked in.

http://sourceforge.net/projects/javahexeditor/

http://www.youtube.com/watch?v=36MFqY55yR0

http://www.wudsn.com/

Thanks Tony, never thought my Facebook approach would end up on 6502.org...
... it should be the other way round,right?

The IDE supports many host systems (barebone Eclipse 50 MB: PC, Mac, Linux), many compilers (ATASM, MADS, DASM, ... getting more) and platforms (see above).
The main idea is to be the integrating point and link all the cool things that are already there.
Many nice projects I have seen before failed because people got lost in trying to much (I have to contraint myself every day, too, to be honest).
I have met many people who would "like to code something" but are stopped by the initial effort/problem.
The IDE relieves you from 90% of the normal setup stuff (scripts, paths, options, ...) and meanwhile there are more than 100 active users.
The first video tutorial http://www.youtube.com/watch?v=36MFqY55yR0 show how to install everything and run the first demo in 15 minutes.

I think this gives a good idea of the main editor.


The source (including all include files) is actually parse while you type, so this give you much more than just syntax highlighting
- hyperlink navigation to source and binary files
- hyperlink navigation to labels etc. even across files
- content assist (auto-completion) for labels etc.





Besides this, there is a
- build-in hex editor (currently viewer, but will be completed) which automatically detects famous file formats
- build-in graphic converter (C64, Atari, ...) with scripting option for creating arbitrary conversions
- build-in sound editor (in process, C64, Atari)

.. and more to come. Just tell me you wishes.

My own weapon of choice on here is the Kowalski compiler. One wish I have for it would be an emulation by setting up lemory locations for what you want it to do. This would become important since I have a bank switching sceme built into the computer, so being able to compile across pages would be a huge plus

This IDE looks to me like an assembler, not compiler. What does it do that the Kowalski simulator doesn't?

Hi,

>an assembler, not compiler.
Not sure where you make this difference. I normally refer to the language as "assembler" and the comiler executable, as the "compiler".

>What does it do that the Kowalski simulator doesn't?
Thanks for pointing me that simulator. First time I see it today and it's cool.
For plain 6502 coding I think it's a perfect fit (and he this is 6502.org )

WUDSN IDE's benefits are integrating the editor, compiler and emulator just like Kowalski simulator does.
The difference WUDSN IDE works for many different target platforms, where different people write different emulators.
Writing an excat Atari or C64 emulator is a life-time task with and there nobody who can spent 3 life times for an IDE .
The same goes for the compilers. If you are an Atari VCS developer, all your sources are in DASM format
and you want to keep them as they are. Besides this the IDE comes with the built-in viewers/editors/converters
mentioned above, which again simply your life when your target is a Atari, C64, NES ... like system.
Besides that I always try to help people getting into coding. That's the whole point why I made the IDE an official tool.
My video tutorials turned out to be very well received and many "potential" codes became actual coders now.

- Peter/JAC!

However, the program that assembles your "assembler" isn't a compiler. From the on-line tech dictionary:

• assembler
  
  Software that translates assembly language into machine language.
  Contrast with compiler, which is used to translate a high-level
  language, such as COBOL or C, into assembly language first and
  then into machine language.

As others around here know, I (and another member ) tend toward pedantry, especially in the technical realm. Incorrect terminology often leads to incorrect assumptions, leading to incorrect procedures...etc.

The correct name for the language is assembly language. Compiled languages are, by definition, high level, human-oriented representations. The terminology came into being in the early 1950s, assembly language when the idea of symbolically representing machine instructions with mnemonics was hatched, and compiler, when Grace Hopper developed a method of translating A-0 language statements into their assembly language equivalents. IBM's FORTRAN compiler was the first widely-used one and produced assembly language source code.

My pedantic tendencies come from having trained numerous people over the years in the fine art of repairing electronic and computer hardware. It's an exact art that requires an exacting language. Using the wrong term could sometimes result in a misunderstanding that produced expensive or worse results.
The Kowalski simulator lets one set up a virtual 65(c)02 system, complete with console I/O, rudimentary memory protection and interrupts. When I was first fleshing out my POC computer, I used the Kowalski simulator to test some concepts before committing the code to EPROM and running it in the actual hardware.

When I got to the point where I was going to run the POC computer in native mode I had a problem. I didn't have a 65C816 assembler and I was unwilling to pay someone an arm and a leg to get one. That led me to continue to use the Kowalski simulator's assembler, along with an extensive set of macros to synthesize the '816-unique instructions. Of course, I couldn't execute such code in the simulator, but that limitation didn't matter at that point, since I had working hardware on which to run programs.

There others here who use the Kowalski simulator as well, although I'm not sure to what extent.

Hi Peter, call it what you will: looks great! It took me a while to spot the hiding-in-plain-sight statement that it runs on Linux - good move from my perspective.
Cheers
Ed

This really looks like a promising tool (I am using eclipse often on everday Java development, and got used to its features...)

One comment: I was unable to really navigate the web site, on Linux firefox 13.0.1 the menu does not work, and the content runs off the right side of the window without scroll bars....

Thanks for the hint fachat. I edit the site manually a html/php and validator now tell's me I broke it
Will have a look.

BTW: is the xa65 cross-assembler supported? (ok, shameless plug, as I wrote it, but yet,...

On the web page I only see mention of "you only need a single project" ... does it support multiple projects?

For example I could have one project with filesystem libraries, another with USB65 libraries, and so on, and the actual application code in a separate project. And then I want to assemble that all into a single binary. Is this possible?

Is egit support (the eclipse git plugin e.g. for github or similar sites?)

TIA
André

Edit: xa65 support would be ok if only for the current dev version that has more compatibility support with ca65 and masm. see here on github https://github.com/fachat/xa65

That should be fixed now. I had to remove the Facebook button iframe, otherwise firefox get's confused. Will have to look for another solution.

>BTW: is the xa65 cross-assembler supported? (ok, shameless plug, as I wrote it, but yet,... )
No But if it is mostly ca65, I suggest we wait until I have included ca65 and they you can provide the delta.
I only add new assembler if I also have a test suite/people how use it. Otherwise it's impossible to keep the IDE up to date/in sync/working as expected.

>On the web page I only see mention of "you only need a single project" ... does it support multiple projects?
It does not use project specific settings, so it simply doesn't matter if you use one or more projects.
I tend to use one project (top level folder) per hardware (atari800, atari2600, c64,..) and then linked folders to central locations outside of the workspace.
But you are free to do what you like.

>For example I could have one project with filesystem libraries, another with USB65 libraries, and so on, and the actual application code in a separate project. And then I want to assemble that all into a single binary. Is this possible?
Sure. For the cross-assemblers the work space/project structure does not exist.
They only see the file system, so also here you can have the structure as you like/need.

>Is egit support (the eclipse git plugin e.g. for github or similar sites?)
The Eclipse default team support works out of the box.
Whatever versioning tool works for other projects will also work here.

Did you get the "listing" branch from github? I'm sorry it's not that clear. This branch has the latest version at the moment: https://github.com/fachat/xa65
Then then man page says that "-P filename" sets the listing filename, default is none. use the special filename "-" to print the listing to standard output.

André

Good ol' unixy tradition

André