Thank you all for your generous contributions! :great This thread has proven to be way more valuable than I'd ever imagined. I should probably even change the subject, actually.. :)

As mentioned earlier, I'll be fine with AsmPro for a while, being the noob that I am, experimenting on the quite-low-level hardware that I have. However, I'll hopefully reach the point were I'll have some of my own libraries, which should be reusable across projects and independently developable (not sure that's a word, though). Anyway, would that be the point to start looking out for the next step? Because that'll probably require some control over how things are compiled and linked -- ie, something like a makefile, I guess.

First on the list would be PhxAss, as it has been mentioned several times -- and not only by its developer. ;) If I understand correctly, this is 'only' an assembler -- I mean, just like in the vasm scenario, you'd need a linker (eg, vlink) and an editor (and preferably also a debugger) on top of that to do the 'makefile scenario' above. Is this about right?

I'd also like to take a look at devpac, *the* reference m68k assembler. I'm not entirely sure what that means, but it sounds profound enough to at least give it a go. ;) Can't seem to find it on aminet, however, and highsofts site seems to be abandoned. Where can I get it?

Some things are much faster to code in C and performance isn't always important so you may want to mix assembler and C as well as breaking assembler code into modules. This is where vasm becomes more convenient, especially if cross-compiling/assembling. There are features, flexibility and optimizations which make some assemblers nicer than others. I really like assemblers which can optimize branches in both directions for example but this isn't as important for someone learning.

PhxAss and vasm can both create an Amiga executable without an external linker.

Devpac comes with an editor and debugger and is very professional. It is AmigaOS friendly and worked with RTG last I tried. It is certainly worth taking a look at. There should be versions on the EAB file server. The down sides are that the assembler is slower than vasm, it needs more resources than most other assembler environments and it is no longer supported.

Well my original plan actually was to code in C. I'll be going for something demo-like, so performance might be an issue, but I could probably add some assembler code into the mix if necessary. Still, the most comprehensive beginner tutorial towards programming a demo is Photons series, afaik, so I decided to take a closer look at the assembler way. I haven't learnt how to break assembler code into modules, atm, I'm afraid..

Cross compiling is still on my to-check-out list. I've also been looking into this, btw: http://eab.abime.net/showthread.php?t=85474
I'm not really sure why I'm still trying to develop on the actual hardware, tbh. I'm used to code in visual studio, for crying out loud! :rolleyes

Does that include the case when you only have an .object file of the lib you want to use? In visual studio parlance: can you reference a .dll/.lib file?

Alright, I'll check that out.

Saw this and made a small update to AsmTwo tonight (same link)

- supports absolute paths for all includes via : in path
- incdir "" to fix relative paths from older AsmOnes is not required anymore

The archive is compressed on Amiga and will preserve Amiga file system attributes, but only if decompressed on the Amiga. (Just a difference in file systems, my usual CLI 'magic' is "protect [file] rweds".)

A .dll (Windows Dynamic Link Library) or .so (Linux Shared Object) are shared link at run time objects but the 68k AmigaOS has nothing similar. AmigaOS 4 did introduce .so objects in PPC to make porting Linux code to the AmigaOS easier. Some people think this was a bad move and that they should convert all .so files to AmigaOS .library files as .so files are picky about having the exact version, they use CPU power at run time and the CPU needs efficient large PIC (Position Independent Code) support. PIC support on the 68000 is only efficient with small code sizes, the 68020 ISA is much better and I showed how a 68k ISA extension could make the 68k have one of the cleanest and most efficient large code PIC supports of any CPU not that very many people cared or noticed. I still don't know if .so files are a good idea to introduce to the 68k. It might be possible to build .so files for 68k AROS (I believe requires 68k ELF link files which AROS uses) already but I don't know of any support in AROS.

Link (at compile time) libraries for the 68k AmigaOS use the .lib suffix for SAS/C and vbcc (.lib files in Windows may be something completely different). GCC link libraries use the .a suffix. Usually .so or .dll files can be turned into link libraries for the 68k. You would need a linker for combining multiple link libraries (.lib) and/or object files (.o) at compile time. I use the linker all the time with a CED ARexx script (assemble+link) as the linker has more features. If wanting to share code, there is documentation on Aminet on how to make shared AmigaOS libraries (.library).

I used to use Devpac 3 and from what my memory tells me, I switched to AsmOne because Devpac didn't support some things like local labels.

I was using AsmTwo for a while but I switched to the latest version of AsmOne due to the extended features of the latest version of that and also for the support for assembling code for 68020+ and the FPU. If AsmTwo was branched off the latest version of AsmOne then AsmTwo would be epic.

Maybe AsmThree will be made one day combining all the features of everyone's favourite Amiga assemblers so we can then all universally agree that AsmThree is the assembler to use :P

Yes, own libraries is a very good thing to have and makes your life easier. Can't live without mine.


You don't need to. In VS you include the .lib to either use some .dll or for use of stactically linked functions, but on the Amiga you just OpenLibrary() something and then call the functions.

However, as the average libs: dir is quite full of various libs from various people, it may be better to use simple include files containing your own reusable functions. By using conditional assembly you can avoid including what you don't use in your current project ; this is what i did.

Well the .library approach may be a little clumsy to use, but it's well known and definitely something I'd like to know how to do. So I've been trying to assemble this project: http://aminet.net/package/dev/asm/Random250Lib. This should allow me to assemble the random250.library from its assembler source -- giving me both an example of how to do this and an actual random number generator (always nice to have). Remember I'm still using AsmPro.

When I first tried to assemble it, it gave a file error in the first include (Exec/Types.i). According to the AsmPro docs, I should put my include files in AsmPro:Include, but this unfortunately doesn't seem to work. I can only get it to assemble if I copy the exec folder (from Include_i, from NDK39) to the folder that contains the source. Neither of the above solutions seems satisfactory to me, as they both involve copying folders and files around. I could not find another way to add an include path to AsmPro. Am I missing something? Can I maybe set something like a (linux) symbolic link in my project folder to where the SDK actually is?

Also, having assembled it without errors, I can't see any output. I was expecting that it would generate the random250.library file, but it doesn't (I've renamed the one that came precompiled). Here also, I'm clearly doing something wrong. I guess it compiles to memory, and I should redirect that or something? :confused

Great to see you on this thread, Photon, and even better to see you're still working on this. :great

And many thanks for the tutorials; they're a real eye opener to me -- and I'm not even halfway through them.. ;)

Ok, I need to assemble it and then use 'write object' to save to file, apparently.. :rolleyes

Ah, the joy of system includes... Well, it's not for nothing that i just never use them :D

You don't need a symbolic link, just to find some include directory config in AsmPro - there ought to be some !
If you don't find how to do that (i can't help with AsmPro itself, sorry), at last resort some INCDIR directive in the source will do.

One would think so, indeed, but I can't seem to find it. If anybody knows how to set this in AsmPro, please let me know.

Excellent advice, thanks, that works! :great Seeing as this will usually be very similar from project to project, I could even actually live with this.

My asm-one code compiles fine in asm-pro 1.17:
Just use INCDIR to point where you have all the include files.

Thanks for your input, but we've (well, meynaf, really) already established this is indeed a working solution. :agree

I'm still not sure this is actually the way you're supposed to do it, though. Is there really no way to set an (and preferably several) include path(s) in AsmPro? So you don't have to modify the source?

Ah, damn... Yeah, I missed that somehow. After several reinstalls of windoze, drivers and other crap my eyes are bloodshot and my brain cells are too busy commiting suicide to pay attention to details ><.

Hmm, not sure. If it's heavily based on the original Asm-one source by R.G.M., which I think is the case, it only supports one include directory (which you can change multiple times with INCDIR).

Don't worry about it; you apparently still have enough brain cells to point me into a working direction. :great

I still don't know how to properly set this include path in AsmPro, unfortunately, other than adding an IncDir in the source.. :banghead

Hmm, doesn't it use the default directory? You can set that by pressing ramiga-[. Then if you don't use INCDIR it should look for includes in that directory.
You can also use V (command line) to set it or print its contents (so it should tell you to what exactly it's currently set). Something like cwd/pwd change/print working directory on unix.
So in my case, I would use "V Work:Developer/Include/" and as long as all the includes are there it would work.

Yep, setting the 'default dir' to the system include path apparently seems to work. I thought that this was used for something else, though..

Oh, and it also looks in the dir containing the source. (which was where I thought 'default dir' needed to point to for this to work)

The assembler you pick also depend on if you program on real HW, or if you use an emulator. I've been using WinUAE and started with DevPac 3, as that's what I used 20 years ago. But I quickly changed to using my favorite PC text editor and assembling with vasm. By doing that I'm not limited by the small screen size and the assemble time is instantaneous.