What floppy disk format and layout and what disk image format are used for the Coleco Adam?

Question

I just found out that emulators for the Coleco Adam use a disk image file format with the DSK file extension.

This is a very very overused extension on many different disk formats. Though a few DSK formats are used by multiple platforms. Also several raw track & sector formats use the DSK file extension.

Do we know if the Coleco DSK image file format is one of those used by computers/emulators?

Or if we it's a raw format, is there anything special we should know about the order of the sectors such as interleave/skew?

According to Wikipedia there was only one type of floppy: 5​1⁄4-inch, double density (MFM), single-sided, 40 tracks x 8 sectors of 512 bytes, holding 160 KB.

Also, what disk layout did those floppies used? Is there a boot sector, directory track, file allocation table, etc? On which tracks and sectors are those located and what is the format of a directory entry?

Answer 1

A partly speculative answer, working backwards from the source code of Marat Fayzulin's ColEm, it appears to be a fixed-size sector dump. On line 52 of EMULib/FDIDisk.c you can see confirmation of the geometry you already know about:

• single sided;
• 40 tracks;
• 8 sectors per track;
• 512-byte sectors.

Line 406 lists FMT_ADMDSK (i.e. Adam disk) amongst those that "must have exact size" and that exact size is calculated by multiplying those fields together.

I also grabbed the TOSEC collection for the ColecoVision Adam from archive.org and looked at its DSK collection; it has only 21 of them. Of those, all but two are exactly 163,840 bytes in size (i.e. 408512); the two that are not are both marked '[a]' which is apparently impenetrable ROM-hoarder code for 'alternate', i.e. both are accompanied by images of the same disk that are 163,840 bytes in size. So bad images that have been preserved through a surplus of caution is not necessarily a bad guess, though it is a guess.

Peeking inside these images for further confirmation, there was no commonality in terms of a potential file header and all had what looked like catalogue/directory contents starting at exactly 0x400, further making it unlikely that there's anything present beyond a sector contents dump.

Checking out Marcel de Kogel's AdamEm I noticed at line 1983 of Coleco.c there is:

static const byte interleavetable[8]= { 0,5,2,7,4,1,6,3 };

And, elsewhere, what look like high-level emulation of disk functionality:

diskread(addr+i,(len-i<512)? len-i:512,
                                (block&(~7))|interleavetable[block&7],
                                 DiskStream[nr])

With the interesting bit being (block&(~7))|interleavetable[block&7] — given that there are eight sectors per track, I would guess that they're stored in a disk image in physical order and that these equate to Coleco blocks 0, 5, 2, 7, 4, 1, 6, 3.

I could find no corresponding table in ColEm though, so probably this is a software construct. So I would imagine that you'll need to do that mapping if writing a piece of software that thinks in terms of ColecoVision block numbers, but probably they're just labelled 0-7 on disk and the disk image is definitely just track 0 then track 1 then track 2...