Apple Partition Map
The Apple Partition Map (APM) is a partition scheme developed by Apple Inc. for dividing physical storage devices, such as hard disk drives, into multiple logical partitions on Macintosh computers.[1] It serves as a data structure that describes the layout, types, and attributes of these partitions, enabling the operating system to manage file systems, boot volumes, and device drivers on the disk.[1] APM was specifically designed for compatibility with Apple's hardware and software ecosystem, including SCSI and ATA interfaces, and supports partitioning schemes for formats like Hierarchical File System (HFS) and its successor, HFS Plus.[2] Introduced in 1987 with the Macintosh II to support the first SCSI hard drives, APM quickly became the standard partitioning method for classic Mac OS systems, replacing earlier rudimentary approaches used on floppy disks and the original Macintosh HD20 drive.[3] It was documented extensively in Apple's Inside Macintosh: Devices and technical notes, evolving to accommodate features like driver chaining and boot support without major structural changes over nearly two decades.[1] By the mid-2000s, APM powered partitioning for PowerPC-based Macs, allowing unlimited partitions per disk while maintaining simplicity for HFS/HFS+ volumes.[3] At its core, APM's structure begins with a 512-byte Driver Descriptor Map (DDM) in block 0, followed by the partition map itself starting in block 1, where the total size is specified by thepmMapBlkCnt field in the first entry.[1] Each partition entry occupies 512 bytes and includes critical fields such as pmSig (signature 'PM' for partition map), pmPyPartStart and pmPartBlkCnt (defining the partition's starting block and size in 512-byte blocks), pmParType (specifying types like 'Apple_HFS' for file system partitions or 'Apple_Driver' for boot drivers), and pmPartStatus (flags for attributes like bootability or writability).[1] A 16-bit or 32-bit checksum ensures data integrity, and the map supports embedding HFS Plus volumes within HFS wrappers for backward compatibility.[2] This design allows the Macintosh ROM or Open Firmware to read the map directly for booting, with partitions typically limited to 2 terabytes in total disk size due to 32-bit block addressing.[3]
APM's key strengths lie in its robustness for multi-partition setups, seamless integration with Mac OS file systems, and support for boot processes via designated startup partitions, but it lacks features like free space allocation or backup tables found in modern schemes.[1] During Apple's 2006 transition to Intel-based processors and EFI firmware, APM was largely superseded by the GUID Partition Table (GPT), which offers greater scalability for disks beyond 2TB and enhanced recovery options, though APM remains supported in Disk Utility for legacy compatibility and bootable install media on older PowerPC systems.[3] Today, it is primarily used for maintaining vintage Macintosh hardware or creating cross-compatible volumes with pre-2006 macOS versions.[4]
Introduction and History
Development and Introduction
The Apple Partition Map (APM) was developed by Apple Computer in 1987 as a proprietary partitioning scheme to enable more flexible disk organization on Macintosh systems. It was introduced alongside the Macintosh II, the first color-capable and expandable Macintosh model, which featured a Motorola 68020 processor and built-in SCSI support for external hard drives. Prior to APM, the original Macintosh models like the 128K relied on the flat Macintosh File System (MFS) for single-volume floppies, while the Macintosh Plus introduced rudimentary support for multiple partitions on hard drives via a simpler pre-APM scheme.[3][5] Designed specifically to support multiple partitions on SCSI and other block devices, APM allowed users to separate system files, applications, and user data into distinct volumes, improving manageability and performance on larger hard drives. This was particularly beneficial for professional workflows, as it facilitated bootable system partitions alongside dedicated spaces for data and software. APM's structure was optimized for Apple's hardware ecosystem, standardizing logical blocks at 512 bytes to ensure compatibility with contemporary drives and the Macintosh ROM's boot process.[3][6] APM debuted with Mac OS System Software 4.1, released on March 2, 1987, coinciding with the Macintosh II launch, and integrated seamlessly with the Hierarchical File System (HFS), which had been introduced in 1985 to replace the flat Macintosh File System (MFS) used on earlier floppies and limited hard drives.[7] While MFS's simple structure influenced early disk handling, APM's design emphasized HFS's hierarchical capabilities, enabling efficient mapping of directories and files across partitions. Apple's engineering team, drawing from SCSI standards and internal filesystem evolution, prioritized robustness and simplicity in APM to support the transition to more powerful 68k-based machines.[8][9][10] APM continued as the standard partitioning scheme through the shift to PowerPC processors in 1994, maintaining backward compatibility with 68k systems while accommodating larger drives and evolving OS features.[3]Evolution and Deprecation
The Apple Partition Map (APM), introduced with the Macintosh II in 1987, underwent limited adaptations during the 1990s to accommodate growing storage needs and the introduction of the HFS Plus file system in 1998 with Mac OS 8.1.[3][2] These updates allowed APM to support larger volumes and improved file allocation efficiency over the original HFS, but the scheme retained its core 32-bit block addressing, capping the maximum addressable disk size at 2 tebibytes (approximately 2.19 × 10¹² bytes).[3] By the early 2000s, APM's inherent limitations—such as the absence of native 64-bit addressing, inability to handle unpartitioned free space, and poor interoperability with non-Mac platforms—became increasingly evident amid rising demands for larger drives and cross-system compatibility.[3] These shortcomings prompted Apple to adopt the GUID Partition Table (GPT), part of the Extensible Firmware Interface (EFI) standard, starting with the transition to Intel-based processors in January 2006.[3] GPT addressed APM's constraints by enabling 64-bit addressing for disks exceeding 8 zettabytes, providing redundant partition tables for recovery, and ensuring better alignment with modern hardware and file systems like APFS.[3][4] Despite the shift to GPT for primary boot drives on Intel and later Apple silicon Macs, APM persisted in niche roles, particularly for optical media such as CDs and DVDs formatted in hybrid configurations combining HFS or ISO 9660 structures.[3][11] macOS versions through the 2010s maintained read/write support for APM volumes via backward compatibility in Disk Utility, allowing booting from hybrid APM/GPT setups during the PowerPC-to-Intel transition period.[3] However, Apple began emphasizing GPT as the preferred scheme for all new installations and external drives, citing enhanced security features like protective MBR compatibility.[4][12] APM's status as a legacy format solidified in the mid-2010s, with Apple documentation from 2016 onward recommending against its use for contemporary workflows due to compatibility risks with EFI firmware and larger storage devices.[4] By macOS Ventura in 2022, while APM remained selectable in Disk Utility for legacy or specialized purposes like virtual machine install media, Apple positioned it firmly as outdated, urging users to migrate to GPT for optimal performance and future-proofing.[4][13]Technical Specifications
Overall Disk Layout
The Apple Partition Map (APM) divides a disk into logical blocks of 512 bytes each, providing a structure for defining multiple partitions on block devices such as hard disks and optical media used with Macintosh systems. Block 0 is reserved exclusively for the Driver Descriptor Map (DDM), a data structure that specifies the disk's block size and total block count to enable proper device initialization and access.[14] The partition map begins immediately at block 1 and occupies a contiguous series of blocks, with each partition map entry spanning exactly one 512-byte block. The first entry in the map describes the partition map itself as a special partition that encompasses all blocks allocated to the map (from block 1 onward), ensuring self-description of the structure. The total size of the partition map is determined during disk initialization and remains fixed thereafter, accommodating the number of partitions defined; it is not resized dynamically and must include space for all entries, including any unused or "free" slots if anticipated. This layout allows for flexible block allocation across the disk while maintaining a simple, linear organization of partition descriptions.[14][3] APM structures support up to 64 partition map entries in typical implementations, with each entry 512 bytes in size, enabling up to 63 data partitions (or free space entries) in typical 64-entry configurations, as the DDM is separate from the map entries. All numeric fields within APM entries and the DDM use big-endian byte order, aligning with the Motorola 68000-series and PowerPC processor architectures prevalent in APM-era Macintosh computers.[14][15] The scheme employs 32-bit addressing for block numbers, limiting the maximum disk size to 2 TiB. This arises from the capacity formula: maximum size = $2^{32} blocks \times 512 bytes/block. To compute this, first calculate $2^{32} = 4,294,967,296 blocks. Multiplying by the block size yields $4,294,967,296 \times 512 = 2,199,023,255,552 bytes. Since 1 TiB equals $2^{40} bytes or 1,099,511,627,776 bytes, the total is exactly 2 TiB. Although some references note a signed 32-bit interpretation capping at 1 TiB ($2^{31} blocks), the effective specification permits unsigned addressing for the full 2 TiB limit.[16][15]Partition Map Entries
The Apple Partition Map (APM) defines partitions through a series of fixed-size entries, each occupying exactly one 512-byte logical block on the disk. These entries collectively form the partition map, which begins immediately after the Driver Descriptor Map in block 0, starting at block 1 of the disk.[14] The structure ensures that the map is self-describing, with the first entry typically representing the entire disk and specifying the total number of entries in the map.[14] Each partition map entry, known as aPartition record, contains a standardized set of fields that describe the partition's location, size, type, status, and boot-related attributes. The signature field at the beginning verifies the entry's validity, while fields for start block and length use 32-bit integers to address positions and extents in blocks. The partition type and name are stored as null-terminated strings, allowing human-readable identification. Additional fields support booting, including logical data start, status bitfield, and boot code parameters, with the remaining space reserved for optional boot code or padding. The processor type field specifies the target architecture, such as for 68k or PowerPC systems.[14]
The following table outlines the precise layout of a partition map entry, with byte offsets relative to the start of the 512-byte block:
| Byte Offset | Size (bytes) | Type | Field Name | Description |
|---|---|---|---|---|
| 0 | 2 | Integer | pmSig | Partition signature, set to $504D ("PM" in ASCII).[14] |
| 2 | 2 | Integer | pmSigPad | Reserved; must be 0.[14] |
| 4 | 4 | LongInt | pmMapBlkCnt | Number of blocks occupied by the entire partition map (identical in all entries).[14] |
| 8 | 4 | LongInt | pmPyPartStart | Physical block number of the partition's first block.[14] |
| 12 | 4 | LongInt | pmPartBlkCnt | Number of physical blocks in the partition.[14] |
| 16 | 32 | Char | pmPartName | Null-terminated partition name string (up to 32 characters).[14] |
| 48 | 32 | Char | pmParType | Null-terminated partition type string (e.g., identifying HFS or driver partitions).[14] |
| 80 | 4 | LongInt | pmLgDataStart | Logical block number of the first data block in the partition.[14] |
| 84 | 4 | LongInt | pmDataCnt | Number of logical blocks in the data area.[14] |
| 88 | 4 | LongInt | pmPartStatus | 32-bit bitfield indicating partition status, such as valid, bootable, or allocated.[14] |
| 92 | 4 | LongInt | pmLgBootStart | Logical block number of the first boot code block.[14] |
| 96 | 4 | LongInt | pmBootSize | Size of the boot code in bytes.[14] |
| 100 | 4 | LongInt | pmBootAddr | Load address for the boot code in memory.[14] |
| 104 | 4 | LongInt | pmBootAddr2 | Reserved.[14] |
| 108 | 4 | LongInt | pmBootEntry | Entry point address for the boot code.[14] |
| 112 | 4 | LongInt | pmBootEntry2 | Reserved.[14] |
| 116 | 4 | LongInt | pmBootCksum | Checksum for the boot code.[14] |
| 120 | 16 | Char[17] | pmProcessor | Null-terminated string indicating the processor type (e.g., "PPC").[14] |
| 136 | 376 | Pad | pmPad | Reserved for future use or optional boot code.[14] |
50 4D, confirming a valid APM entry. This fixed format allows the boot loader or disk utility software to parse and validate partitions systematically across the block-based disk structure.[14]
Driver Descriptor Map
The Driver Descriptor Map (DDM) resides in the first physical block (block 0) of a disk formatted with the Apple Partition Map, providing essential information for initializing block device access during system startup.[14] Its structure is defined by theBlock0 data type and begins with a 16-bit signature field sbSig set to 0x4552 ("ER" in ASCII), which validates the record's presence.[14] Following this are fields for sbBlkSize, a 16-bit integer specifying the device's logical block size in bytes (typically 512); sbBlkCount, a 32-bit integer indicating the total number of logical blocks on the device; and sbDrvrCount, a 16-bit integer denoting the number of driver descriptor entries in the map.[14] The remaining space in the 512-byte block contains an array of up to 61 driver entries (each 8 bytes: 4-byte ddBlock, 2-byte ddSize, 2-byte ddType), given the fixed block size and field alignments,[14][15] where each consists of ddBlock (a 32-bit integer for the driver's starting physical block number on the disk), ddSize (a 16-bit integer for the driver's length in 512-byte blocks), and ddType (a 16-bit integer for the target operating system, such as 1 for MacOS or 2 for A/UX).[14]
These driver entries point to embedded block device drivers, such as the standard SCSI driver (often labeled "Apple_Driver" and supporting asynchronous and synchronous transfers) or IDE/ATA equivalents, which are loaded sequentially based on their order and compatibility with the host OS type.[14] No explicit version field exists in the DDM structure itself, though practical implementations remained consistent across Macintosh hardware generations without documented revisions like version 1 or 2; any variations stem from the drivers' internal formats rather than the map.[14]
In the boot process, the Macintosh ROM's Startup Manager scans the DDM early during initialization to detect sbDrvrCount and load the specified drivers into memory, enabling subsequent reads of the partition map entries and hardware-specific disk operations before the operating system kernel engages.[14] This mechanism ensures compatibility for booting from diverse storage interfaces without relying on pre-loaded firmware for all device types.[14]
Partition Types and Identifiers
Common Partition Types
The partition type in an Apple Partition Map (APM) is specified as a 32-byte ASCII string in thepmParType field of each partition map entry, padded with null characters if the string is shorter than 32 bytes.[14] This identifier defines the purpose of the partition and influences how the operating system recognizes and handles it, such as determining the appropriate file system driver or mount behavior via the Start Manager.[14]
Apple defines several standard partition types, primarily for use in classic Mac OS environments. These are outlined below in a table for clarity:
| Type | Purpose |
|---|---|
| Apple_partition_map | Contains the partition map itself, typically the first entry on the disk. |
| Apple_Driver | Holds device driver code, essential for booting and hardware interaction. |
| Apple_Driver43 | Contains a SCSI Manager 4.3 device driver for compatibility with BSD variants. |
| Apple_MFS | Uses the original Macintosh File System, limited to the 64K ROM version. |
| Apple_HFS | Implements the Hierarchical File System for standard Mac OS volumes (128K ROM and later). |
| Apple_Unix_SVR2 | Supports the Unix file system, originally for A/UX environments. |
| Apple_PRODOS | Formats partitions for the ProDOS file system used in Apple II compatibility. |
| Apple_Free | Marks unallocated or unused space on the disk. |
| Apple_Scratch | Designates empty space available for general use. |
Apple_UFS identifies partitions formatted with the Unix File System (UFS), providing compatibility for Unix-based applications and tools.[17] Apple_RAID denotes partitions configured as part of an Apple RAID set, enabling software-based redundancy or striping.[19] HFSX volumes, which are case-sensitive variants of HFS Plus (with signature 'HX'), use the partition type Apple_HFSX.[2] These identifiers ensure that Mac OS can appropriately mount and access the partition contents without requiring manual intervention.
Partition Status Flags
The partition status flags form a 32-bit field within each Apple Partition Map entry, used to denote the operational state, allocation, and boot-related attributes of a partition. This field, labeled aspmPartStatus, primarily influences how the system recognizes and interacts with partitions during initialization and booting.[14]
The low-order byte contains the primary status bits:
- Bit 0 (0x00000001): Set if the partition map entry is valid.
- Bit 1 (0x00000002): Set if the partition is allocated.
- Bit 2 (0x00000004): Set if the partition is in use.
- Bit 3 (0x00000008): Set if the partition contains valid boot information.
- Bit 4 (0x00000010): Set if the partition is readable.
- Bit 5 (0x00000020): Set if the partition is writable.
- Bit 6 (0x00000040): Set if the boot code is position-independent.
- Bit 7: Unused.
- Bit 8 (0x00000100): Contains a chain-compatible driver.
- Bit 9 (0x00000200): Contains a real (non-chain) driver.
- Bit 10 (0x00000400): Contains a chain driver.
- Bit 30 (0x40000000): Do not automatically mount (A/UX-specific).
- Bit 31 (0x80000000): This is the boot (startup) partition.