DMS compression methods

[Exodous]

Originally Posted by nocash

Your 32767 byte banner seems to be only 32766 bytes tall.

The file was definitely 32767 bytes as it broke DMS when I made it 32768 bytes, so it's always possible my code had a bug and missed off the last byte, one for me to check....

Originally Posted by nocash

And why did you use 3C0h bytes for fake bootblocks???
Normally bootblocks are charactersistically having these two features: They contain a checksum on the 400h byte block. And they are stored on two physical 200h byte floppy sectors.

... and another oddity, maybe it was due to how the display of bootblocks worked that this was chosen?


As the source code to my tool was last edited on 7th August 1994, my memory on it all is a little rusty. Thankfully, it's full of comments, so I'll try and refresh myself why and get back to you later in the week

[Toni Wilen]

Originally Posted by paraj

This one also seems to be missing at least one byte on track $4F: https://files.scene.org/view/mirrors...ticalMassB.dms

Gettting this fixed would be really great. This DMS file seems to be the only existing version of this demo, with broken animation part.

[temisu]

Originally Posted by nocash

Good to know!
Mmmh, temisu, I think you might misremember what you were doing with which files. Looking at you source code, you may have perhaps wanted to say something like:

But anyways, what I have discovered is that the case doesn't seem to be as rare as you think.

The other three files (Eradication, Flt-cup, Grandnt2) seem to have the same missing byte problem, but the garbage padding at the end of the bitstream is fooling your decompressor into thinking that missingNo=0, and that's wrong, it should be missingNo=1.

You can detect that situtation by looking for checksum errors. Admittedly it isn't optimal to use the checksum to detect and correct the errors. I am still struggling to confirm if the error corrected results are reliable.

I think you might be correct here, and I did not understand the problem correctly. I need to investigate these new findings. If you find more broken files let me know.

And big thank you for this discussion. It really helps everyone when someone is paying attention

[temisu]

Originally Posted by Toni Wilen

Gettting this fixed would be really great. This DMS file seems to be the only existing version of this demo, with broken animation part.

The second disk has broken DMS bitstream affecting the last 5 bytes of the file. Putting stuff there does not make it run any better - I strongly suspect the trouble is in the first disk, and it was there before it was compressed since the music and the anim is corrupted before it loads anything much from disk 2.

[temisu]

I rewrote the decompressor - now it can decompress everything except this Parallax disk2 and theunt, which both are badly broken:

https://github.com/temisu/ancient/bl...compressor.cpp

Maybe it is too early to say I'm done with this but now it works a bit better again

[Exodous]

Originally Posted by Exodous

The file was definitely 32767 bytes as it broke DMS when I made it 32768 bytes, so it's always possible my code had a bug and missed off the last byte, one for me to check....

Sorry, my mistake, the header file was actually 32766 bytes. It stopped working in DMS when I made it 32767 bytes or greater as the CRC was reported as being invalid.


I thought this may because the CRC routine in my code was only capable of handling signed 16 bit data lengths, but I've just modified it to handle full unsigned 32-bit data lengths and DMS still doesn't like anything greater than 32766 bytes.

Originally Posted by nocash

And why did you use 3C0h bytes for fake bootblocks???

Having looked at the code, the comments say the fake bootblock should be 960 bytes long and that's what it checks for.


I've modified the check to allow for a larger bootblock and it works just fine, so I presume it was just an arbitrary size I decided upon when I wrote the tool.

[nocash]

Originally Posted by paraj

This one also seems to be missing at least one byte on track $4F: https://files.scene.org/view/mirrors...ticalMassB.dms

Thanks!

Disk A - https://files.scene.org/view/mirrors...ticalMassA.dms
That disk does look seriously damaged (unrelated to DMS bugs). Most tracks seem to contain raw data (without OFS filesystem headers, supposedly loaded directly from the bootblock?). But there is also corrupted OFS filesystem in the middle of the disk (a root directory with name "Cocktail ?!", two damaged root entries, and several files that have intact file header, and intact data first 200h bytes, but then followed by corrupted data).
As temisu said, Disk A seems to be the main problem, and the demo won't work even when repairing Disk B.

Disk B - https://files.scene.org/view/mirrors...ticalMassB.dms
That's interesting and nasty. For manually fixing it: It's easy to guess that the last 8 bytes should be 8000000000000000. But there is no way to fix that automatically.

Looking at the decompressed data: It seems to contain a bitmap bitplane with values like ..FFFFFFFFFFFFFx000000..000000xFFFFFFFFFF.. but the last 8 bytes are wrong or missing (two garbage bytes, and 6 missing bytes). When repeating the pattern of the preceeding bitmap bytes, those last 8 bytes should be probably x000000000000000 (namely, 8000000000000000 will produce correct checksum).

In the RLE layer, those 8 bytes should be RLE-encoded as 80 90 07 00. But the RLE data does instead contain two garbage bytes, and two missing bytes.

And the LZ layer, it does contain two trailing garbage literal codes, which should be removed, and should be probably replaced by a single length/distance code that would represent 80 89 07 00. Anyways, no way to fix that automatically.

DMS Testing
I've finally got my floppy disk emulation working, and I can now emulate & test the DMS software : )
Albeit, it's a bit tiresome to boot up different DMS versions and to key in the command line strings each time : /

Anyways, I've tested the repaired Eradication ADF file, and I can in fact reproduce the DMS error when re-compressing it via Heavy2, tested with DMS v1.11 thru DMS v2.04. and they are all bugged (even though the .guide file in v2.04 does (incorrectly) claim to have "found and solved" the DMS bug) (for 2.04, I've only tested the DMSWB gui version, the DMS commandline version wants me to run the DMS installer, and to install a newer OS for running the DMS installer).

Eradication can be compressed without bugs when using Heavy1 (or when using DMS versions older than v1.10, which don't support Heavy1/Heavy2 at all). That doesn't necessarily mean that Heavy1 is more stable - but one can apparently switch to using a different compression method in case of problems.

Warp (DMS predecessor, from same author, ie. SDS Software)
A bit-offtopic, I've also looked into the older warp format. It's more simple, and has some similarities to DMS, and surprisingly some extra low-level features for sector "Labels" and raw MFM encoding.

Warp files (.WRP) (SDS Software)
The file contains several pairs of TOP and BOT chunks:
  000h 0Ah ID ("Warp v1.1",00h) ;v1.1, although the sofrware version is 1.11
  00Ah 2   Track (usually 00h..4Fh) (max FFFFh..0052h in UnWarp?)
  00Ch 4   Side ("TOP",00h=Side0, "BOT",00h=Side1, FFh,xxh,xxh,xxh=Banner/Text)
  010h 2   Type (1=Normal, 2=MFM)
  ...  (8) Unused(?) extra 8 bytes (present only if Type=2=MFM)
  012h 2   Compression Method (0..3) (usually 1 or 3)
  014h 2   CRC16 with initial value 0000h on decompressed data
  016h 4   Compressed Size (SIZ)
  01Ah SIZ Compressed Data
Compression Methods:
  0=Replace (uncompressed)  (ARC method 02h) (eg. random mixed with value 90h)
  1=Crunch  (RLE90+LZW)     (ARC method 08h) (used for most tracks)
  2=Squeeze (RLE90+Huffman) (ARC method 04h) (eg. random 7bit values)
  3=Pack    (RLE90)         (ARC method 03h) (eg. random 8bit values)
Decompressed Data (when Type=1) (written via SendIO with cmd=ETD_FORMAT):
  0000h 0Bh*200h  Sector Data   (for sector body)
  1600h 0Bh*10h   Sector Labels (for sector header, usually zerofilled)
Decompressed Data (when Type=2) (written via SendIO with cmd=ETD_RAWWRITE):
  0000h 3xxxh     Raw MFM data  (sync marks, sector header, data, gaps)
Decompressed Data (when Side=FFh) (shown as text)
  0000h ...       Banner/Text (max 8000h bytes or so)
The WRP file may contain fewer than 2*80 tracks (it may omit unused tracks, and
large disks may be split into several wrp files).
Type=2 and Banner/Text are implemented in UNWARP decompressor, but unknown if
(or how) the WARP compressor does actually support creating such files.
Type=2 does include 8 extra bytes in the header (but those bytes seem to be
unused).
WARP is automatically using the best method for each track. RLE90/LZW/Huffman
are exactly same as in ARC (but unknown if LZW has same gaps after clear codes;
the small 16B0h-byte WRP tracks never(?) contain any clear codes at all).

About the LZW clear codes: I've tried hard (but failed) to create a test file. Theoretically the clear code should (perhaps) occur in files with more than 1000h LZW codes.
1000h codes should occupy about 1520h bytes in LZW format, and with the right amount of random and non-random data, it should be possible to have more than 1000h codes that are smaller than 16B0h uncompressed bytes (and smaller than Huffman or plain RLE).

Originally Posted by Exodous

Sorry, my mistake, the header file was actually 32766 bytes. It stopped working in DMS when I made it 32767 bytes or greater as the CRC was reported as being invalid.

Good to know.

Originally Posted by Exodous

Having looked at the code, the comments say the fake bootblock should be 960 bytes long and that's what it checks for.

The DMS v2.xx ParCon hacks seem to display 400h bytes, with 40h bytes per line. That is, up to including the last 40h bytes at offset 3C0h. Maybe you've somehow misread it to not include those last line, or maybe there was a DMS version that actually didn't display the last line.
And, the official DMS v1.xx versions from SDS Software seems to display only 200h bytes (which is fitting better on 640pix screens).

Originally Posted by temisu

I rewrote the decompressor - now it can decompress everything except this Parallax disk2 and theunt, which both are badly broken

Cool. I haven't implemented that auto-fixing myself yet. I guess it should work in most cases, or hopefully. It's probably best to throw a warning message on broken files instead of silently fixing them.
For example, CriticalMassB has 2 wrong bytes and 6 missing bytes (which is clearly unfixable).
But there might be also cases where you get 2 wrong bytes and 1 missing byte (then all 3 bytes would be still wrong when adding the missing byte).

Originally Posted by temisu

If you find more broken files let me know.

Sure, I'll post them here if I find any. You also don't have more broken files than those posted here, or do you?
The only other file that I am aware of is that "Superfrog disk 3" but I've no idea if that disk/version could be found online.

[temisu]

Originally Posted by nocash

Disk B - https://files.scene.org/view/mirrors...ticalMassB.dms
That's interesting and nasty. For manually fixing it: It's easy to guess that the last 8 bytes should be 8000000000000000. But there is no way to fix that automatically.

Looking at the decompressed data: It seems to contain a bitmap bitplane with values like ..FFFFFFFFFFFFFx000000..000000xFFFFFFFFFF.. but the last 8 bytes are wrong or missing (two garbage bytes, and 6 missing bytes). When repeating the pattern of the preceeding bitmap bytes, those last 8 bytes should be probably x000000000000000 (namely, 8000000000000000 will produce correct checksum).

In the RLE layer, those 8 bytes should be RLE-encoded as 80 90 07 00. But the RLE data does instead contain two garbage bytes, and two missing bytes.

And the LZ layer, it does contain two trailing garbage literal codes, which should be removed, and should be probably replaced by a single length/distance code that would represent 80 89 07 00. Anyways, no way to fix that automatically.

Yeah, all of the same thoughts I had, I actually checked earlier what the bitmap at the end of the disk is and it is 256pix wide 2bpp vectorcube. Most likely never used by the demo itself. Like seen on the disk A, the demo was not written on empty disks but some disks that already had some data already in them. Thats why you can find funny stuff on them between the track loaded data. Manually fixing the DMS-errors will not make the demo run any better

Makes me kind of sad though. I had completely forgotten this demo, although it is no gem it is still pretty nice. And all this because of broken disks

First and last time I saw it properly was in ASM'92 big screen.

Originally Posted by nocash

Anyways, I've tested the repaired Eradication ADF file, and I can in fact reproduce the DMS error when re-compressing it via Heavy2, tested with DMS v1.11 thru DMS v2.04. and they are all bugged (even though the .guide file in v2.04 does (incorrectly) claim to have "found and solved" the DMS bug) (for 2.04, I've only tested the DMSWB gui version, the DMS commandline version wants me to run the DMS installer, and to install a newer OS for running the DMS installer).

This is very cool. I tought the bugs were random.

Originally Posted by nocash

Warp (DMS predecessor, from same author, ie. SDS Software)

I've been thinking about supporting Warp as well, but there is the complication of raw MFM-data (how to represent that, it is not going to cleanly go into adf) and the fact that I don't see much Warp files lying around.

I did earlier code for IPF->ADF with a side-API for raw-track data (not public yet). It has exactly the same problem of "I can make this work but how the data is going to be usable?"-thingy

Originally Posted by nocash

Cool. I haven't implemented that auto-fixing myself yet. I guess it should work in most cases, or hopefully. It's probably best to throw a warning message on broken files instead of silently fixing them.

My code is BSD-licensed, take it, go wild Just remember to attach the license-file and you are good no matter if you are doing open source or commercial stuff...

Originally Posted by nocash

Sure, I'll post them here if I find any. You also don't have more broken files than those posted here, or do you?
The only other file that I am aware of is that "Superfrog disk 3" but I've no idea if that disk/version could be found online.

So far thats the files I have. I thought I had more but no. I'll let you know if I stumble into more of them.

[dlfrsilver]

Originally Posted by temisu

Yeah, all of the same thoughts I had, I actually checked earlier what the bitmap at the end of the disk is and it is 256pix wide 2bpp vectorcube. Most likely never used by the demo itself. Like seen on the disk A, the demo was not written on empty disks but some disks that already had some data already in them. Thats why you can find funny stuff on them between the track loaded data. Manually fixing the DMS-errors will not make the demo run any better

Makes me kind of sad though. I had completely forgotten this demo, although it is no gem it is still pretty nice. And all this because of broken disks

First and last time I saw it properly was in ASM'92 big screen.



This is very cool. I tought the bugs were random.



I've been thinking about supporting Warp as well, but there is the complication of raw MFM-data (how to represent that, it is not going to cleanly go into adf) and the fact that I don't see much Warp files lying around.

I did earlier code for IPF->ADF with a side-API for raw-track data (not public yet). It has exactly the same problem of "I can make this work but how the data is going to be usable?"-thingy



My code is BSD-licensed, take it, go wild Just remember to attach the license-file and you are good no matter if you are doing open source or commercial stuff...




So far thats the files I have. I thought I had more but no. I'll let you know if I stumble into more of them.

Let me help a bit : the WRP files that contains partly cracked games or games with MFM tracks, can be written inside extended ADF files in emulation.

[nocash]

Yes, there are extended .ADF files with MFM data. The format isn't officially documented anywhere, but it should look like so:

Extended ADF (v1)
   000h 8     ID "UAE--ADF" (ADF_EXT1)
   00Ch N*4   Track List (always A0h entries for 2*80 tracks)
   ...  ..    Track Data
  Track List entries:
   000h 2     Type (0=NormalAmigaDosTrack, 1=RawMFM)
   002h 2     Available space for track in bytes (must be even) (3380h)

Extended ADF (v2)
   000h 8     ID "UAE-1ADF" (ADF_EXT2)
   008h 2     Reserved (0)
   00Ah 2     Number of tracks (N) (default 2*80=160)
   00Ch N*0Ch Track List
   ...  ..    Track Data
  Track List entries:
   000h 2     Reserved (0)
   002h 1     Disk revolutions-1 (when Type=1)
   003h 1     Type (0=Normal AmigaDos Track, 1=Raw MFM)
   004h 4     Available space for track in bytes (must be even) (3380h)
   008h 4     Track length in bits (often len*8=19C00h) (0=empty/unformatted)
  Track Data, Type 0
   000h ..    Data (usually 1600h bytes for 11*200h)
   ...  ..    Zeropadding (to Track size, which is usually 3380h)
  Track Data, Type 1, one revolution
   000h ..    MFM data
  Track Data, Type 1, more revolutions
   ...  ..
  Track Data, Type 1, unformatted
   000h ..    Zerofilled

https://fossies.org/linux/uae/src/disk.c
https://raw.githubusercontent.com/BlitterStudio/amiberry/master/src/disk.cpp

But do MFM warp files really exist? It doesn't look so:
WARP v1.11 doesn't mention any commandline switches for selecting MFM format.
WARP v1.11 contains command 800Bh (ETD_FORMAT), but I can't see command 8011h (ETD_RAWWRITE) in the disassembly (unlike UNWARP, which supports both 800Bh and 8011h).
WARP v1.11 is bundled with a generic Read.Me and UnWarp.doc, but unfortunately no Warp.doc (so there's no info on if or how one can use (or buy?) MFM support).

Or wait... looking at the ascii strings in the WARP executable, there seem to be undocumented commandline switches: MFM, DOS, IBM, APPEND, NOCOMP, NOZERO. Which should be supposedly appended at end of the commandline as so:

warp read 0 79 filename mfm

Yes. that's working! Or in practice, my emulation does hang (because the MFM reader is checking the port BFDD00h.bit4 index hole flag, and I haven't emulated that yet).

There is also a "Could not open Text file" string in the WARP executable, but I don't know how to specifiy a text file in the commandline.
And, it seems that can enter text via keyboard after compression, but I don't know to terminate the text input and return to the command prompt.

In theory, there should have been a Warp.doc file that describes all those things, but it's missing in the warp downloads, or was there some printed warp manual on paper?

EDIT: Found manuals here: http://janeway.exotica.org.uk/release.php?id=87807 that package seems to contain various hacked warp versions. The good thing is that those hacks include manuals, describing the "MFM" switch, and optional trailing "+TEXTFILE". The latter should also make it easy to test large LZW blocks with LZW clear codes.

[mark_k]

Interesting... I have started to look at the Warp executable in ReSource.

I noticed one broken instruction, maybe due to a typo in the source code? There is one occurrence of

BCLR #CIAB_DSKSIDE,($1BFD100).L

That needs to be patched to ($BFD100).L to work on 68020+.

[dlfrsilver]

Originally Posted by nocash

Yes, there are extended .ADF files with MFM data. The format isn't officially documented anywhere, but it should look like so:

Extended ADF (v1)
   000h 8     ID "UAE--ADF" (ADF_EXT1)
   00Ch N*4   Track List (always A0h entries for 2*80 tracks)
   ...  ..    Track Data
  Track List entries:
   000h 2     Type (0=NormalAmigaDosTrack, 1=RawMFM)
   002h 2     Available space for track in bytes (must be even) (3380h)

Extended ADF (v2)
   000h 8     ID "UAE-1ADF" (ADF_EXT2)
   008h 2     Reserved (0)
   00Ah 2     Number of tracks (N) (default 2*80=160)
   00Ch N*0Ch Track List
   ...  ..    Track Data
  Track List entries:
   000h 2     Reserved (0)
   002h 1     Disk revolutions-1 (when Type=1)
   003h 1     Type (0=Normal AmigaDos Track, 1=Raw MFM)
   004h 4     Available space for track in bytes (must be even) (3380h)
   008h 4     Track length in bits (often len*8=19C00h) (0=empty/unformatted)
  Track Data, Type 0
   000h ..    Data (usually 1600h bytes for 11*200h)
   ...  ..    Zeropadding (to Track size, which is usually 3380h)
  Track Data, Type 1, one revolution
   000h ..    MFM data
  Track Data, Type 1, more revolutions
   ...  ..
  Track Data, Type 1, unformatted
   000h ..    Zerofilled

https://fossies.org/linux/uae/src/disk.c
https://raw.githubusercontent.com/BlitterStudio/amiberry/master/src/disk.cpp

But do MFM warp files really exist? It doesn't look so:
WARP v1.11 doesn't mention any commandline switches for selecting MFM format.
WARP v1.11 contains command 800Bh (ETD_FORMAT), but I can't see command 8011h (ETD_RAWWRITE) in the disassembly (unlike UNWARP, which supports both 800Bh and 8011h).
WARP v1.11 is bundled with a generic Read.Me and UnWarp.doc, but unfortunately no Warp.doc (so there's no info on if or how one can use (or buy?) MFM support).

Or wait... looking at the ascii strings in the WARP executable, there seem to be undocumented commandline switches: MFM, DOS, IBM, APPEND, NOCOMP, NOZERO. Which should be supposedly appended at end of the commandline as so:

warp read 0 79 filename mfm

Yes. that's working! Or in practice, my emulation does hang (because the MFM reader is checking the port BFDD00h.bit4 index hole flag, and I haven't emulated that yet).

There is also a "Could not open Text file" string in the WARP executable, but I don't know how to specifiy a text file in the commandline.
And, it seems that can enter text via keyboard after compression, but I don't know to terminate the text input and return to the command prompt.

In theory, there should have been a Warp.doc file that describes all those things, but it's missing in the warp downloads, or was there some printed warp manual on paper?

EDIT: Found manuals here: http://janeway.exotica.org.uk/release.php?id=87807 that package seems to contain various hacked warp versions. The good thing is that those hacks include manuals, describing the "MFM" switch, and optional trailing "+TEXTFILE". The latter should also make it easy to test large LZW blocks with LZW clear codes.

I met such WRP files containing MFM tracks and cracked Longtrack. Winuae ask you then to use an extended ADF because the ADF format cannot hold the MFM.

[Toni Wilen]

Originally Posted by nocash

As temisu said, Disk A seems to be the main problem, and the demo won't work even when repairing Disk B.

This demo can run fully (except broken disk 1 animation) when using 1M Chip RAM config. But unfortunately demo code is also broken, music player and trackloader both use CIA-B timers and both check timer status by polling CIAICR (don't do that, use timer on/off bits!), usually clearing other's interrupt bit causing a hang or a crash. It is multi-broken demo

I have seen this demo working until end part on both real A500 and UAE but it is rare that it works fully.. Usually it dies.

[jbl007]

I put a working Disk 2 in the zone. At least it can un-dms correctly. Doesn't change much unfortunately, demo always ends with a black screen.

[temisu]

Originally Posted by Toni Wilen

It is multi-broken demo

Yes, this is accurate. Can we fix the DMS-compression errors? nocash did it as well I did it. so we definitely can. (manually that is)

Does it make the demo run any better? Not one bit, which is unfortunate. It would need patching by someone who has time. At least the code/data does not look like it is compressed (in disk) which will probably make stuff easier if someone wants to take a shot. You can just patch the adf directly.

This Disk B on this demo is also very interesting in that it is not consistent on other breakage we've seen so far on DMS files. The data is corrupted but packed data checksum is valid. Other cases we have documented here are those the last byte is missing/corrupted in a some sort of off-by-one error.

It is really special in a special way

Originally Posted by dlfrsilver

I met such WRP files containing MFM tracks and cracked Longtrack. Winuae ask you then to use an extended ADF because the ADF format cannot hold the MFM.

I got interested about this topic and trying to look the winuae (that is on github) I noticed that there is no special processing for mfm-tracks in wrp files. Maybe the detection is done later via size? In any case I would love to have that kind of file to test.

The extended ADF seems to be something that I need to try how it works, it seems to be a perfect format for certain raw data. Or should it be called uadf? uae-adf? In any case searching extended adf in eab does not yield the most constructive discussions...

[nocash]

I've disassembled another disk compressor...

Lhwarp .LHW (1989-1990, Jonathan Forbes)

File Header (10h or 14h bytes, depending on version)
  000h 1   Version High  (01h)       ;\
  001h 1   Version Mid   (00h..09h)  ; three digit version (1.39 = newest)
  002h 1   Version Low   (00h..09h)  ;/
  003h 1   Unused        (00h)
  004h 2   First Track   (00h..4Fh, usually 00h)
  006h 2   Last Track    (00h..4Fh, usually 4Fh)
  008h 4   Text compressed size (or 0=None)
  00Ch 4   Text uncompressed size (always 0 for bugged v1.20+text)
  010h (4) Total Filesize                             (exists in v1.30 and up)
  ...  ..  LZHUF-Compressed Text (if any)
  ... (16) Copy of hdr[0..0Bh], plus nonzero Text size (for bugged v1.20+text)
  ...  ..  Track Headers & Compressed data for First..Last Track

Track Headers (0Ch, 10h, or 14h bytes, depending on version)
  000h 1   Compression Method (00h,01h,07h,0Ah)          (used in v1.10 and up)
  001h 1   Track Present Flag (00h=Normal, 02h=TrackNotPresent) (used in v1.1x)
  002h 1   Track Number       (00h..4Fh) (First..Last Track)
  003h 1   Unused             (00h)
  ...  (4) Sector Present Flags (0..3FFFFFh) (little-endian!) (in v1.10 and up)
  ...  4   Decompressed Size  (210h*num_sectors) (0..2D60h)
  ...  4   Compressed Size
  ...  (4) Checksum (sum of all decompressed bytes)  (exists in v1.02, v1.03)
  ...  (4) CRC32 (with initial=0, result=uninverted) (exists in v1.10 and up)
  ...  ..  Compressed Track (if any sectors are present)

Decompressed Track format
 Version v1.0x:
  0000h 2C00h Sector data   (22 x 200h bytes)
  2C00h 160h  Sector labels (22 x 10h bytes)
 Version v1.10 and up:
  0000h 200h  1st Sector data
  0200h 10h   1st Sector label (usually zerofilled)
  0210h 200h  2nd Sector data
  0410h 10h   2nd Sector label (usually zerofilled)
  ...   ..    etc.

Methods
  00h = Freeze/Unfreeze   v1.00 (LZHUF)         (aka LHA -lh1- method)
  01h = Store/Unstore     v1.40 (none)          (aka uncompressed, or empty)
  07h = Vaporise/Soldify  v1.20 (ClearGapLZW)   (aka Unix nCompress.Z Mode=8Eh)
  0Ah = Squeeze/Unsqueeze v1.20 (Huffman+RLE90) (aka CP/M Squeeze.xQx)
Most .LHW files are using LZHUF (the newer LZW/Huffman methods are rarely used;
they were perhaps added to offer faster compression, albeit with worse
compression ratio).

Versions
  1.00        Did exist (but doesn't seem to be supported any longer)
  1.01        0Ch-byte track header (oldest supported version)
  1.02 - 1.03 10h-byte track header (with checksum entry)
  1.10 - 1.11 14h-byte track header (with CRC, TrackPresent, SectorPresent)
  1.20 - 1.21 As above, no longer using TrackPresent flag, Squeeze/Vaporise
  1.30 - 1.31 As above, with added total size entry in File header
  1.40        Newest software version (stores 1.39 in file header, not 1.40)

Bugs/Issues
Most releases contain bugfixes. For files created with version v1.1x or v1.2x,
it is common to have 1-5 corrupted tracks with bad CRC warnings (nonetheless,
the sector data appears to be correct, the error might be in the sector labels
(?) or in the CRC field).
Lhwarp is slow (although v1.40 claims to use assembler functions with
mysterious speed increases).

[Crashdisk]

@nocash
if you need a particular type of DMS, I have a very nice collection, including ADF files corresponding to buggy DMS files

[temisu]

I’d very interested in the buggy files as well

[Crashdisk]

Originally Posted by temisu

I’d very interested in the buggy files as well

No problem, I give to anyone interested in the subject. This file is in The Zone! for you :

BuggedDMS.zip

[temisu]

Very interesting failure cases. I also love that you included the adfs for comparison.

Thanks!