Note: This page was retrieved from the Wayback Machine and is preserved here for posterity ( http

://web.archive.org/web/20010528021434/www.magnet.ch/emutech/Tech/ )
Dear emulation author! Please keep 2IMG files clean. We would like to make this a stable, consistent image format that gets rid of all the problems older and established formats are known for. If you have suggestions for enhancements or questions, please contact me or post on comp.emulators.apple2. The 2IMG format was jointly developed by the authors of XGS, KEGS, Catakig and Bernie. 2IMG
+ 0 + 4 + 8 +10 +12 +16 +20 +24 +28 +32 +36 +40 +44 +48 char char word16 word16 word32 word32 word32 word32 word32 word32 word32 word32 word32 word32 magic[4]; // creator[4]; // header_len; // version; // image_format;// flags; // num_blocks; // data_offset; // data_len; // cmnt_offset; // cmnt_len; // creator_offset; creator_len; // spare[4]; // "2IMG" Creator signature Length of header in bytes Image version Image data format (see below) Format flags (see below) Number of 512-byte blocks in this image File offset to start of data Length of data in bytes File offset to start of comment Length of comment in bytes // File offset to start of creator data Length of creator data in bytes Spare words (pads header to 64 bytes)

Here's a short description:
+ 0 char magic[4];

Contains the string "2IMG"
+ 4 char creator[4];

A signature of the software that created this image. Important to properly handle the creator-specific chunk. Currently used signatures are: WOOF for Bernie ][ The Rescue CTKG for Catakig
+ 8 word16 header_len;

The length of this header which equals 64 bytes as of this writing.
+10 word16 version;

The version number of this header. We're at version 1 at this moment.
+12 word32 image_format;

Describes what kind of disk image is stored in the DATA chunk. Possible values are: 0 for DOS 3.3 -order floppy images. This is the same kind of data as in .do images. The disk data is already decoded, stored as logical disk blocks, sorted by logical block number. 1 for ProDOS-order disk images. This format is for hard disk images and "generic SmartPort devices". Each block has 512 bytes. Blocks are sorted by their logical block number. 2 for raw dumps of the disk nibbles. This is only valid for floppy disk images.
+16 flags word32 flags;

has the following layout:

31 27 23 19 15 11 7 3 0 Lxxx xxxx xxxx xxxx xxxx xxxV vvvv vvvv |\_________________________/| \_______/ | | | | Disk Lock Reserved Vol #? DOS 3.3 volume #

x: reserved (0) L: if true (1), disk image is locked V: if true (1), the least significant 8 bits provide the volume number. This is only meaningful for DOS 3.3 images. If V is zero, then the volume number is not specified and 254 is assumed. (Again, only in case of a DOS 3.3 image.) v: volume number (byte).

+20

word32

num_blocks;

Number of 512-byte blocks in image. Makes only sense when format flag is set to 1 (ProDOS image.)
+24 +28 word32 word32 data_offset; data_len;

Indicates where the actual disk bytes begin. The offset is calculated from the very beginning of the file, i.e. it includes the size of this header. The following 4 bytes set the

size in bytes of the data chunk. Note: the DATA chunk must preceed the COMMENT and CREATOR chunks.
+32 +36 word32 word32 cmnt_offset; cmnt_len;

Points at a text chunk for a user-defined "disk label". The text should be ASCII encoded. Since the cmnt_len field determines the length of the comment chunk, there's no C-style terminator or Pascal-style length byte/word in the text chunk required. Note: the COMMENT chunk must come after the DATA chunk and before the CREATOR chunk. If it's not present, set both the offset and length words to zero.
+40 +44 word32 word32 creator_offset; creator_len;

You may add your own chunk where you can store data specific to your emulator. Please keep in mind that this chunk is linked to the creator code at the beginning of the header. If you really need to change the creator, you should take appropriate steps to remove the CREATOR chunk or convert it to your own format. Just don't change the creator signature and keep the old creator chunk. Note: the CREATOR chunk must be the last one of the three chunks. If it's not present, set both the offset and length words to zero.
+48 word32 spare[4];

Reserved for future use.

ProDOS-Order (.PO)

.PO disks contain logical disk bytes, i.e. blocks of 256 bytes each sorted by their logical block number. Since they are only used for dumping floppies, .PO images always have 560 blocks originating from 35 tracks of 16 sectors each. You can use the following translation table to find out about a sector's physical block number:
block: 0 1 2 3 4 5 6 7 8 9 A B C D E F position: 0 8 1 9 2 A 3 B 4 C 5 D 6 E 7 F

This table mirrors ProDOS' hard-coded interleaving. It is different from the one found on DOS 3.3 disks.

DOS-Order (.DO)

.DO disks contain logical disk bytes, i.e. blocks of 256 bytes each sorted by their logical block number. Since they are only used for dumping floppies, .DO images always have 560 blocks originating from 35 tracks of 16 sectors each. You can use the following translation table to find out about a sector's physical block number:
block: 0 1 2 3 4 5 6 7 8 9 A B C D E F position: 0 7 E 6 D 5 C 4 B 3 A 2 9 1 8 F

This table mirrors DOS 3.3' hard-coded interleaving. It is different from the one found on ProDOS disks.

NIB

.NIB images are copies of a disk's nibblized disk bytes. Since they are pure copies without having gone through any sort of decoding, they work equally well for both DOS and ProDOS disks. .NIB images are made up of 35 tracks. Each track has $1A00 (6656) bytes. There's no header structure. The first disk byte of track 0 starts at file offset +0, the first byte of track 1 at file offset +$1A00, and so on.