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 char magic[4]; // "2IMG"
+ 4 char creator[4]; // Creator signature
+ 8 word16 header_len; // Length of header in bytes
+10 word16 version; // Image version
+12 word32 image_format;// Image data format (see below)
+16 word32 flags; // Format flags (see below)
+20 word32 num_blocks; // Number of 512-byte blocks in this image
+24 word32 data_offset; // File offset to start of data
+28 word32 data_len; // Length of data in bytes
+32 word32 cmnt_offset; // File offset to start of comment
+36 word32 cmnt_len; // Length of comment in bytes
+40 word32 creator_offset; // File offset to start of creator data
+44 word32 creator_len; // Length of creator data in bytes
+48 word32 spare[4]; // 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 word32 flags;

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 word32 data_offset;

+28 word32 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 word32 cmnt_offset;

+36 word32 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 word32 creator_offset;
+44 word32 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.