Here's a little report on my recent experience playing with the DMK file format and tools (I'm currently working on a tool to write-back DMK files to real floppies using a SuperCard Pro device).
So I first tried the official openMSX READ-DMK.COM tool, and it was not working on any of my MSX machines here: the drive was spinning but its LED stayed off. I checked the code and discovered that the phil_select routine was selecting drive #2 instead of drive #0. That can be fixed by replacing 0xC2 by 0xC0 here:
; 1) select
phil_select ld a,(0xF348)
ld h,0x40
call 0x0024 ; select FDC slot in page 1
ld a,(side)
ld (phil_control1),a
;ld a,0xc2 ; motor on, led on, drive A
ld a,0xc0 ; motor on, led on, drive A
ld (phil_control2),a
ret
My guess is that on some machines, bit 1 is ignored, so when you use 0xC2 it activates drive #0. On some other machines, that bit is used, and drive #0 is not activated.
I also did some changes in READ-DMK.COM to write the .DAT files to the current drive and specify the slot of the disk drive to use, allowing use of mass storage devices.
So I finally had a working READ-DMK.COM tool. Before that I tried to insert a 2nd drive on a Philips 8250 I had in the attic, breaking some screws when removing the drive plate holder (dismantling a 8250 is a real super-mess!), just to finally discover that my 8250 was not working anymore (black screen... was pissed off and did not investigate further).
I then tried to make DMK images of both SD Snatcher (disk A) and Ys II (Program disk), which I know were copy-protected.
For SD Snatcher, READ-DMK stopped with a "Read track returned too much data" error. Maybe that could be fixed by increasing a buffer size? DMK Creator 5.1 created a DMK file without reporting any error, but when launching that image in openMSX, I got a "This disk is not original error".
For Ys II, READ-DMK worked, and the image was totally working in openMSX. With the image created with DMK Creator 5.1, game was stuck on a black screen. I did some checks with my beta DMK-write program, and it seems that DMK Creator does not handle the sector size field or CRC correctly:
READ-DMK.COM report (track 7 has a sector size of 0 for sector #5 and in consequence bad CRCs for both id and data):
Track 7:
Sector #1: track 3 side 1 number 1 size 2 idcrc 6683 (6683) datacrc b15a (b15a)
Sector #2: track 3 side 1 number 2 size 2 idcrc 33d0 (33d0) datacrc bc42 (bc42)
Sector #3: track 3 side 1 number 3 size 2 idcrc 00e1 (00e1) datacrc 0564 (0564)
Sector #4: track 3 side 1 number 4 size 2 idcrc 9976 (9976) datacrc 787d (787d)
Sector #5: track 3 side 1 number 5 size 0 idcrc 8098 (8a05) datacrc 01c0 (5c11) *IIC *IDC
Sector #6: track 3 side 1 number 6 size 2 idcrc ff14 (ff14) datacrc c1dd (c1dd)
Sector #7: track 3 side 1 number 7 size 2 idcrc cc25 (cc25) datacrc 57d9 (57d9)
Sector #8: track 3 side 1 number 8 size 2 idcrc dc1b (dc1b) datacrc 1fb0 (1fb0)
Sector #9: track 3 side 1 number 9 size 2 idcrc ef2a (ef2a) datacrc 796c (796c)DMK Creator 5.1 report (everything seems normal here, even if track 7 is protected):
Track 7: Sector #1: track 3 side 1 number 1 size 2 idcrc 6683 (6683) datacrc b15a (b15a) Sector #2: track 3 side 1 number 2 size 2 idcrc 33d0 (33d0) datacrc bc42 (bc42) Sector #3: track 3 side 1 number 3 size 2 idcrc 00e1 (00e1) datacrc 0564 (0564) Sector #4: track 3 side 1 number 4 size 2 idcrc 9976 (9976) datacrc 787d (787d) Sector #5: track 3 side 1 number 5 size 2 idcrc aa47 (aa47) datacrc 90ee (90ee) Sector #6: track 3 side 1 number 6 size 2 idcrc ff14 (ff14) datacrc c1dd (c1dd) Sector #7: track 3 side 1 number 7 size 2 idcrc cc25 (cc25) datacrc 57d9 (57d9) Sector #8: track 3 side 1 number 8 size 2 idcrc dc1b (dc1b) datacrc 1fb0 (1fb0) Sector #9: track 3 side 1 number 9 size 2 idcrc ef2a (ef2a) datacrc 796c (796c)
I also noticed that READ-DMK.COM sometimes failed when trying to identify the number of sectors on a track (displaying 9, 18, 27... and some weird number after that). That's more likely to happen on my HB-F1XDJ here, and might be related to too small delays after moving the heads (just a supposition here).
A final note on the DMK format: from what I've seen, it does not allow to store all "markers" for a track, it's just keeping an index on the sector's first IDAM marker. The 2nd DAM marker is not stored, and has to be guessed from the DMK file bytes when re-creating a real disk. Maybe that could compromise the backup integrity of some disks with sophisticated protection mechanisms involving weird marker patterns.

).