(bad?) DMK/PDI dump of Gize!/XIX - need advice...

Expert (117)

14-07-2019, 21:26

I bought this copy of Gize! / XIX (a Fairytale game "undumped" on MSX2) from YAJ from a seller that claims he started it up and it worked.

Well, he either lied, or it was damaged in shipment, since the disks only boot to a blue screen. Regardless, I tried to dump DMKs and PDIs of the disks, with 100% success according to the tools, but of course they have the same behavior in openMSX.

A peep of a hexdump of disk 1 shows an intact file index and all the good stuff, but it seems regardless some data got corrupted here and there or the physical copy protection is just borked somehow.

Does anyone have any experience dealing with stuff like this? Is recovery possible? Or would it take so long it's not even worth it? :-?

My only recourse at the moment is to step through in openMSX and maybe try to bypass whatever is hanging it - but who knows if I'll be successful :(

By Manuel

Ascended (19801)

14-07-2019, 22:44

Check with analyze-dmk whether there are multiple bad sectors. A copy protection is only one special sector, usually. If you find multiple, it may mean the disk was damaged.

Hmm, I just checked myself, I don't see any bad sectors. Forget my remark... I don't see anything special regarding the disk structure on DMK level.

By shram86

Expert (117)

14-07-2019, 22:47

Manuel wrote:

Check with analyze-dmk whether there are multiple bad sectors. A copy protection is only one special sector, usually. If you find multiple, it may mean the disk was damaged.

Hmm, I just checked myself, I don't see any bad sectors. Forget my remark... I don't see anything special regarding the disk structure on DMK level.

Thanks for checking. I wonder what's wrong...

By max_iwamoto

Paladin (691)

15-07-2019, 04:43

Could you dump the disks with program called DCOPY into DSK file? Or is there any way to convert DMK file into DSK?
I can try to debug it and give you an answer if there a legitimate code and / or protection.

By shram86

Expert (117)

15-07-2019, 05:01

max_iwamoto wrote:

I don't know where to find DCOPY, but if it's just a raw sector dump, I used "dd" on linux to create this file. It fails on the last sector (same with Disk-Manager) due to the protection.

By Manuel

Ascended (19801)

15-07-2019, 17:14

If possible you might want to dump it with read-dmk.com as well.

By shram86

Expert (117)

15-07-2019, 18:12

Manuel wrote:

If possible you might want to dump it with read-dmk.com as well.

I'll give that a shot this afternoon. What would be the difference between read-dmk and DMK Creator images?

Edit: I can't use read-dmk, I only have one disk drive.

By Jipe

Paragon (1631)

15-07-2019, 17:51

try with CTRL key then boot

the tail of saving files is 716k , normal dsk are 720k

By shram86

Expert (117)

15-07-2019, 18:18

Jipe wrote:

try with CTRL key then boot

the tail of saving files is 716k , normal dsk are 720k

I'm not sure what you mean by these two statements.
1. I already tried several days ago to boot with CTRL just in case, but to my knowledge all this does is prevent a second floppy driver from loading into RAM if it exists. I only have one floppy.
2. It sounds like you're just reiterating what I said in a different way - one sector is missing from the dsk dump, the last sector, which is the one with the copy protection.

By Manuel

Ascended (19801)

16-07-2019, 00:15

Boothing with CTRL frees up RAM, even if you only have 1 drive in the MSX.

The DMK you gave didn't show any strange sector at the end. Wait, I overlooked something:

-- physical track 79, head 1
 0: AOfst= 175 C= 79 H=  1 R=  1 N=  2 ACrc=472d,ok  DOfst= 219 T=n DCrc=c40b,ok 
 1: AOfst= 833 C= 79 H=  1 R=  2 N=  2 ACrc=127e,ok  DOfst= 877 T=n DCrc=c40b,ok 
 2: AOfst=1491 C= 79 H=  1 R=  3 N=  2 ACrc=214f,ok  DOfst=1534 T=n DCrc=c40b,ok 
 3: AOfst=2148 C= 79 H=  1 R=  4 N=  2 ACrc=b8d8,ok  DOfst=2192 T=n DCrc=c40b,ok 
 4: AOfst=2806 C= 79 H=  1 R=  5 N=  2 ACrc=8be9,ok  DOfst=2850 T=n DCrc=c40b,ok 
 5: AOfst=3464 C= 79 H=  1 R=  6 N=  2 ACrc=deba,ok  DOfst=3507 T=n DCrc=c40b,ok 
 6: AOfst=4121 C= 79 H=  1 R=  7 N=  2 ACrc=ed8b,ok  DOfst=4165 T=n DCrc=c40b,ok 
 7: AOfst=4779 C= 79 H=  1 R=  8 N=  2 ACrc=fdb5,ok  DOfst=4823 T=n DCrc=c40b,ok 
 8: AOfst=5437 C= 79 H=  1 R= 10 N=  2 ACrc=9bd7,ok  DOfst=5480 T=n DCrc=d4a9,ok

As you can see, that last sector has a deviating Record number. But that's all I cn see that is strange. It also has a different CRC, I guess there is some content then (the rest looks all the same, so probably empty).

DMK Creator is a different program and uses different strategies than READ-DMK to read out such floppy disks. But alas, you need 2 drives for the latter to work properly. (Although perhaps it also works with mass storage (maybe ASSIGN needed to get the data where you want it, as it will always go for drive B:.)

By shram86

Expert (117)

16-07-2019, 02:34

Manuel wrote:

Boothing with CTRL frees up RAM, even if you only have 1 drive in the MSX.

The DMK you gave didn't show any strange sector at the end. Wait, I overlooked something:

-- physical track 79, head 1
 0: AOfst= 175 C= 79 H=  1 R=  1 N=  2 ACrc=472d,ok  DOfst= 219 T=n DCrc=c40b,ok 
 1: AOfst= 833 C= 79 H=  1 R=  2 N=  2 ACrc=127e,ok  DOfst= 877 T=n DCrc=c40b,ok 
 2: AOfst=1491 C= 79 H=  1 R=  3 N=  2 ACrc=214f,ok  DOfst=1534 T=n DCrc=c40b,ok 
 3: AOfst=2148 C= 79 H=  1 R=  4 N=  2 ACrc=b8d8,ok  DOfst=2192 T=n DCrc=c40b,ok 
 4: AOfst=2806 C= 79 H=  1 R=  5 N=  2 ACrc=8be9,ok  DOfst=2850 T=n DCrc=c40b,ok 
 5: AOfst=3464 C= 79 H=  1 R=  6 N=  2 ACrc=deba,ok  DOfst=3507 T=n DCrc=c40b,ok 
 6: AOfst=4121 C= 79 H=  1 R=  7 N=  2 ACrc=ed8b,ok  DOfst=4165 T=n DCrc=c40b,ok 
 7: AOfst=4779 C= 79 H=  1 R=  8 N=  2 ACrc=fdb5,ok  DOfst=4823 T=n DCrc=c40b,ok 
 8: AOfst=5437 C= 79 H=  1 R= 10 N=  2 ACrc=9bd7,ok  DOfst=5480 T=n DCrc=d4a9,ok

I tried ASSIGN but it didn't work. Looks like it tries to use the hardware letter and not the logical letter.