Support for TRS-80 DMK image files

[keirf]

Discussed in https://github.com/keirf/greaseweazle/discussions/393

^{Originally posted by **malmacleod** January 4, 2024} Hello Keir, I am a relatively new user of the Greaseweazle, but have been very impressed with it so far. I've also been using ImageDisk and Catweasel for many years. My main use at the moment for the Greaseweazle is to archive and recreate 5.25" FM/MFM disks for the TRS-80 Models 1, 3 & 4. I've been doing this successfully with DSK and IMD files, but it would be great if support for DMK could also be added. DSK in particular is not well suited for the TRS-80, because of the non-standard DAMs used in the directory track (I'm aware that you dealt with this issue last year for the TRS-80 Model 1) and of course this metadata is not stored in DSK files (which in the TRS80 world are sometimes called JV1 files). DMK was used by some early PC-based TRS-80 emulators such as TRS32 (and DMK is still supported by current emulators such as TRS80gp), and there are many online repositories for TRS-80 disks that are only in DMK format (often these are named as DSK files, but on examination of the first 4 bytes they can be verified as being DMK files). Would it be possible to add support for DMK please? If so, that would lessen the dependence that I currently have to use Catweasel for this task. FYI the DMK spec is available here -> http://cpmarchives.classiccmp.org//trs80/mirrors/www.discover-net.net/~dmkeil/trs80/trstech.htm#Technical-DMK-disks Secondary question: Are there any other file formats (ie not DSK or IMD) already supported by Greaseweazle that are well suited for FM/MFM-formatted disks? By that I mean containers that have good metadata storage for DAMs, interleave, etc. An example of a DMK file for the TRS-80 is LS-DOS 6.3.1H on this page -> https://www.tim-mann.org/misosys.html If you need any further info or examples, I'm happy to help! Mal

[qbarnes]

BTW, for those who still have Catweasels and use cw2dmk, as the cw2dmk maintainer (https://github.com/qbarnes/cw2dmk), I've been making considerable progress refactoring and rewriting cw2dmk into gw2dmk for the Greaseweazle. I've got gw2dmk hobbling along using GW hardware to read floppy disks and it's writing out DMKs. There's still a lot to go though. I might be ready for some people to start being gw2dmk alpha testers in a month or two. If anyone who has formerly or currently uses cw2dmk and wants to volunteer, toss me an email.

As I've been deep-diving on the DMK format, I've been learning there's various subtleties and extensions, that as far as I can tell, have remained publicly undocumented. I have run across a copy of the informal standard on GitHub: https://github.com/lutris/openmsx/blob/master/doc/DMK-Format-Details.txt. I plan on getting these subtleties and extensions publicly documented. If the maintainer of this repo doesn't accept PRs, I'll start another repo for just documenting the DMK tweaks and mods that has happened over the years, mostly to support uncommon disk and encoding formats. Those extensions though shouldn't stop anyone from adding general DMK support to gw. I too am very much looking forward to having DMK support added to gw!

[keirf]

I put a first cut on branch dmk but it's quite unsatisfactory for some old 8-inch FM images I've been sent. It's hard to know whether the format eg. has a different CRC algorithm for data, or I am misunderstanding some aspects of the DMK image format. Some other FM and MFM images I can decode fine.

Actually they were created with cw2dmk using some fancy -q option, so I guess I can share them and you can tell me what I'm doing wrong. A different scanning/streaming algorithm on the unencoded data, like you have, may make most sense rather than my search'n'replace hack on the post-encoded data array. I won't attach them here but I will email the zip file across to you. Then we have some images in common that we could iterate on.

[qbarnes]

I believe on the CZSDOS and CZMDOS disks, you're getting CRC errors because your sector size is too short by 4 bytes. You need to "lie" to your algorithms to add another 4 bytes. I did this to my own DMK utility (dmkdump) to +4 their sector size as a quick hack and then I got valid CRC reads from your example DMKs.

In cw2dmk source, this is handled here: https://github.com/qbarnes/cw2dmk/blob/master/secsize.c#L57-L59 And is documented here: https://github.com/qbarnes/cw2dmk/blob/master/cw2dmk.man#L512-L518

[drencorxeen]

DMK is also used on the TRS Color Computer emulators as well as a modified version of DMK for the CoCoSDC. :)