Cross Development Tools

[Mikefulton]

I am curious to find out whatever I can about what tools people are using for cross-development targeting the ST. I am primarily interested in tools running on Windows, but wouldn't mind hearing about Linux or Mac-based setups.

As I think I've said elsewhere, I'd forgotten how primitive the development environments on the ST really were. If I can get a setup going that uses GCC with the Eclipse GUI under windows, or something along those lines, that would be awesome.

I'd love to hear if any of the available solutions have a debugging setup? I'm thinking something that uses remote debug stub on the ST side, either hardware or emulator.

Please include download/info links where appropriate.

Anyway I'd love to hear what people are doing.

[troed]

I am curious to find out whatever I can about what tools people are using for cross-development targeting the ST. I am primarily interested in tools running on Windows, but wouldn't mind hearing about Linux or Mac-based setups.

As I think I've said elsewhere, I'd forgotten how primitive the development environments on the ST really were. If I can get a setup going that uses GCC with the Eclipse GUI under windows, or something along those lines, that would be awesome.

I'd love to hear if any of the available solutions have a debugging setup? I'm thinking something that uses remote debug stub on the ST side, either hardware or emulator.

Please include download/info links where appropriate.

Anyway I'd love to hear what people are doing.

Personally I'm using Devpac in both emulators and on target, but that's because partly what I want to do is to have the full retro experience.

A slight step up from that is to code in your favorite host computer environment and then launch gen.ttp (for example) from commandline in an emulator to compile, and again launch an emulator with the result on the commandline to test.

Further, you can use a VBCC cross-compiler setup (http://dhs.nu/vbcc/) and just do testing in an emulator. I haven't looked into remote debugging.

/Troed

[ggn]

Check out Vincent's cross-gcc tools here then: http://vincent.riviere.free.fr/soft/m68k-atari-mint/. It even supports gdb as long as you run mint but honestly I've never tried this particular option. However plain building is fine.

[Anima]

vasm and vlink need to be mentioned as well. They can be compiled on your preferred system and with a modern editor/IDE it's quite a good assembler development solution.

[Orion_]

For C development I'm using VBCC, and for ASM I use VASM (which has a devpac syntax compatibility mode), I compiled a Windows version available in the "Free Falcon demos/tools" link in my signature
For testing and debugging, I'm using Steem and Steem's debugger which is the most user friendly 68k debugger I've ever seen, I even use it to debug small 68k code portion for Jaguar, Megadrive or Falcon.

[AtariZoll]

My "cross development" tools are Notepad and Steem Debugger. Using that editor just because is more comfortable than some Atari editor with it's limited resolution and features. For assembling Devpac is best choice, and what I tried among cross development assemblers all had some flaws. Assembling in some emulator can increase speed up to 20x - what is good when dealing with larger sources.
I doubt that there is anything better than Steem Debugger for debugging Atari SW. Of course, C, Pascal coders may prefer specific debugger.

[dhedberg]

I'm on Windows and I'm using vasm, vlink and make. I've tried several editors but eventually fell in love with the amazing Sublime Text which also has support for 680x0 syntax highlighting. I cross-assemble on Windows and run on real hardware using PARCP-USB for automatic file transfers and remote execution.

[dml]

Currently I use cross-gcc v4.6 with a mixture of inline assembly and VASM for external .s files (using VASM 'aout' output format for .o linkables, all linked with gnu LN).

Have also been known to just use Devpac natively

[spiny]

I'm not a serious coder, but I use notepad++ on windows with STEEM. I have devpac open on the emulator with a simple .S file that just INCLUDEs a separate file that I edit using notepad, then I can just compile in devpac without having to open the file every time (and my code crashes a lot, so its compiled a lot of times )
Obviously, I test everything on a real ST once it's in PRG format

[Mikefulton]

Are people using cross-GCC just on the command line? No IDE environment?

[mfro]

Are people using cross-GCC just on the command line? No IDE environment?

I'm done with Eclipse, honestly. A huge, slow, overloaded beast that screws itself up every second update.

This does all I want: http://www.atari-forum.com/viewtopic.ph ... or#p252309

[Orion_]

Try CodeBlocks IDE with a custom makefile

[Mikefulton]

Try CodeBlocks IDE with a custom makefile

I'll check it out. Although... "custom makefile" ? I would expect a decent IDE to have project management and build functions as part of the package.

I'm also considering taking the plunge and figuring out how to do custom project templates in Visual Studio. I know it can be configured to use external compilers, linkers, etc. but I've never looked into doing it.

[Mikefulton]

Are people using cross-GCC just on the command line? No IDE environment?

I'm done with Eclipse, honestly. A huge, slow, overloaded beast that screws itself up every second update.

This does all I want: http://www.atari-forum.com/viewtopic.ph ... or#p252309

I wasn't necessarily thinking of Eclipse. I've never really had any problems with it, but I've generally preferred NetBeans for Java development, although for Android projects, Eclipse is the way to go.

[mfro]

I wasn't necessarily thinking of Eclipse. I've never really had any problems with it, but I've generally preferred NetBeans for Java development, although for Android projects, Eclipse is the way to go.

I was just referring to Eclipse since you were mentioning it in your initial post. Might be well suited for Java development (but I'm done with that as well ), but CDT is a nightmare to me.

I don't know if it will suit your taste, but libcmini (http://atariforge.org/gf/project/libcmi ... 2Ftrunk%2F) comes with a few simple GEM example programs that contain Makefiles supporting Vincent's cross toolchain (and its ability to generate different binary flavours for different Atari/clone targets). I generally prefer the commodity of an IDE but also like the flexibility of custom makefiles (and the freedom to not bind myself to a certain build environment). The libcmini example projects can be loaded into QtCreator but also build from the commandline on Linux, Mac OS X and Windows (using cygwin). These are still far from complete and imperfect in many cases but might be enough to get you going.

[Mikefulton]

Eclipse was just an example, not really a preference.

[mfro]

Eclipse was just an example, not really a preference.

you couldn't know you'll hit a sore spot over here

[Mikefulton]

Check out Vincent's cross-gcc tools here then: http://vincent.riviere.free.fr/soft/m68k-atari-mint/. It even supports gdb as long as you run mint but honestly I've never tried this particular option. However plain building is fine.

It says to install Cygwin 32-bit. Do we know why it specifies 32-bit in particular?

[joska]

Are people using cross-GCC just on the command line? No IDE environment?

I mostly use AHCC and PureC (and Devpac 3 on occasions) on real hardware, "cross development" usually means editing sources with gedit and compiling them using Devpac or AHCC under Hatari. I find modern IDE's to be total overkill when developing stuff for TOS/MiNT.

[Mikefulton]

Are people using cross-GCC just on the command line? No IDE environment?

I mostly use AHCC and PureC (and Devpac 3 on occasions) on real hardware, "cross development" usually means editing sources with gedit and compiling them using Devpac or AHCC under Hatari. I find modern IDE's to be total overkill when developing stuff for TOS/MiNT.

I'm not worried about things like automatic keyword completion and stuff like that. But, for example, Lattice C 5.6 doesn't even show a project window with the files in your project. Just opening a file to take a quick look takes a long frickin' time compared with what I'm used to, because I have to go up into the menus, choose open file, then navigate to the right place etc. I bounce around files a lot, and if it takes me 10 seconds instead of 1, that's a deal breaker.

[Mikefulton]

So I'm looking at Vincent Riviere's site, and the "quickstart" instructions for his stuff says:

1.Install Cygwin 32-bit. This will provide you a full UNIX-like environment necessary for running the GNU tools.
2.Install the following packages, using the Cygwin setup program: libmpc3.
3.Download and install cross-mint-cygwin-20141104-setup.exe.
4.Now you can use any tool prefixed by m68k-atari-mint-, such as m68k-atari-mint-gcc, m68k-atari-mint-g++, and even read the man pages.

My comments, and questions to the forum, are:

1. This is straightforward enough, because I've used Cygwin before on many occasions. I hadn't gotten around to installing it on my relatively new laptop yet, though, so I went ahead and installed it.

2. This presumes way too much knowledge about Cygwin and/or Linux systems. I have no idea how to run the "Cygwin setup program" and trying a command line of "setup libmpc3" did nothing useful. So now I'm stuck. How do I do this?

Figured it out... not that hard ultimately, but I still think it needs a more clear explanation.

3. Downloading it was easy enough. Haven't tried installing it yet... wanna get past step 2 first.

Just finished doing this. Easy-peasy.

4. Tools are prefixed by "m68k-atari-mint-gcc" because the existing names were too short? Sigh.



Well, theoretically I have it all installed now, but it is time for me to call it a night. Tomorrow I'll play around with building something within Cygwin's BASH shell, and then I'll look at configuring an IDE to use the tools.

[jfl]

Are people using cross-GCC just on the command line? No IDE environment?

I mostly use AHCC and PureC (and Devpac 3 on occasions) on real hardware, "cross development" usually means editing sources with gedit and compiling them using Devpac or AHCC under Hatari. I find modern IDE's to be total overkill when developing stuff for TOS/MiNT.

I'm not worried about things like automatic keyword completion and stuff like that. But, for example, Lattice C 5.6 doesn't even show a project window with the files in your project. Just opening a file to take a quick look takes a long frickin' time compared with what I'm used to, because I have to go up into the menus, choose open file, then navigate to the right place etc. I bounce around files a lot, and if it takes me 10 seconds instead of 1, that's a deal breaker.

My comment is a bit off-topic since I don't do cross development. I use the QED editor on my FIrebee (and compile natively with GCC). QED has a nice and simple project window which contains the files you need. It allows searching across all those files via a well designed search dialog. Also, QED's syntax highlighting is pretty good and easily tweakable.

I always have a desktop window opened on my current project; a right click on the .QPJ file launches the text editor with the project window with all the files I need, a right click on the .RSC file launches the resource editor and displays all the object trees. What more does one need

I'm with joska on this: anything more sophisticated than that always seemed overkill to me. With a "modern" well-configured desktop you can simplify many repetitive tasks.

[Anima]

Are people using cross-GCC just on the command line? No IDE environment?

This might be interesting for you as well: Cross compiling on the PC for M680x0 and DSP56001.

[joska]

I'm not worried about things like automatic keyword completion and stuff like that. But, for example, Lattice C 5.6 doesn't even show a project window with the files in your project. Just opening a file to take a quick look takes a long frickin' time compared with what I'm used to, because I have to go up into the menus, choose open file, then navigate to the right place etc. I bounce around files a lot, and if it takes me 10 seconds instead of 1, that's a deal breaker.

As jfl said, if you want to develop on real hardware you can use qed which has some really nice features. I use qed when I program in assembler, because the Devpac editor (actually, the entire IDE) is horrible.

My personal favourite when it comes to C programming for TOS/GEM is PureC and ResourceMaster. OK, PureC has no project manager window but it has many other really nice features. It has a rather good source level debugger, and the editor is quite good too. E.g. it has online help, press Help and it will look up what's under the cursor. If it's a library call or keyword it will display the appropriate documentation, if it's a function or variable it will jump to it's definition in your code. Press Undo and you jump right back to where you were. Any warnings or errors will appear in the compilation log window, double-click on the error and you will jump to the correct line in the code. I find PureC to be a very efficient tool.

AHCC works pretty much like PureC, but does not have a debugger. It's capable of producing ColdFire-friendly binaries though, and it has several C99-features PureC is missing.

[dml]

Well, theoretically I have it all installed now, but it is time for me to call it a night. Tomorrow I'll play around with building something within Cygwin's BASH shell, and then I'll look at configuring an IDE to use the tools.

If you get stuck making the toolchain work, I probably have some smaller projects that might help get you moving.

But once you get a helloworld.c compiling it should be downhill from there. It's all familiar stuff to anyone used to GCC.

BTW... TOS system specifics are defined in <mint/sysbind.h> or <mint/osbind.h>. Despite the naming, the compiled output for the mintlib and includes is TOS compatible, if a bit on the large side. The size overhead can also be overcome with a bit more effort.