DMK support please?

[rhester72]

I appreciate the addition of disk support, but nearly every emulator has moved to DMK format, to such a degree it's very difficult to even find software (or working converters!) in JV1 format any longer.

Even the very basic (Microsoft) Colossal Cave adventure needs DMK because of on-disk copy protection...any hope of this format being supported?

[theflynn49]

Colossal Cave adventure has been "fixed" https://misterfpga.org/viewtopic.php?t=7599
trstools is the reference for TRS80 disk format conversion http://www.trs-80emulators.com/trstools/
JV3 maybe converted to JV1 (if less than 96 tracks) with https://github.com/theflynn49/JV3toJV1
Disks are not the main medium for the trs80 collection, instead you find lots of BAS and CMD files you have to carry around yourself (and the core has tools for that)

On the other hand, supporting DMK would be a lot of work, for not much reward ... so I would not be surprised if that takes forever to be implemented.

[rhester72]

I was the person who advocated for and assisted with the fix you're referencing. ;) It would benefit any original/copy-protected software (that used something other than manual protection), hence the request. It is, in fact, so important that all software emulators have adopted it and very little original software is even available in JV1.

If it's too much work, so be it, but I'd hardly regard it as "not much reward".

[theflynn49]

Could you feed me back with an example of such DMK complete app disk working on a Model I ? (I couldn't find one when I reviewed the disk driver. The only thing I wanted was booting LDOS and successfully compiling unarc/ccc, .... you see my point ... )

[rhester72]

If I'm understanding you correctly, Microsoft Adventure is one, which is the reason for the work to 'crack' it to work on JV1. The original has deliberately mislabeled and misordered sectors to confuse DOS and thus the original could only be preserved as DMK.

[theflynn49]

Ok, to make my position clear, and clarify what could convince me to implement such driver : if you find let's say 10 other games (or more) in the DMK format that have such protection (and have not been cleaned up), I'd say it's worth developing the DMK driver (if it's not too cumbersome in vhdl). And I wrote 'games' because MiSTer is basically a retro game platform, nobody wants to use SuperCalc on it (and if you do, you have xtrs :) )

If there is just a couple remaining, unless one is a formidable historical keep to be preserved at all costs kind of thing, well, I'll pass to someone else. I tried to find some, and I couldn't find any, but I am not really good in searching these things.

[rhester72]

I hear you - unfortunately I'm not familiar enough with the platform (I never had one back in the day!) to even identify them without at least a large a time investment as it would take to implement the format. laughs If I ever have more time on my hands than I know what to do with, and aren't embroiled in at least a dozen projects in parallel as I usually am, I promise I will make such a search and report my findings. =)

[theflynn49]

I perfectly got your point. Same for me, I tend to be careful with spending my available free development hours :D ... Let's see what's the feedback of the community on these points (it's pretty slow nowadays unfortunately), and we'll see, they may come back with a convincing list !

[dshadoff]

I was trying to remember what the specific challenge was with DMK, and then I found this:
"Files with a .DSK or .DMK extension could be JV1, JV3, or DMK format."

-> This means that knowing all of those formats wouldn't be enough; you would need to be detect which format was actually being referenced by this file. Simply implementing the DMK format wouldn't be sufficient, as some DMK images may actually be other formats according to this quote. While this is possible - and maybe even relatively simple - on an emulator written in a high-level language, it would be hugely more complicated in HDL.

Found here:
https://www.trs-80.com/wordpress/tips/formats/#dsk

But there's a nice little description of the DMK format itself in the section immediately below that, in case you were interested.

[rhester72]

Agreed, but wouldn't it make more sense to do the detection in MiSTer Main first and then hand off a signal to the core as to the actual type?

[theflynn49]

In my collection I find :
$ ls -lR | grep -i ".cmd$" | wc -l => 5467
$ ls -lR | grep -i ".bas$" | wc -l => 7237
$ ls -lR | grep -i ".dsk$" | wc -l => 1075
$ ls -lR | grep -i ".cas$" | wc -l => 727
$ ls -lR | grep -i ".dmk$" | wc -l => 356

And each time I look at a DMK (or DMK in a DSK for that matter) it's either :

• a disk not suitable for model I
• a disk with files like .bas files I can copy on a JV1 disk without issues
• a program I find somewhere else as a .cmd or a .cas
• a DSK(JV3) which I can convert (actually quite a lot are like this)
• a desktop office app of some sort

And I concur with @dshadoff, making this in vhdl is not gonna be fun, so it needs to be proven useful. Although we have all the SDram to do this.
And spending space in MisterMain for it ? hmmm, Sorgelig will have to be convinced ...
my 2 cents

[theflynn49]

I used these docs for handling the formats =>
doc for JV1 & JV3 from Tim Mann : https://tim-mann.org/trs80/dskspec.html
doc for DMK : http://cpmarchives.classiccmp.org//trs80/mirrors/www.discover-net.net/~dmkeil/trs80/trstech.htm#Technical-DMK-disks