MorphOS

This page contains platform specific notes about the MorphOS version.

Stack

Under MorphOS, the default stack is set to 256 kB. Stack size can be set directly by the programmer with a compiler switch (-Cs), or with the {$MEMORY} directive. The memory area for the stack is dynamically allocated on program startup, so if you set this value too high, in low memory situations your program may exit immediately on startup without any further notice.

Note to classic Amiga programmers: Increasing stack size with the 'stack' utility provided with MorphOS will not work because it sets the size of the 68k stack for applications running in 68k emulation.

Syscalls

Free Pascal currently supports ABox-style calls for MorphOS. You don't need to use additional hand-written assembly to call any ABox library function. However, you must declare every function you're going to use in the following way:

Var 
  my_LibBase: Pointer;

function my_LibCall(param1: longint location 'd0',
                    param2: longint location 'd1'): LongInt; 
         SysCall my_LibBase 1234;

Where my_LibBase is the library base returned by exec's OpenLibrary() call, and 1234 is the call offset. Please note that offset values in Free Pascal must be specified as positive values, and not negative as shown in MorphOS SDK.

The value after location can be any 68k register from d0-d7/a0-a5. Register a6 is used internally to pass my_LibBase in it. Register a7/sp cannot be used. Register names are not case sensitive. In SysCalls you must specify a location for every argument explicitly.

MOST IMPORTANT: You must open the libraries you're going to use explicitly before using any function from them, because the compiler will not do it for you. Don't forget to close all libraries before you exit.

Before declaring a SysCall function, please check the units provided with FPC, the function you want to use might already be declared in one of the units, ready to be used.

CHANGE: since 2004/08/22, my_LibBase can be a typed pointer, beside a dword and a void pointer. It's recommended to use PLibrary or the library's own type if one exists or possible.

Naming conventions

This section describes the differences between the official MorphOS SDK, which is for C language, and MorphOS-specific units in FPC RTL.

Constants

System constants are named exactly like in MOS SDK.

Structures

System structures are named similar like in MOS SDK, but follows the Pascal convention about type naming, so structure names has a T before, and each type has a pointer to type with P before the name. The following example should make things trivial:

 struct Task equals to TTask
 struct Task * equals to PTask

Function calls

System calls are named like in MOS SDK, but there are a few exceptions. Unfortunately MOS legacy (Amiga compatible) API has some name conflicts with Free Pascal RTL functions, and this issue cannot be solved with function overloading. These calls are available with a name prefixed by their library's name. So for example, exec.library's FreeMem() is available under the name execFreeMem(), and FreeMem() means the FreeMem() call of FPC's own heap manager. The following functions are known to be affected:

• exec.library
  • AllocMem() (only causes trouble inside System unit),
  • FreeMem()
  • Insert()
• dos.library
  • Close()
  • Read()
  • Write()
  • Input()
  • Output()
  • Seek()
  • Rename()
  • Exit()
  • Flush()
  • System()

Be prepared for more...

Alignment

Record elements are aligned to DWORD (4 bytes) under MorphOS by default. Use {$PACKRECORDS 2} if you need word aligned structures. For byte aligned records, use a packed record.

FPCMake

FPCMake is not yet working on MorphOS. Porting of the Classes unit must finish first.

Things good to know

Here are a few hints, which i think are good to remember, when using FPC on MorphOS.

• On program exit, System unit will close all files opened via it's own functions, so it's recommended to use them in most cases.
• Do not mix FPC's and the OS's file functions on a single file. It may work in some cases, but that's purely a coincidence. It's bad programming and can stop working anytime without notice.
• On program exit, the heap manager will free all memory allocated via it's own functions. It uses a memory pool to avoid fragmentation. It also makes debugging easier when using heaptrc unit. Using OS memory functions directly is not recommended.

To Do

There are still many things on the To Do list. Currently, these are the most important ones.

• Fix startup code to exit gracefully when stack cannot be allocated
• Clean up some messy parts of System unit
• Clean up DOS unit, and fix the bugs
  • (started, situation is much better now, worst bugs already fixed, in CVS)
• Clean up and finish SysUtils and Classes unit
• Start to implement MorphOS specific units:
  • Exec
  • DOSLib
  • Utility
  • Graphics
  • Hardware & Inputevent
  • Layers (started, not yet in CVS)
  • Intuition (started, not yet in CVS)
  • CyberGraphX (started, not yet in CVS)
  • AHI (started, not yet in CVS)
  • Timer
  • ...and more
• Release a snapshot
• Make snapshot releases regular
• ... and more

Thanks

The MorphOS http://www.morphos.net port of Free Pascal Compiler was possible, because Genesi S.a.r.l. http://www.genesi.lu provided a free Pegasos II/G4 http://www.pegasosppc.com machine to do the development on.