Amiga HUNK file format: header

Introduction

An executable starts with HUNK_HEADER ($000003F3). It tells the loader how much memory to reserve for each hunk and of which kind, before any hunk is read. All numbers are 32-bit big-endian longs. Object files and libraries have no header block; they start with HUNK_UNIT or HUNK_LIB (see objects and libraries).

Fields

What	Size	Meaning
Block id	4	`$000003F3`.
Resident library names	variable	Zero or more names, each a count of longs followed by that many longs of text; a count of 0 ends the list. A load file has none, so the list is a single zero long; the amiga-dev wiki says a load file with names is refused with `ERROR_BAD_HUNK`.
Table size	4	The highest hunk number plus one.
First hunk	4	The number of the first hunk to load (normally 0).
Last hunk	4	The number of the last hunk to load. There are last − first + 1 hunks in this header’s sizes.
Hunk sizes	one long each	For every hunk to load: its size in longs in the low 30 bits, and where it may be placed in the top two bits (below). A hunk’s allocated size can be larger than the bytes its block holds, for example a hunk with trailing space that is not stored.

Memory flags

The top two bits of each size long (bit 31 and bit 30) say what kind of memory the hunk wants. All hunk memory is public.

Bit 31	Bit 30	Meaning
0	0	Any memory, fast preferred.
1	0	Fast memory; the load fails if there is none.
0	1	Chip memory (the memory the custom chips can reach); the load fails if there is none.
1	1	The exact memory flags are in a long that follows this size long, in the size table. Bit 30 is cleared before the size is used.

The extended form is written by the vasm assembler’s output_hunk.c in exactly this way: the size long with both bits set, then a long of MEMF_ flags. In an object file the same two bits sit in the top of the hunk’s own id (HUNK_CODE and the others), and the extra long follows the id, before the size.

More than one header

An overlay executable has its root hunks, a HUNK_OVERLAY table (see hunks), and then the hunks of the overlay segments. In the real overlay file on the Workbench disks (AExplorer) a second HUNK_HEADER follows the overlay table, so the viewer reads one more header and its hunks after an overlay table.

What the viewer checks

The last hunk is not before the first, and the range fits the table size.
The size table is as long as the range says, and the file does not end inside it.
Each hunk block holds no more longs than the header reserves for it.
The number of hunks in the file equals the number the header lists.

It shows the memory a file needs as the sum of the sizes, split into chip, fast and any. In the 2,547 real files read in memory for the tests, 104 hunks ask for chip memory and none asks for fast memory only or uses the extended form.

Not described

Known, not yet covered

Reference: the individual MEMF_ bits of the extended flags long, and what each AmigaOS version does with a hunk it cannot place. The header fields come from the amiga-dev wiki and the amitools reader as the fetch tool summarised them, and from the vasm source.
Viewer: the extended flags are shown as a number, not decoded.

Amiga HUNK File Format – Header