|
|
|
|
Amiga Hunk
|
| |
|
| |
Hunk is the executable file format of tools and programs of the Amiga "Classic" Operating System (up to AmigaOS 3.9) based on Motorola 68000 CPU and other processors of the same family.
This kind of executable got its name from the fact that the software programmed on Amiga is divided in its internal structure into many pieces called hunks, in which every portion could contain either code or data.
hunks in an Amiga executable file could exist in various types.
Discussion
Ask a question about 'Amiga Hunk' Start a new discussion about 'Amiga Hunk' Answer questions from other users |
Encyclopedia
Hunk is the executable file format of tools and programs of the Amiga "Classic" Operating System (up to AmigaOS 3.9) based on Motorola 68000 CPU and other processors of the same family.
This kind of executable got its name from the fact that the software programmed on Amiga is divided in its internal structure into many pieces called hunks, in which every portion could contain either code or data.
Hunk structure
The hunks in an Amiga executable file could exist in various types. There are 32-bit type hunks, 16-bit type hunks, and even some of 8-bit type.
Types of hunks were standardized in AmigaOS, and well documented in The AmigaDOS Manual edited by Commodore to explain to programmers how to code on the Amiga, during the years in which Commodore manufactured Amiga computers. Their structure was officially codified and could be changed only by a Commodore committee, which then communicated the modifications to the developers for new releases of the Amiga operating system.
The structure of an Amiga hunk is very simple: There is a header at the beginning of the hunk indicating that that kind of "portion of code" is a known and valid Amiga hunk type, then follows an ID which indicates the length of the hunk itself, and at the bottom is the segment of the hunk which contains the real code or data.
Features of Amiga executable files
Amiga executable files can be launched either from the graphical shell of the Amiga, the Workbench, from the Amiga's command line interpreter (called CLI, later AmigaShell), or even from a file manager tool.
No particular filename extension is required for Amiga executable files. For example, the calculator applet "Calculator" can be renamed to "Calculator.com", "Calculator.exe", "Calculator.bin", or even "Calculator.jpeg". These are all valid names for programs or tools, because AmigaOS does not differentiate between file extensions.
Some operating systems, such as MS-DOS or Windows, need filename extensions to recognize that a file is an executable. Usually, this extension is a three-character acronym separated from the real filename by a period ".".
AmigaOS adopted another method to recognize it is dealing with a valid executable. There is a particular sequence of bytes in the file header, yielding the hexadecimal value $000003f3. This sequence, which signifies an executable file and lets it be self-running, is called a magic cookie (from the magic cookies in Alice's Adventures in Wonderland by Lewis Carroll).
This kind of solution to identify executables on the Amiga was taken from similar solutions which were adopted by UNIX/Unix-like operating systems, where magic cookies are called magic numbers.
Even if this solution for identifying executable files is still in use in Unix, Unix-like systems have nowadays adopted a different system. The new system deals with file attribute bits and consists of setting the attribute bit "X" (stands for "eXecutable") in the table of attribute bits of the structure of the file itself.
Structure of an Amiga executable file
The internal structure of an Amiga executable file is very simple. In the beginning of the file there is the magic cookie, then is declared the total number of hunks in the executable, and just after this is the progressive numbers of hunks starting from "0" (zero).
The first hunk is always numbered zero, so if the executable is (for example) subdivided into three hunks, they will be numbered "0" for the first one, "1" the second and "2" the third hunk, and so on.
Just before the real hunks start is a table containing information about the length of any hunks present in the executable, and in the last part of the file are positioned the real hunks, each one described by its type name: HUNK_CODE, HUNK_DATA, et cetera.
Representation of the structure:
| Magic Cookie | Total number of hunks | Progressive number of hunks | Table of length | Various Hunks (Hunk_Code, Hunk_Data, etc) |
|---|
|
Hunk Types
Known hunk types into Amiga are:
| Name | Value |
|---|
| HUNK_UNIT | 999 | | HUNK_NAME | 1000 | | HUNK_CODE | 1001 | | HUNK_DATA | 1002 | | HUNK_BSS | 1003 | | HUNK_RELOC32 | 1004 | | HUNK_RELOC16 | 1005 | | HUNK_RELOC8 | 1006 | | HUNK_EXT | 1007 | | HUNK_SYMBOL | 1008 | | HUNK_DEBUG | 1009 | | HUNK_END | 1010 | | HUNK_HEADER | 1011 | | (not used) | 1012 | | HUNK_OVERLAY | 1013 | | HUNK_BREAK | 1014 | | HUNK_DREL32 | 1015 | | HUNK_DREL16 | 1016 | | HUNK_DREL8 | 1017 | | HUNK_LIB | 1018 | | HUNK_INDEX | 1019 | | HUNK_RELOC32SHORT | 1020 | | HUNK_RELRELOC32 | 1021 | | HUNK_ABSRELOC16 | 1022 | | HUNK_PPC_CODE | 1257 | | HUNK_RELRELOC26 | 1260 |
Metadata
Amiga could save metadata into hunks, as the hunk structure could be easily adapted to support this feature, but the hunk format of executables was abandoned in favour of ELF and there is no central authority (as the dismissed Commodore) which could implement this feature as one of the Amiga standards.
Amiga saves some metadata into files known as ".info" (so called from the name of their extension suffix). These ".info" files could be barely considered similar to the resource fork present in old Macintosh executable files, but generally speaking ".info" files are not equivalent to resource forks.
".info" files are created any time a project (datafile) is saved on disk. Example: When user saves a file called "MyProject" there will be created two files on disk called "MyProject" and MyProject.info".
Into the "MyProject" file are saved real data of the project file, while in "MyProject.info" file there will be stored the icon, and the information regarding the software which originated the file, so any time the project icon is invoked by clicking on it with mouse, there will be opened the parent software (users can change any time this information, allowing other programs to believe they created the project file rather than the original software which physically created it).
Into AmigaOS does not exist Application Binding as in other systems like MacOS.
Into the ".info" file are stored also some particular characteristics of the project file and the user comments.
".info" files do not appear on the Workbench Screen (Workbench is the default Amiga Desktop GUI). On the desktop screen it appears only the icon of the project file taken out of the "info file". In fact the icon is the virtual medium that connects the project itself and the metadata stored into ".info".
When the user clicks on the icon with left button of the mouse, the project ".info" calls the program which originated it. When the user clicks on the icon with the right button, then a dialog box will appear, allowing the user to interact with metadata contained into ".info file".
The ".info" files are copied or moved together with their associated project file, by moving the icon with the mouse, and can be viewed as standalone file through command line interfaces of Amiga such as AmigaShell, or using third party filemanagers or directory listers like Directory Opus or DiskMaster.
If the ".info" file represents an executable program, then into the ".info" are stored information about the stack of RAM buffers that could be reserved to the executable file (exp: 4096 or 8192 or 16384 or more bytes of RAM) and even the arguments that could be invoked by using a command line interface. For example into Amiga it is usual that a program could open its own graphic user interface screen independent from the desktop sceeen. By invoking arguments such as "Screen=800x600" and "Depth=8" into the info file dialog box, the user can save these informations into the associated ".info file" and then AmigaOS will open any time the productivity software into its own screen sized 800×600 with 8 bytes of colour depth (equal to 256 colors).
The same behaviour is obtained by invoking the productivity software into a command line interface by typing "nameofproductivitysoftware /screen800x600 /depth8".
This method of storing arguments associated with software into preference informations contained in ".info" files allows the Amiga users to use either command line interfaces or GUI graphical interfaces at the same time obtaining same results.
The user has also the choice of deleting ".info" files, but then he will renounce the benefits of having an icon representing the project file on the desktop, and will renounce to all the metadata contained into it.
Icons
A brief view of the bitmap icons contained into ".info" metadata files:
The icons are RAW bitmap data contained into ".info" files and are not standard Amiga IFF/LBM files. The users can deal with icons by using the AmigaOS standard program "IconEdit", present into O.S. since its early versions. Starting from AmigaOS 2.0 version IconEdit could import and save normal IFF/LBM files that are standard into Amiga.
Some Amiga programs like Personal Paint from Cloanto are capable to view, load and save bitmap data as normal Amiga Icons or into Amiga ".info" files already existing.
Ancient Amiga Icons are two-state icons, by using two different bitmap images. The first bitmap contains data of "quiet" icon, also known as "quiet state" of the icon. The second bitmap image contains data for the "selected" state of the icon. When user clicks twice on an icon and activates it, then the quiet icon bitmap data was suddenly replaced by selected icon bitmap data. Such a behaviour gives the Amiga icons an effect of moving cartoons.
Modern Amiga GUI graphic engines, such as ReAction GUI (equipping AmigaOS 3.9 and 4.0) and MUI (equipping AROS and MorphOS) have various modes of showing that an icon is in its "selected" state. These modes include: "Twice Icon Bitmaps" as in early AmigaOS, "Glow Contour" of the icon, "Icon Flashing" effect, "Inverse Color" effect, etcetera. The users could change this behaviour by choosing the icon panel into preferences dialog boxes of the associated operating systems.
All modern Amiga-like operating systems (AmigaOS 4.0/4.1, MorphOS and AROS) could associate either RAW bitmap data, or IFF/LBM files or also PNG files as standard internal bitmap image of any icon.
Other executable file formats recognized by AmigaOS
AmigaOS up to 3.9 recognizes various kinds of executable files other than Hunk format created for Motorola 68000.
Hunk_Overlay
The Hunk_Overlay type for Amiga executables was one of the standard hunk types created by Commodore. It was intended to solve the common problem of having a very small amount of RAM, which afflicted early low-end Amiga models. It implemented a method to run huge programs even on machines equipped with little RAM, in a time when a RAM expansion card and some RAM modules could cost more than an entire low-end computer.
Executables based on Hunk_Overlay structure have a root node which is in memory at all times, and the rest of the program is split into smaller modules. These smaller parts are loaded and unloaded as needed, so any programmer could fit a very large program into a small amount of memory.
Even if the creation of this hunk type could be considered smart in principle, the use of Hunk_Overlay in practice was so complicated and developer-unfriendly that developers usually avoided using this Hunk Type structure.
Extended Hunk format
In 1997, Phase5, an Amiga hardware manufacturer, launched their range of PowerPC (PPC) accelerators.
The PowerUP boards were dual-processor boards, incorporating the PPC and a 68K processor (68LC040, 68040 or 68060).
The AmigaOS still requires a 68K processor, while the PPC acts as an extremely fast coprocessor that carries out specific instructions. Unfortunately, this causes significant slowdown when the OS task switches between the 68K and PPC. In an attempt to solve the problems that were raised and the lack of performance by PPC processor, Haage & Partner, an Amiga software and hardware manufacturer (which also created AmigaOS 3.9), developed a competing API called WarpOS. The best feature of WarpOS is that it is system friendly with original Amiga executables which implemented the Amiga HUNK format. This format was called EHF (Extended Hunk format), and implemented the hunk type named HUNK_PPC_CODE.
ELF
Phase 5 implemented ELF excutables for its PowerUP accelerator boards. This format was then adopted as standard by AmigaOS 4.0, MorphOS and AROS. ELF support was added to WarpUp by 3rd party developers.
AmigaOS 4.0 and MorphOS
AmigaOS 4.0 and MorphOS can run ELF natively, but as these systems were designed to run on PowerPC processor-based machines, the developers added also compatibility for WarpUP software, used in AmigaOS 3.9. In addition MorphOS implements PowerUp software compatibility as implemented by Phase5 for PowerUP accelerator cards.
Both new operating systems could also run Amiga Hunk format because they implemented internally the old Amiga API environment based on AmigaOS 3.1, and can run 68000 code through emulators equipped with internal JITM (Just In Time Machine) which maps all instruction sets of the 680X0 family, much enhancing the emulation speed. The JIT machine of AmigaOS is called Petunia. The one running on MorphOS is called Trance.
- See also pages regarding at Amiga.History site.
- on Haage&Partners site.
External links
- Unofficial PowerUP Support Homepage
|
| |
|
|
