The file format also records FM and MFM marks as looking the same. It doesn't tell you anything about where the data marks are. Instead it tells you where the address marks are in a separate table. This file format doesn't attempt to preserve that. On a real disk, address and data marks are specially-crafted so as to be unambiguous, by dropping a clock bit. When dealing with sectors marked as single-density, just discard every other byte from the original file. Obviously repeating every byte twice for single-density disks is a complete fiction, likely invented so that the one-size-for-all-tracks model worked. This is where DMK starts to go off the rails a little: Standard IBM System 34 disk encoding as used by most computers is an ID Address Mark, then an address ending with a CRC, then a gap, then a data (or deleted data) mark, then sector data and another CRC, then another gap to the next IDAM. How does it tell where the sectors begin? Through the presence of an IDAM. Having stepped to the track it wants, to read a given sector the controller then has to sit and wait until that particular sector goes past. This relates to how floppy disks work - they're always spinning and a floppy controller just receives an incoming stream of data bits. So the first 128 bytes of each track image aren't actually on the original floppy disk, they're just part of this file format.Īs you note, an IDAM is an ID Address Mark. The first 128 bytes of each track image are a list of IDAM pointers and single/double density flags. Then side 0, track 1 side 1, track 1 side 0, track 2, etc, etc. immediately after the 16-byte header, on a double-sided disk, you'll see the track image for side 0, track 0. 1-sided or 2-sided) with track lengths of n at file offset: (t*q + s)*n + 16 So you can find track t on side s of a q-sided disk (i.e. Each track image is the length you got from the header, and they're interleaved by side.

The first 16 bytes are the header, which you seem to be familiar with - write protection, geometry, track size, etc.įrom there on are a bunch of track images. But starting with the perfectly sensible stuff: It has a bunch of design deficiencies, and was clearly tightly coupled to the program that originally implemented it. I support DMK in my MSX emulator, and bear in mind that it's a bit of a confused file format. But it can't be very analog because the DMK files are still all the same size. I found a tool for viewing DMK files that helped me realize a few more of my DMKs have this little directory track declaration, but their offsets occur at locations varying by a number of bytes from the start of the disk image. Because the actual sector data starts at offset 0x0108 of the DMK file, which leaves 120 bytes between the IDAM table and the sector data, which must be internal/low-level 'raw' data. The IDAMĪnd sector data each have CRCs, this is just like on a real disk. Have bits 6 or 7 set of byte 4 of the disk header then each singleĭensity data byte is written twice, this includes IDAMs and CRCs (theĬRCs are calculated as if only 1 byte was written however). The actual track data follows the header and can be viewed with a hexĮditor showing the raw data on the track. The two high bits of an offset are flags. Then there is the first 128-byte track header section containing a list of 16-bit 'offsets' to each 'IDAM' in the track. The format starts with a 16-byte header that describes the disk geometry.

The DMK format seems to be a bit vague to me probably due to assuming a relatively deep level of knowledge about how the disk format and drive controller work at a low level. So far I'm only digging into the TRS-80 Model I/III side of things. It's capable of representing copy-protected disks and all 'WD-1771 and WD-19xx controller functions and formats'. DMK is a low-level disk image file format used by TRS-80 Model I & Model III, Tandy Color Computer, Dragon 32 & 64, and MSX emulators.

Double sided disk map