Here's what I'm aware of:

A65, part of Dev65 by Andrew Jacobs (BitWise), cross platform, java source here
ca65, part of cc65 by Ullrich von Bassewitz, open source, cross platform, binaries available
xa65 by André Fachat (now maintained by Cameron Kaiser) open source, portable
ACME by Marco Baye, open source, binaries for various platforms
MXASS by Michael Steil, source, freeware, binaries for DOS/Windows (older version)
WLA DX by Ville Helin, cross platform, open source, binaries for Windows.
HXA65 by Anton Treuenfels (teamtempest), open source (awk), binaries for DOS/Windows

See also http://www.6502.org/tools/asm/

I've requested a new project area on SourceForge for Dev65. I'll upload my source code there later.

_________________
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

That's great!

You can see the code at:

http://dev65.svn.sourceforge.net/viewvc/dev65/trunk/

I'll tidy up the examples area and publish a build from it.

_________________
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

How do we go about installing it or whatever we do to get it started?

Cool, thanks for sharing! And it's in Jave :-)

I didn't have a look, but are you using some kind of lex/antlr/xtext parser or similar? I'm preparing the work for an assembler my 65k project and I'm also looking into a Java-based implementation. It still has to implement (at least most of) the xa65 features, at least o65 or even o65ng support.

André

No. its a hand coded LL(n) style parser with some look ahead in the tokeniser. 6502 assembler syntax doesn't have a complex grammar so I didn't use a parser generator.

_________________
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

Mmm, shouldn't that be "ca65" (65x assembler) and not "cc65" (C compiler)?

There's also HXA65 by self. The listing here on 6502.org doesn't mention 65816, but HXA65 supports it nonetheless. Open source (but in TAWK, a compiled variant of AWK. Could be ported to GAWK with some effort, I suppose). Binaries for DOS/Windows.

Should be a new version soon, but almost all new features are oriented toward assembly listings (I saw a listing that impressed me last year and decided I wanted HXA to do that).

That's great, thanks for the correction and clarification: I've updated my list (not sure what you might do with your quoted version of it!)

I note you also have a testsuite: always good to see those!

I'll also mail Mike N with the updated information so he can update the static index page.

I wouldn't have guessed there were so many.

Cheers
Ed

Oh yes, it's been very helpful in making sure HXA does what I say it should do. Also making sure it still does what I say it should do when I add something new.

But it's not a panacea. There are so many tests that manual checks for any version focus mainly on the new or revised parts. Automatic checking of the rest makes sure what worked before still works and what didn't still doesn't. However sometimes something that has become just a little off, but not enough to cause an error message, can sneak through. There are two bugs in the current posted version that got in this way, and got found only because I happened to manually run the relevant tests again.

Another problem is that I can only test for what I can think of. It has become quite apparent over time that sometimes my imagination is not as wide-ranging as it could be. There is a third bug that has been lurking for years, simply because until yesterday (literally) it never occured to me to check for it. Even that's not quite accuarate; I was actually checking for something else and got a failure, but not the one I was expecting.

Sometimes a test can tell me something years after I wrote it. I've added macro names and their expansion counts to assembly listings in the development version, which showed me that in one larger test a) three macros had never been expanded since I wrote the test (my bad!) and b) the one expanded most often was not the one I would have guessed. Live and learn...

bound,

We need a coder for an assembler for the 65Org16 (65016) project. It is identical to the 6502 (except BCD mode, SED & CLD opcodes are non-existent) and has the same opcodes as the original 6502, except the data bus is 16 bit. Also, the address bus is 32 bit, giving a user 4GBytes of linear addressable memory, i.e. no banking registers, thanks to BigEd's original mod of Arlet's core: Check here and here.
So, for example, coding for an LDA #$00 in original 6502 would be A9,00. For the new CPU coding for LDA #$0000 would be 00A9,0000... I would like to add more opcodes/accumulators/index registers in the future. But for now, we at least need some kind of basic assembler to boost the 65Org16 into orbit and you seem to have the very useful skills to contribute?

Right now I am hard coding in a text editor. PITA!

If you decide to contribute, I may have a piece of hardware to contribute for your efforts so you can test your own code on this before posting...

Don't get discouraged.... See here when I got fed up with posting on my PWA project, and actually started deleting links to pics I had posted...
You may actually be ahead of the power curve and not even realize it...

Regards,
EE

Have you considered using an existing macro assembler to prototype the instruction set? An earlier thread discussed using macros to add R65C02 instructions to a 65C02 assembler; this would be the same thing, just on a larger scale.

I'd think it would be much easier to get things "just right" by editing macro definitions than by re-writing an assembler each time a change was desired. Once a macro set "jelled" and became comfortable an assembler could be written to handle the instructions natively (ie., faster).

Any macro assembler that has the flexibility to let you write macros that specify exactly what bytes you want where should do. If a 65xx-assembler won't permit macros with the same names as existing instructions (<cough> HXA65 </cough>), perhaps an assembler for another cpu would (<shameless plug> HXA_T </shameless plug>).

Many assemblers have the MACFIRST directive which allows using macros to re-define mnemonics.

I could probably tweak the source for mine in a couple of hours. I'll have a try at the weekend

_________________
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

That would be very much appreciated!

I'm using a modified version of Dave Beazley's assembler, which is better than hand-assembling, but it does have limitations.

Cheers
Ed