SpritesMind.Net

I'm looking for an alternative to the vasm assembler for 68000 work; I'm not a fan of its non-commercial-only license.

Vasm is nice enough, though I have to work around some of it to get the output how I like. My first thought of an alternative would be GNU gas, but finding a precompiled x86 Windows binary targeting 680x0 will be a hassle. I like that vasm targeting 68000 is a single exe file, but GNU tools tend to be a big lump of things all together.

Are there any alternatives to vasm that are similar? If it supports the same syntax, even better!

I've always liked asmx: http://xi6.com/projects/asmx/

Handles a number of different processors, including the Z80 and the 68000.

There is such a Windows gas included in sgdk. That said, eww, Windows.

And to be honest GAS is probably the worst 68000 assembler :p

About the only thing gas has going for it is that it's the easiest to make work with gcc for a mixed C/C++/asm program.

The syntax is pretty non-standard, which is probably the main problem people have with it.

About the only thing gas has going for it is that it's the easiest to make work with gcc for a mixed C/C++/asm program.

Being able to compile it and run it on any platform is a big plus if you're into that.

I've found a lot of the GNU stuff for x86 targeting 68000 here, and I've started to get my head around the process I'd need to do to get binary output out of it

http://vincent.riviere.free.fr/soft/m68k-atari-mint/ (edit wrong link)
https://sourceforge.net/projects/mingw-gcc-68k-elf/

as input.asm -o output.o
objcopy -O binary output.o output.bin

can also

objdump -d output.o

to get a disassembly of the object code.

But, yeah, I'm not a fan of this GNU syntax where the registers have to be prefixed with % and $ means a literal, and not a hexadecimal value. Things like d0 are silently treated as symbols, and since they wouldn't be initialised, they'd be treated as a value of 0. It's not at all like the syntax I'm used to - I believe vasm's syntax is similar to Devpac?

I had a quick look at asmx - no precompiled binaries is a pain in the nuts, but I'll try it.

asmx is compiled and working. It's not a drop-in replacement for vasm, but it's definitely a start. It pads with FF rather than 00, and some behaviour is different than vasm, resulting in my dc.l Mega Drive header vanishing entirely when I'm not looking. Working on it

https://imgur.com/3X9ALBL

MrD wrote: ↑

Wed Apr 22, 2020 8:16 pm

But, yeah, I'm not a fan of this GNU syntax where the registers have to be prefixed with % and $ means a literal, and not a hexadecimal value. Things like d0 are silently treated as symbols, and since they wouldn't be initialised, they'd be treated as a value of 0.

You can avoid the gas prefixes by using the flag --register-prefix-optional. Using 0x instead of $ isn't that bad - it matches C/C++ better, so I think that's more a consistency thing. When you use the --register-prefix-optional flag, register names work as expected, so you don't have to worry about them acting as symbols.

Note about asmx: Herb Johnson's fork http://www.retrotechnology.com/memship/asmx.html is ahead of the one on Bruce Tomlin's website http://xi6.com/projects/asmx/

Specifically, there's a bug in Bruce's current version where object output files are opened as text not binary so Windows users will have 0A bytes output as 0D 0A. (incbins are also opened as text).

The result of a strange few minutes comparing the output of vasm and asmx, seeing asmx picking less efficient branch instructions for un-sized beq and somehow not reproducing an incbin correctly.

Also @Chilly: how am I supposed to copy-paste maths routines from the 80s into my code blindly if the syntaxes don't match?? You want me to think?

Thanks for the link on that. As to thinking, sometimes that's a good thing. When copying over old code and then updating it for gas syntax, I've sometimes spotted something I could change to make it better. Most people learn a bit over the years, and no code is perfect. You might even spot bugs that should be fixed. That said, if the code is long enough, I just use macros in the editor to alter the syntax for me. Advanced search-n-replace FTW!

Hmm - wonder if it's got these changes as well...

viewtopic.php?f=7&t=744

EDIT: No, it doesn't. Well, not all of them. It has the "w" to "wb" fix, but not any of sik's asm68k.c fixes. However, I found another bug in asmx.c similar to the "w" to "wb" issue: at line 4731 in the july2017 asmx.c (also in the original asmx.c), there is
That's a binary include, and as such should be "rb". Apply that fix to asmx.c and sik's patches to asm68k.c.

After doing asm on several platforms I have to recommend gcc/gas. Why? Because macros are quite powerful, not perfect, but good enough to make extend programing simpler than others.
(I know I touched a sensitive point, waiting for massive angry replies… )

Stef wrote: ↑

Wed Apr 22, 2020 9:08 am

And to be honest GAS is probably the worst 68000 assembler :p

Can you justify that?
I mean, yeah sure you need to tweak it a bit to be human friendly, but is very useful once done.

Very true - the C preprocessor can be run on gas files (use .S instead of .s for automatically doing so). Pragmas and defines and stuff can be used. This does make a gas assembler specific file very flexible compared to more traditional assemblers.

Define would be nice, since I can't see any support for register lists (for movem) in asmx and no way to fake it with macros.

Miquel wrote: ↑

Thu Apr 23, 2020 4:25 pm

Stef wrote: ↑

Wed Apr 22, 2020 9:08 am

And to be honest GAS is probably the worst 68000 assembler :p

Can you justify that?
I mean, yeah sure you need to tweak it a bit to be human friendly, but is very useful once done.

To be honest, that is the one i'm using But the default syntax is really terrible until you use the --register-prefix-optional option. Also it doesn't support local label or macro for instance... Something i like to use when possible. But looking the last Chilly Willy post it seems to support C processor, i wasn't aware of that ! Does it requires .S extension for that ? Define can replace macro (not exactly but that would help already).

It doesn't require using .S, but if you don't, you'll have to invoke the preprocessor manually from the makefile. It's easier to just use the .S extension and then go to town with #define and whatnot. That's what the .S does - signal gcc that it should automatically invoke the preprocessor before invoking the assembler.

Perhaps the handiest thing about being able to use the preprocessor is defining structures in the regular C manner. Defining structs in assembly is always more of a hassle.