Cross Development Tools

[simonsunnyboy]

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

I have used Cmake to generate a Code::Blocks IDE project with it. that worked well for me. It can also generate plain makefiles or Eclipse projects.

http://www.cmake.org - i also have some example source on github. I can post a link when I get back from Christmas vacation.

[mikro]

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

No, that's standard naming scheme for cross compilers. "gcc" would mean a native cygwin compiler.

[Mikefulton]

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

No, that's standard naming scheme for cross compilers. "gcc" would mean a native cygwin compiler.

Yes... I'm aware of the "standard". I've just always thought it was stupid.

[mfro]

Yes... I'm aware of the "standard". I've just always thought it was stupid.

I consider that a life saver if you have more than one toolchain on a single machine. You almost never need to type that anyway since probably no non-trivial program can be build by just directly calling the compiler.

If you do not like (or need) it, you can always shorten the number of required keystrokes by a set of links:

Code: Select all

for i in /usr/bin/m68k-atari-mint-*
do
    ln -sf $i /usr/bin/$(echo $i | sed -e 's#m68k-atari-mint-##')
done

which is much easier than the other way round. But beware of your native tools.

[Anima]

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

No, that's standard naming scheme for cross compilers. "gcc" would mean a native cygwin compiler.

Yes... I'm aware of the "standard". I've just always thought it was stupid.

In fact, you can add the "C/C++ GCC Cross Compiler Support" using Eclipse (via "Install new software...") so that you can use the "m68k-atari-mint-" prefix for the compiler.

[Mikefulton]

Try CodeBlocks IDE with a custom makefile

So I have installed CodeBlocks IDE, I've installed Cygwin and the cross compiler files.

Do you have an example of this custom makefile you can share? Project definitions, target definitions, anything like that?

[RicardoF1RST]

There used to be SNASM which was a hardware SCSI interface which fitted to the target machine (different units for all of them including ST) and talked to an ISA card in a PC. Typically the PC ran BRIEF text editor and assembled the 68k then transferred the target file over SCSI to the ST. A remote debugger (on the PC) could then monitor the memory of the ST live.

There was a software solution too, which I mainly used, called BogeyDev, which ran on an ST and used the parallel port to talk to other ST's and Amiga's (the target machine) which offered most of the benefits of SNASM and operated in the same way (using Tempus text editor and DevPac assembler) but only needed a parallel cable (no hardware).

[simonsunnyboy]

Try CodeBlocks IDE with a custom makefile

So I have installed CodeBlocks IDE, I've installed Cygwin and the cross compiler files.

Do you have an example of this custom makefile you can share? Project definitions, target definitions, anything like that?

Any Makefile for your project will do. You have to use the dialogues of the IDE project to configure the targets. It can be tedious and you have a problem when the C::B project file gets corrupted.

That is why I prefer generating it it with Cmake and a similar CMakeLists.txt like this one:

Code: Select all

cmake_minimum_required(VERSION 2.8)
project("wizzcat.tos")
# disable strange gcc assumptions
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")

# select Atari ST cross compiler
enable_language("ASM")

set(CMAKE_C_COMPILER m68k-atari-mint-gcc)
set(CMAKE_ASM_COMPILER m68k-atari-mint-as)
set(CMAKE_AR m68k-atari-mint-ar)
set(CMAKE_RANLIB m68k-atari-mint-ranlib)
set(CMAKE_C_FLAGS "-m68000 -O3 -fomit-frame-pointer -Wall -mshort -nostdlib -std=c99")
set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_C_FLAGS} ${PROJECT_SOURCE_DIR}/startup.S" )
set(CMAKE_ASM_FLAGS "-m68000 -I${PROJECT_SOURCE_DIR}")

link_directories(${CMAKE_SOURCE_DIR})

include_directories (
	src/
)

add_library(wizzcat
 src/wizzcat.S
 src/wizzcat.h
)

add_executable(wizzcat.tos
 main.c
)

target_link_libraries(wizzcat.tos wizzcat)

This is an example with custom startup code (to get rid of the bulky Mintlib) and assembly language sources. Full package is on github.

To generate the project for Code::Blocks, you call cmake:

Code: Select all

cmake -G "CodeBlocks - Unix Makefiles" path-to-configfile

This ejects a .cdp file you open with Code::Blocks and prepares compile targets. Note that you cannot deug them from within. That must be done with an emulator or with a debugger on the Atari target.

[Mikefulton]

There used to be SNASM which was a hardware SCSI interface which fitted to the target machine (different units for all of them including ST) and talked to an ISA card in a PC. Typically the PC ran BRIEF text editor and assembled the 68k then transferred the target file over SCSI to the ST. A remote debugger (on the PC) could then monitor the memory of the ST live.

There was a software solution too, which I mainly used, called BogeyDev, which ran on an ST and used the parallel port to talk to other ST's and Amiga's (the target machine) which offered most of the benefits of SNASM and operated in the same way (using Tempus text editor and DevPac assembler) but only needed a parallel cable (no hardware).

I remember thinking "why?" with regards to SNASM back in the day, since Atari's own DB debugger supported remote debugging via the MIDI ports with an optional stop-button wired up via the serial port. Much simpler setup.

[Mikefulton]

Try CodeBlocks IDE with a custom makefile

So I have installed CodeBlocks IDE, I've installed Cygwin and the cross compiler files.

Do you have an example of this custom makefile you can share? Project definitions, target definitions, anything like that?

Any Makefile for your project will do. You have to use the dialogues of the IDE project to configure the targets. It can be tedious and you have a problem when the C::B project file gets corrupted.

That is why I prefer generating it it with Cmake and a similar CMakeLists.txt like this one:

Code: Select all

cmake_minimum_required(VERSION 2.8)
project("wizzcat.tos")
# disable strange gcc assumptions
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")

# select Atari ST cross compiler
enable_language("ASM")

set(CMAKE_C_COMPILER m68k-atari-mint-gcc)
set(CMAKE_ASM_COMPILER m68k-atari-mint-as)
set(CMAKE_AR m68k-atari-mint-ar)
set(CMAKE_RANLIB m68k-atari-mint-ranlib)
set(CMAKE_C_FLAGS "-m68000 -O3 -fomit-frame-pointer -Wall -mshort -nostdlib -std=c99")
set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_C_FLAGS} ${PROJECT_SOURCE_DIR}/startup.S" )
set(CMAKE_ASM_FLAGS "-m68000 -I${PROJECT_SOURCE_DIR}")

link_directories(${CMAKE_SOURCE_DIR})

include_directories (
	src/
)

add_library(wizzcat
 src/wizzcat.S
 src/wizzcat.h
)

add_executable(wizzcat.tos
 main.c
)

target_link_libraries(wizzcat.tos wizzcat)

This is an example with custom startup code (to get rid of the bulky Mintlib) and assembly language sources. Full package is on github.

To generate the project for Code::Blocks, you call cmake:

Code: Select all

cmake -G "CodeBlocks - Unix Makefiles" path-to-configfile

This ejects a .cdp file you open with Code::Blocks and prepares compile targets. Note that you cannot deug them from within. That must be done with an emulator or with a debugger on the Atari target.

I kinda gave up on getting this going for the moment. I might come back to it later, but for now I'm just editing source on the PC side but I tab into Lattice C on STEEM to build.

[RicardoF1RST]

I remember thinking "why?" with regards to SNASM back in the day, since Atari's own DB debugger supported remote debugging via the MIDI ports with an optional stop-button wired up via the serial port. Much simpler setup.

Because SNASM provided the same development environment for ST, Amiga, Amstrad, C64, Spectrum, Megadrive etc etc... You just needed the right target interface. My favourite bit of SNASM were the macros they provided for BRIEF. I miss being able to double click a subroutine name (in the call) and instantly be viewing/edit the subroutine, then be able to return to where you were.

[helmut]

Because SNASM provided the same development environment for ST, Amiga, Amstrad, C64, Spectrum, Megadrive etc etc... You just needed the right target interface. My favourite bit of SNASM were the macros they provided for BRIEF. I miss being able to double click a subroutine name (in the call) and instantly be viewing/edit the subroutine, then be able to return to where you were.

That's called tagging. Many editors can do that, including vi.

-Helmut

[Mikefulton]

I remember thinking "why?" with regards to SNASM back in the day, since Atari's own DB debugger supported remote debugging via the MIDI ports with an optional stop-button wired up via the serial port. Much simpler setup.

Because SNASM provided the same development environment for ST, Amiga, Amstrad, C64, Spectrum, Megadrive etc etc... You just needed the right target interface. My favourite bit of SNASM were the macros they provided for BRIEF. I miss being able to double click a subroutine name (in the call) and instantly be viewing/edit the subroutine, then be able to return to where you were.

I was aware of all that. I was the guy at SCEA who dealt with SN Systems back in the original PS1 days.

For an embedded system where you didn't develop natively in the first place, SNASM was great. No doubt about it. But very few developers back in those days did non-native development for any of the current computer systems where native development was an option. For those developers, at least for the ST, SNASM was an expensive option to spending $20 on some MIDI cables and a custom cable for the stop button, and since SN Systems didn't do a complete ST tool chain, you still probably ended up doing mostly native development anyway.

[RicardoF1RST]

I never spent any money on SNASM, it came with the job. To be honest I preferred Bogeydev on my MegaST connected to 1040ST and Amiga via a printer lead, that worked really well. The only machine I developed native on was the BBC Micro after that everything was remote. It would have been a tad tricky to develop on an Amiga when (nearly) every byte of RAM was being used by the game.

[Mikefulton]

I never spent any money on SNASM, it came with the job. To be honest I preferred Bogeydev on my MegaST connected to 1040ST and Amiga via a printer lead, that worked really well.

Bogeydev wasn't really known in the US back in those days. Would have been nice to know about it, but somehow the information never really filtered up to Atari Sunnyvale. That was unfortunately true for a lot of stuff. I suspect the European developers might have assumed their local subsidiary was telling us about it, and maybe the subsidiary thought the developers were, but in many cases neither was true.

The only machine I developed native on was the BBC Micro after that everything was remote. It would have been a tad tricky to develop on an Amiga when (nearly) every byte of RAM was being used by the game.

You're saying "develop" but it sounds like you're really talking just about remote debugging.

Just doing remote debugging isn't really cross development. That's where you edit your source code, compile, assemble, and link your executable program file on a different kind of system. Basically you can do everything except run the code.

Back in the heyday of the ST and Amiga there were very few options for cross development. The GNU tool chain didn't exist yet in the early days, and what few cross development tools you could find were generally very expensive and not specific to Atari.

I know a few people who edited their source code on a PC so they could use their favorite editor, but they still had to copy it all back over to the ST to do a build.

[joska]

Just doing remote debugging isn't really cross development. That's where you edit your source code, compile, assemble, and link your executable program file on a different kind of system. Basically you can do everything except run the code.

I edit, compile, assemble and link on my Falcon/Afterburner, then upload and execute the code on an STE via a parallell cable. Is this native development or cross development?

[Frank B]

Just doing remote debugging isn't really cross development. That's where you edit your source code, compile, assemble, and link your executable program file on a different kind of system. Basically you can do everything except run the code.

I edit, compile, assemble and link on my Falcon/Afterburner, then upload and execute the code on an STE via a parallell cable. Is this native development or cross development?

Ricardo did you manage to rescue your sources for your ST game? I know the Amiga guys asked for a release on EAB. Is there any chance you could release the sources? It would be awesome to STe-ify an original unreleased game too. If you're having issues on the Mega people here can probably help you out.

[RicardoF1RST]

I'm going to build a new copy (of Ramrod) as an ST floppy image file, then try that in an Emulator - we shall see.

Bogeydev was written by Colin Dooley (Aka. Fungus, as in Fungus The Bogeyman - he changed his name, accounts could never work out that his middle name was "The" hence middle initial was "T.") for internal use at Gremlin Graphics. It was a shell written and running on an ST from which you could launch a text editor (Tempus) an assembler (DevPac) then transmit the object file (without symbols) to a remote machine (ST or Amiga) via the parallel cable.

On the remote machine there was just a small bit of code running from a floppy (512 bytes I recall, just a boot sector which left the other 511.5K available) that listened to the parallel interface and looked after the basics on the target machine.

The file transfer was hash totalled in 256 byte chunks so sections could be skipped to speed up the transfer. Once transfered a debugger could single step code, watch/edit memory, set breakpoints etc etc.

SNASM provided the same feature set, except it included a bundled assembler, was PC based, and was mainly used with BRIEF (text editor). I could never work out why SNASM used a SCSI interface to over complicate things - that made things expensive, when prior to that parallel leads and serial cables were fine. But then I guess, Bogeydev was dealing with object files circa 30-60K, SNASM 512K ... so I guess as games got fatter the interface speed needed to. After all computers are never fast enough

There was also a system used by all the 8-bit guys on C64, Spectrum, Amstrad, Atari400/800 etc. But I don't think that had remote debugging, just editing and assembling then firing down a shared high speed serial interface from the Pinnacle (I recall, possibly a CP-M box) server to the target machine. That allowed 8-bit development with the aid of a hard drive I guess.

You have to remember that to all intents and purposes all the early computers were effectively consoles with keyboards. Their operating systems were either too basic or too heavy on resources. Hence remote development was the only option, really, once you had killed the operating system - it was a no brainer.

[RicardoF1RST]

You're saying "develop" but it sounds like you're really talking just about remote debugging.

As I recall, SNASM was by "Cross Products" - hint in the name there.

I wrote the code, assembled it and managed all the files required by the game on a development machine which was either a Mega4ST with 16MHz 68K (with external CPU cache) or on a 386DX40 PC. The object file (generated by the assembler) was then transferred to the target machine via either a parallel printer or SCSI cable to either a 1040ST or A500 (1MB) Amiga which had a 512 byte bootstrap running on it. The code on the target machine could request files from the development host or from floppy within the target (via track/sector/length requests - no real file system).

I call that Cross Development, and thats the system everyone I knew used at US Gold, Gremlin Graphics and Probe.

Come to think of it, Bogeydev needed a bit of RAM for its bootstrap, but I imagine the SNASM system contained some ROM which looked after that side of things which freed up another 512 bytes ... hadn't thought of that before - SNASM didn't need a floppy disc.

[RicardoF1RST]

then transmit the object file (without symbols) ...

Come to think of it, it may have transmitted a symbol file too - that rings a bell, but it was a while ago(!).

[Mikefulton]

Just doing remote debugging isn't really cross development. That's where you edit your source code, compile, assemble, and link your executable program file on a different kind of system. Basically you can do everything except run the code.

I edit, compile, assemble and link on my Falcon/Afterburner, then upload and execute the code on an STE via a parallell cable. Is this native development or cross development?

You're developing natively on TOS and remote debugging.

[Mikefulton]

You're saying "develop" but it sounds like you're really talking just about remote debugging.

As I recall, SNASM was by "Cross Products" - hint in the name there.

Yes, I mentioned SN Systems because the guys from Cross Products went on to start that company.

I wrote the code, assembled it and managed all the files required by the game on a development machine which was either a Mega4ST with 16MHz 68K (with external CPU cache) or on a 386DX40 PC. The object file (generated by the assembler) was then transferred to the target machine via either a parallel printer or SCSI cable to either a 1040ST or A500 (1MB) Amiga which had a 512 byte bootstrap running on it. The code on the target machine could request files from the development host or from floppy within the target (via track/sector/length requests - no real file system).

I call that Cross Development, and thats the system everyone I knew used at US Gold, Gremlin Graphics and Probe.

I'd call SOME of it cross development, and if you had mentioned some of those details earlier I would have responded differently.

But not all of it qualifies. Cross development means developing on one machine for a target that uses a different operating system, a different processor, and other different hardware. Using the PC to build for ST or Amiga was cross development. Using the MegaST to build for ST was not.

It's all very interesting, but this thread was supposed to be about modern options for cross development, not a trip down memory lane to 1990 and what options were available back then.

[RicardoF1RST]

I disagree, cross development is creating on a development machine and transferring to the target. Remote debugging can be done with a hand held tool, but add in assemblers etc and it becomes cross development. If the target ST was running TOS maybe to be pedantic it wasn't cross development, but it wasn't running TOS, the first routine my code executed was called TOS_OFF (no pun intended) but I would call it remote development.

I also consider targeting the same CPU as the development machine, as cross development. Otherwise by your analogy developing on a MegaST, targeting an Amiga isn't cross development.

I agree this has become off topic, so I'll go away.

[Mikefulton]

I disagree, cross development is creating on a development machine and transferring to the target. Remote debugging can be done with a hand held tool, but add in assemblers etc and it becomes cross development. If the target ST was running TOS maybe to be pedantic it wasn't cross development, but it wasn't running TOS, the first routine my code executed was called TOS_OFF (no pun intended) but I would call it remote development.

I also consider targeting the same CPU as the development machine, as cross development. Otherwise by your analogy developing on a MegaST, targeting an Amiga isn't cross development.

I agree this has become off topic, so I'll go away.

Don't forget that we're really taking a shortcut to saying "cross-platform development", meaning that you're developing on a different platform (i.e. Operating system, hardware architecture, possibly a different CPU) than the target machine.

Atari -> Amiga qualifies as cross-platform development. The CPU is the same but they're different platforms.

Simply transferring code to a different machine as part of remote debugging doesn't qualify if both machines are the same platform.

[RicardoF1RST]

Exactly, the target wasn't TOS, hence a different platform.