Amiga Hunk
Hunk is the executable file format of programs under the classic AmigaOS (up to version 3.9) for Amigas based on processors of the Motorola 68000 family . The name “Hunk” is derived from the way the software is structured internally; namely as several small chunks or pieces (English hunks ). Each of these hunks can contain data and executable program code.
Hunk structure
The hunks in the Amiga's executable programs exist in at least three different forms. There are 32-bit, 16-bit and occasionally 8-bit hunks.
The various hunks are standardized in the AmigaOS and documented in detail in The AmigaDOS Manual . This standardization was monitored by Commodore itself and expanded if necessary.
Over the years, the standardizations were considered guidelines for Amiga-system-compliant programming for developers. The structures were officially coded in the system and could only be changed by a Commodore committee for new versions of the AmigaOS. They were then released to the developers.
The structure of the Amiga hunk format is kept very simple. It basically consists of three parts: a header, an ID (the size of the hunk) and then a segment that contains the program code or the data.
The header must be of a type known to AmigaOS.
Features of an executable Amiga program
The programs can either be started from the graphical operating system shell of the AmigaOS, the desktop ( Workbench ), from the Amiga CLI (AmigaShell) or from a file manager.
Files under the AmigaOS do not need file extensions. Files can be renamed as desired, including the file extension, and do not change their file type. Under AmigaOS, file types are recognized via hunks, headers or a magic cookie . This magic cookie ($ 000003f3) is used, for example, by the AmigaOS to identify executable programs and is part of the header. The name comes from the fairy tale Alice in Wonderland . A similar procedure is also used by Unix-type operating systems and is called the Magic Number there.
Structure of an executable Amiga program
The internal structure of an Amiga program is also kept quite simple. The structure starts with the magic cookie , followed by the number of all hunks present and then a segment that contains all hunks in their order ( starting at 0 ). The first hunk always has the number zero.
Shortly before the hunk segment starts, there is a table that contains the length of each hunk. Each hunk begins with an ID to which a certain hunk type ( HUNK_CODE or HUNK_DATA ) is assigned.
Magic cookie | Number of hunks | Progressive number of hunks | Hunk lengths table | Various hunks (Hunk_Code, Hunk_Data etc.) |
Spot types
Hun types known to the AmigaOS:
Surname | number |
---|---|
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 |
(unused) | 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
The Amiga would be able to store metadata in hunks. In any case, the structure of the hunks could be adapted relatively easily for this. These changes were discarded in favor of the ELF format. Today, however, there is no longer a Commodore committee that could monitor and implement these changes.
Therefore, the Amiga stores some of its metadata in the so-called .info - sidecar files from. The principle of these files is somewhat similar to the old executable programs of the Macintosh and their resource fork .
The .info files are usually created with each creation of files (project files) under AmigaOS. The .info file contains information such as the actual icon of the file, information about the creator of the file, creation time, required display software, basic file type or user comments. In AmigaOS there is no fixed connection to applications like for example in MacOS .
.info files are not directly visible on the workbench . The Workbench displays the file and its .info file as a unit, using the bitmap information from the .info file to display an icon .
If the user double-clicks the icon with the left mouse button to execute, the program that is set as the display program in the .info file is started and the actual file is transferred as an argument. A menu can be opened with the right mouse button in which the file can be renamed or an information window can be opened. The user can change a large part of the meta information in the information window.
Both files, the actual file and the .info file, are always moved together when they are moved or marked with the mouse on the Workbench. You are always treated as a halt. If you want to manipulate the files individually, you have to rely on the CLI or a file manager such as Directory Opus .
If the .info file represents an executable program, it contains information about the stack size of the program (4096 bytes, 8192 bytes etc.). The information is also taken into account when it is started via the CLI of the AmigaOS.
The user can also remove the .info file, but also removes all meta information and the icon.
Icons
The icons are a part of the .info files, and are embedded in principle raw bitmaps and not the standard Amiga - IFF / ILBM format. The user can edit the bitmaps in the .info files with the standard program IconEdit included with AmigaOS . Since AmigaOS 2.0 the program is also able to import and export IFF / ILBM pictures.
Some other Amiga programs , such as the popular Personal Paint from Cloanto , are able to load, save and display the bitmap information from the .info files. The classic Amiga icons (up to AmigaOS 3.1) are so-called two-state icons. They contain two bitmaps, one for the normal state and one for the pressed state. The two bitmaps are exchanged on-the-fly , so to speak , when an icon is selected or unselected.
More modern Amiga user interfaces such as the ReAction GUI (AmigaOS 3.9 to 4.1) or the MUI (classic AmigaOS , AROS and MorphOS ) use further options for using icons.
All modern Amiga-like operating systems ( AmigaOS 4.0 / 4.1 , MorphOS and AROS) are able to use raw bitmaps, IFF / ILBM and PNG data / files as icon data.
Other executable formats known to AmigaOS
Classic AmigaOS
AmigaOS (up to 3.9) recognizes the following additional formats.
Hunk_Overlay
The Hunk_Overlay type is one of the standard hunks created by Commodore. It was designed to solve low memory problems. This hunk implements a method of loading programs that are larger than the actual amount of memory in the operating system.
With this method, a root structure with references to smaller code fragments / modules is kept in the main memory, whereby the actual code fragments are only loaded into the main memory when required, thus practically a type of overlay programming .
This design approach was relatively clever, but in practice it was so cumbersome to use that it was rarely used. Most developers simply ignored this option.
Extended Hunk Format (EHF)
In 1997, the hardware manufacturer Phase5 introduced PowerPC -based accelerator cards. Since the AmigaOS still ran on 680x0 processors, the PowerPC processor was used like a kind of co-processor. As a result, both processors had to alternately access the main memory (task / context switching) and the system was severely slowed down. To get the problem under control, the AmigaOS 3.5 / 3.9 developer Haage & Partner presented another way of exchanging data and code with the PowerPC hardware. The possibility consisted of a new PowerPC-API / Kernel called WarpOS / WarpUP , which behaved in a system-compliant way by expanding the Amiga-Hunk-Format. This new format is called Extended Hunk Format (EHF) and extends the classic Amiga hunks by the type HUNK_PPC_CODE .
ELEVEN
The hardware manufacturer Phase5 , together with its PowerPC hardware, introduced the ELF format known from the Unix world (part of the PowerPC API / Kernel PowerUP ). The format was later adopted by AmigaOS 4.x, MorphOS and AROS. An ELF emulation was later integrated into WarpOS / WarpUP by a third party.
AmigaOS 4.0 and MorphOS
AmigaOS 4.x and MorphOS can run the ELF format natively on the hardware, as both operating systems run natively on PowerPC hardware. Both are also able to run EHF natively. MorphOS is also able to execute the ELF format for the m68k / PowerPC accelerator cards ( PowerUP ) for the classic Amigas.
Both operating systems are also able to run the classic Amiga hunk format in one emulation layer. Almost the complete AmigaOS 3.1 API is emulated. This is implemented by a JITM (Just In Time Machine), which maps all 68000 instructions to PowerPC instructions and thus achieves a very high emulation speed. The JIT machine under AmigaOS 4.x is called Petunia and the JIT machine from MorphOS is called Trance .
credentials
- The AmigaDOS Manual Third Edition (Bantam Books), Commodore Business Machines, July 1991. ISBN 0-553-35403-5
- Amiga ROM Kernel Reference Manual, Includes and Autodocs (3rd edition; dark gray cover) Addison-Wesley, 1991. ISBN 0-201-56773-3
- Commodore Business Machines: 1989 Amiga Developers Conference Notes, Commodore, 1989. CATS part numbers: NOTES89 and NOTES89D
- Commodore Business Machines: V3.1 Amiga Developer Update Disk Set, Commodore, 1994. CATS part number: AMDEV3.1 (now part of The Developer CD )
- Commodore Business Machines: 1988 Amiga Developers Conference Notes Commodore, 1988. CATS part numbers: NOTES88 and NOTES88D
- Stephen Levy: Amiga Programmer's Guide, Compute! Publications, 1986. ISBN 0-87455-028-9
- Eugene P. Mortimore: Amiga Programmer's Handbook, Sybex, 1985. ISBN 0-89588-343-0
Web links
- Amiga goes PowerUP Unofficial PowerUP support website
- History of the PowerPC on the Amiga (English)
- EHF specification
- Haage & Partner
- Amiga International (English)