Amiga HUNK File Format – Hunks

Introduction

A hunk is one contiguous piece of the program in memory. The file has a block that gives it its contents (code, data or just a size), optional blocks that belong to it (relocations, symbols, debug information), and HUNK_END. Hunks are numbered in file order, from the first hunk of the header. A block is a long id followed by what that block needs; the ids below are the same in every source that was read, and in the assembler’s source.

Block ids

Only the low 29 bits are the id; the top bits ask for chip or fast memory (below). The number $3F4 is unused in every source. Wikipedia and the amitools reader give the numbers in this table; the amiga-dev wiki prints $3FD as HUNK_ABSRELOC16, which disagrees with them and with the vasm assembler, whose header file has HUNK_RELRELOC32 at 1021 and HUNK_ABSRELOC16 at 1022. The viewer follows Wikipedia, amitools and vasm. An id above $3FE that is not in the table is read as a count of longs and skipped, the way the amiga-dev wiki says dos.library treats such ids.

HUNK_CODE

A count of longs, then that many longs of machine code. The loader copies them to the hunk’s memory. The viewer disassembles every HUNK_CODE hunk with the 68000-family decoder; the processor is an option because the file does not say. A HUNK_PPC_CODE hunk has the same layout and is shown as bytes.

HUNK_DATA

The same layout as code: a count of longs and the data. The viewer lists the runs of four or more printable characters in data hunks.

HUNK_BSS

One long: the number of longs to allocate and clear. No bytes follow and no relocation block applies to it.

HUNK_END

No body. It closes the hunk, after the hunk’s relocation, symbol and debug blocks. A stray HUNK_END with no hunk open exists in a real file: the Workbench 1.1 calculator has one after a BSS hunk; the viewer notes it and goes on.

HUNK_OVERLAY and HUNK_BREAK

An overlay program loads only its root hunks at first. After the root hunks comes HUNK_OVERLAY: a count, then that count plus one longs of table (as the amitools reader reads it), and HUNK_BREAK, which has no body. In the real overlay executables on the Workbench disks and the loose Amiga files the table is followed either by a second header with the overlay segments’ hunks (AExplorer), or by data that only the program’s own overlay manager reads (WHDLoad: about 89 KB after a 26-entry table). The viewer reads the first and shows the second as “Overlay data”, bytes it does not interpret. The table’s entries are shown as a count, not decoded.

Memory type in the id

In an object file the memory type of a hunk is in the top two bits of the hunk’s id (HUNK_CODE, HUNK_DATA or HUNK_BSS); in an executable it is in the header’s size table.

Not described

Known, not yet covered

• Reference: the overlay table’s entries and the overlay manager’s protocol, the PowerPC extended blocks other than HUNK_PPC_CODE and HUNK_RELRELOC26 (the sources name only those two), and the loader’s behaviour for blocks it refuses.
• Viewer: overlay segments are not followed; HUNK_PPC_CODE is shown as bytes.

Links