Aros/Developer/Porting software
From Wikibooks, the open-content textbooks collection
Contents |
[edit] Compilers and tools
[edit] Foreign and cross-platform APIs available for AROS
Before you attempt to port a program, make sure it's API dependencies are met on AROS.
ANSI-C/C++, SDL, GTK, Cairo, ...
[edit] Coding style
[edit] Hints: Porting software from...
[edit] AmigaOS
As long as no assembler code is being used in the program, compiling a C program written for plain AmigaOS up to version 3.1 should be possible on AROS without any changes to the source code. (That presumes your AROS is using a 32bit big-endian CPU, like the original Amiga computer.) (Please note that AROS is still beta and incomplete, and might lack some functions from AmigaOS API. See Status of AROS implementation for more on this.)
Some of the first things to consider is the actual size of your C data types, and in your uses of binary files (IFF for example) paying attention to reading and writing with portability to 64bit and little-endian CPUs as well as the classic mc680x0 or powerpc cpus used by Amiga OS. [we should probably have a chart showing sizes/endian used by manx/sas/dice C on a mc68000/68030 vs today's PPC/i386/x86_64 AROS options here along with some GCC source code to show how to read/write binary files correctly under AROS running on differing endian CPUs]
Screens: Amiga chipset graphics based screens were generally done in a planar format 16/32-colors max for ECS hires/lores modes respectively and 256-colors for AGA. [a chart of common amiga screen modes should go here] Methods that worked well for the relatively low resolution planar Amiga displays may be suboptimal for chunky and true color screens that are common today. [pointer to examples should go here] Amiga screens could be of differing resolution, which could be dragged up and down to reveal another, so some applications were written with differing resolution screens, say for a control panel at one resolution and another for the "display" visible at the same time stacked vertically. This may not make sense with today's chip sets or wide-screen displays. Opening multiple screens that vary in scan rate can confuse displays (monitors or projectors) that might take several seconds "calibrating" every time the user decides to change which public or private application screen they want to view. Defaulting to the user's preference for Wanderer (workbench) for screen mode is probably better than having a predefined mode hard coded into your application.
Fonts: AmigaOS 3.1 also shipped with some nice disk fonts that are not currently available under AROS, so you should be careful about having any diskfont hard coded as a default into your program. The ROM font "topaz" should be ok. [a chart of AROS fonts would be nice here]
ReAction (or: ClassAct), a GUI toolkit for AmigaOS, is not available for AROS. It has been made part of AmigaOS 3.5 and higher. Programs that use ReAction might need considerable rework, preferably to use Zune (or: MUI), AROS' GUI toolkit. [We could use a chart comparing gui options for developers here.]
GCC/G++ is the primary C compiler supplied with AROS. Amiga programs making use of other compilers' (SAS/C, Maxon C, ...) specific functionality might need some rework. You'll probably want to write makefiles that can run either hosted or native, so any AROS user can get them compiled and running on their machine. In a hosted environment the shell will most likely use UNIX semantics like cp==COPY ../==parent directory, and all file names will be case sensitive for your makefile and inside your C source code files (example: #include "myFile.h" != #include "MyFile.H"). Under AROS the makefile may use Amiga shell command semantics (copy #? progdir:prefs)or it may be using a UNIX shell ported to AROS, and the AROS environment, and like AmigaOS 3.1 may not care about case sensitivity of file names.
SAS/C was one of the more popular compiler packages back when AmigaOS 3.1 was released, it supported various keywords such as __chip for using chipram, and CPU related register arguments that the current AROS GCC does not.
