Dungeon Master for Atari ST disk image produced by dtc.exe

All questions regarding the dumping of media go here.
Post Reply
Gothmog
Posts: 11
Joined: Wed Oct 19, 2011 5:50 pm

Dungeon Master for Atari ST disk image produced by dtc.exe

Post by Gothmog »

I have dumped an original floppy disk of Dungeon Master for Atari ST with kryoflux (using the 2011-09-23 dtc.exe) and have a question about the content of the resulting disk image. I used the following command line:
dtc.exe -fDungeonMaster -i0 -i2 -fDungeonMaster.st -i4

This produces a disk image in the DungeonMaster.st file. Of course, the game cannot run from this disk image because of the copy protection.
The Dungeon Master copy protection relies on two special sectors:
1) On track 0, there is no sector #8: the eighth sector on the track is instead numbered 247 in the sector header. Apart from that the sector is completely normal. dtc does not export this sector's data to the .st file (the placeholder for sector 8 is filled with $00 bytes) which I think is the normal and expected behavior. Having sector 247 data in place of sector 8 would not make any sense as .st files are just not meant to store sectors with arbitrary numbers.
2) Track 0, sector 7 contains fuzzy bits. My question is about the output produced by dtc.exe in the .st file for this particular sector. In this sector there are 489 bytes that each contain 1 fuzzy bit and 7 normal bits (the other bytes -- the first 20 and the last 3-- do not contain any fuzzy bit).
Because of the fuzzy bits:
- the CRC for the sector is always invalid.
- when you read that sector on a real Atari ST, each of the 489 bytes has a value of either $68 or $E8 (a single bit changes from one reading to the other). The copy protection routines in the game check that the bytes have one of these two possible values (and they also check that the fuzzy bits do randomly change each time the sector is read).

Now here is the data that was output by dtc.exe in the .st file for this sector:

Code: Select all

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000C00  07 50 41 43 45 2F 46 42 09 53 65 72 69 42 26 00  .PACE/FB.SeriB&.
00000C10  00 49 E9 01 68 68 68 68 68 68 68 68 68 68 68 07  .Ié.hhhhhhhhhhh.
00000C20  D0 0C 0C 0C 0C 0F A0 1F 43 43 43 43 43 43 43 43  Ð..... .CCCCCCCC
00000C30  43 43 43 43 43 43 43 43 43 43 43 43 43 40 3E 80  CCCCCCCCCCCCC@>€
00000C40  60 60 60 7D 00 FA 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A  ```}.ú..........
00000C50  1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 1A 01 F4 74 74 74  ............ôttt
00000C60  74 74 03 E8 68 68 68 68 68 68 68 68 68 68 68 68  tt.èhhhhhhhhhhhh
00000C70  68 68 68 68 68 68 68 68 68 07 D1 D1 D1 D1 D1 D0  hhhhhhhhh.ÑÑÑÑÑÐ
00000C80  0F A1 A1 A1 A1 A1 A1 A1 A1 A1 A1 A1 A1 A1 A1 A1  .¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
00000C90  A1 A1 A1 A1 A1 A1 A0 1F 47 47 47 47 47 40 38 38  ¡¡¡¡¡¡ .GGGGG@88
00000CA0  38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38  8888888888888888
00000CB0  38 38 38 38 3E 80 60 60 60 60 60 7D 0D 0D 0D 0D  8888>€`````}....
00000CC0  0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D  ................
00000CD0  0D 0D 00 FA 3A 3A 3A 3A 3A 01 C1 C1 C1 C1 C1 C1  ...ú:::::.ÁÁÁÁÁÁ
00000CE0  C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1 C1  ÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁÁ
00000CF0  F4 03 03 03 03 03 03 E8 68 68 68 68 68 68 68 68  ô......èhhhhhhhh
00000D00  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 E8  hhhhhhhhhhhhhhhè
00000D10  E8 E8 E8 E8 E8 E8 07 07 07 07 07 07 07 07 07 07  èèèèèè..........
00000D20  07 07 07 07 07 07 07 07 07 07 07 07 D1 D1 D1 D1  ............ÑÑÑÑ
00000D30  D1 D1 D1 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D0  ÑÑÑÐÐÐÐÐÐÐÐÐÐÐÐÐ
00000D40  D0 D0 D0 D0 D0 D0 D0 D0 D0 D0 D1 D1 D1 D1 D1 D1  ÐÐÐÐÐÐÐÐÐÐÑÑÑÑÑÑ
00000D50  D0 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E 0E  Ð...............
00000D60  0E 0E 0E 0E 0E 0E 0E 0F A3 A3 A3 A3 A3 A3 A0 1C  ........££££££ .
00000D70  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000D80  1C 1C 1C 1C 1C 1F 47 47 47 47 47 47 47 40 38 38  ......GGGGGGG@88
00000D90  38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38  8888888888888888
00000DA0  38 38 38 30 30 30 30 30 30 30 30 38 38 38 38 38  8880000000088888
00000DB0  38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38  8888888888888888
00000DC0  38 38 30 30 30 30 30 30 30 3E 86 86 86 86 86 86  880000000>††††††
00000DD0  86 86 86 86 86 86 86 86 86 86 86 86 86 86 86 80  †††††††††††††††€
00000DE0  60 60 60 60 60 60 60 7D 0D 0D 0D 0D 0D 0D 0D 0D  ```````}........
00000DF0  0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 15 88 C8 40 7A 1F  ...........ˆÈ@z.
I think this data is incorrect because it does not represent what would be read on a real Atari ST.
I would expect one of these two results instead:
- As the CRC is invalid, consider the data as invalid and do not output any of it to the .st file (leave the sector empty with $00 bytes)
- Ignore the invalid CRC but output to the .st file the data as it would be read on a real Atari ST computer. I guess this would be the preferred solution, as it would match what would happen on a real Atari ST if you tried to image the floppy disk while ignoring the invalid CRC.

Notes:
- I have confirmed the same problem with other floppy disks of Chaos Strikes Back for Atari ST which uses the same copy protection sectors.
- When using the KFAnalyze tool by DrCoolZic (available at http://info-coach.fr/atari/hardware/dev ... #kfanalyze ) on the raw files (this tool simulates a WD1772 FDC), the correct expected values are output for sector 7 (with only $68 and $E8 bytes) when it simulates a "read sector" operation. Here is an excerpt of the correct sector data produced by KFAnalyze:

Code: Select all

Detail buffer content for sector 7 with 515 bytes
= DATA ID=7 515 bytes @121543 us length=16506.79 CRC BAD CLK=4.01 TMV=0 BRD=492 DOI=0 BS=0
  *** Fuzzy Sector *** starting at byte position 39
  0000 121543 3968  fb 07 50 41 43 45 2f 46 42 09 53 65 72 69 ca 08  ..PACE/FB.Seri..
  0010 122053 3968  00 00 ef e9 01 68 68 68 68 68 68 68 68 68 68 68  .....hhhhhhhhhhh
  0020 122563 4096  68 68 e8 e8 e8 e8 e8 e8 68 68 68 68 68 68 68 68  hh......hhhhhhhh
  0030 123071 4000  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  0040 123581 3878  68 e8 e8 e8 e8 e8 68 28 68 68 68 68 68 68 68 68  h.....h(hhhhhhhh
  0050 124091 3968  68 68 68 68 68 68 68 68 68 68 68 68 68 68 e8 e8  hhhhhhhhhhhhhh..
  0060 124603 3908  e8 e8 e8 68 e8 68 68 68 68 68 68 68 68 68 68 68  ...h.hhhhhhhhhhh
  0070 125112 4000  68 68 68 68 68 68 68 68 68 68 68 68 e8 e8 e8 e8  hhhhhhhhhhhh....
  0080 125626 3938  e8 e8 68 68 68 68 68 68 68 68 68 68 68 68 68 68  ..hhhhhhhhhhhhhh
  0090 126139 4031  68 68 68 68 68 68 68 68 68 68 e8 e8 e8 e8 e8 e8  hhhhhhhhhh......
  00a0 126652 4162  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  00b0 127166 4063  68 68 68 68 68 68 68 68 e8 e8 e8 e8 e8 e8 68 28  hhhhhhhh......h(
  00c0 127681 4231  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  00d0 128195 4031  68 68 68 68 68 68 e8 28 e8 e8 e8 e8 e8 68 68 68  hhhhhh.(.....hhh
  00e0 128709 4096  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  00f0 129224 3968  68 68 68 68 e8 e8 e8 e8 e8 e8 68 68 68 68 68 68  hhhh......hhhhhh
  0100 129739 4031  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  0110 130255 3968  68 68 e8 e8 e8 e8 e8 e8 e8 28 68 68 68 68 68 68  hh.......(hhhhhh
  0120 130769 4031  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  0130 131286 3968  68 e8 e8 e8 e8 e8 68 68 68 68 68 68 68 68 68 68  h.....hhhhhhhhhh
  0140 131800 4031  68 68 68 68 68 68 68 68 68 68 68 68 68 68 e8 e8  hhhhhhhhhhhhhh..
  0150 132317 4031  e8 e8 e8 e8 e8 68 68 68 68 68 68 68 68 68 68 68  .....hhhhhhhhhhh
  0160 132829 4000  68 68 68 68 68 68 68 68 68 68 68 68 68 e8 e8 e8  hhhhhhhhhhhhh...
  0170 133344 4063  e8 68 e8 68 68 68 68 68 68 68 68 68 68 68 68 68  .h.hhhhhhhhhhhhh
  0180 133856 4000  68 68 68 68 68 68 68 68 68 68 68 e8 e8 e8 e8 e8  hhhhhhhhhhh.....
  0190 134369 3938  e8 e8 68 68 68 68 68 68 68 68 68 68 68 68 68 68  ..hhhhhhhhhhhhhh
  01a0 134881 4063  68 68 68 68 68 68 68 68 68 e8 e8 e8 e8 e8 68 68  hhhhhhhhh.....hh
  01b0 135393 3938  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  01c0 135904 4096  68 68 68 68 68 68 68 e8 e8 e8 e8 e8 68 68 68 68  hhhhhhh.....hhhh
  01d0 136416 4031  68 68 68 68 68 68 68 68 68 68 68 68 68 68 68 68  hhhhhhhhhhhhhhhh
  01e0 136929 4129  68 68 68 68 68 e8 e8 e8 e8 e8 68 68 68 68 68 68  hhhhh.....hhhhhh
  01f0 137441 4000  68 68 68 68 68 68 68 68 68 68 68 68 68 68 ac 46  hhhhhhhhhhhhhh.F
  0200 137954 4000  42 3a f8                                         B:.
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by IFW »

The KryoFlux host software is not system specific - in fact the generic MFM decoder alone probably supports hundreds of slight variants of the same format...
Being a generic decoder, it is completely immune to the side effects of the sliding data window trick used by that protection, plus many other things.
This is by design, as doing those would undermine the sector recovery capabilities of the software.
Since so far everyone who has ever posted on this forum would prefer to have whatever could be salvaged from a bad sector, rather than have nothing, the host software does that.
Gothmog
Posts: 11
Joined: Wed Oct 19, 2011 5:50 pm

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by Gothmog »

Thanks for your reply. However now I don't understand how dtc can produce the disk image without having to simulate the FDC behavior to interpret the flux transitions and output even the normal sectors (without fuzzy bits or any other timing tricks)? Could you elaborate? or maybe that would be far too complex.

What bothers me in the current state is that when I read track 0 with dtc, I do get an error message "Bad sector found" but I don't know which sector caused the error (unless I missed something).
In the case of Dungeon Master, I know from prior knowledge that sector 7 contains fuzzy bits and thus that the CRC must be invalid. So I can deduce that the error message corresponds to this sector.
However should the disk be completely unknown to me, I would not know which of the dumped sectors is bad. As the output for this sector 7 does not represent any useful data (there is nothing to salvage from it), I think at least the error message should indicate which sector is bad so the user knows not to trust too much the sector data that was dumped.
User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by DrCoolZic »

IFW wrote:The KryoFlux host software is not system specific - in fact the generic MFM decoder alone probably supports hundreds of slight variants of the same format...
Being a generic decoder, it is completely immune to the side effects of the sliding data window trick used by that protection, plus many other things.
This is by design, as doing those would undermine the sector recovery capabilities of the software.
Since so far everyone who has ever posted on this forum would prefer to have whatever could be salvaged from a bad sector, rather than have nothing, the host software does that.
Gothmog wrote: 1) On track 0, there is no sector #8: the eighth sector on the track is instead numbered 247 in the sector header. Apart from that the sector is completely normal. dtc does not export this sector's data to the .st file (the placeholder for sector 8 is filled with $00 bytes) which I think is the normal and expected behavior. Having sector 247 data in place of sector 8 would not make any sense as .st files are just not meant to store sectors with arbitrary numbers.
It is unfortunate that DTC only support .st format. Having a sector with value 247 is a protection on Atari only because of limitations of the WD1772 as many other FDC would not care.
It would be nice to write track content with a file format that allow at least to write sector numbers but this would make DTC specific to Atari and as I understand SPS do not want to do that.
I have on the list of things to do an adaptation of the KFAnalyze to write FD content to a more powerful format (may be .stt or .stx) that would allow to save this information.
IFW wrote:The KryoFlux host software is not system specific - in fact the generic MFM decoder alone probably supports hundreds of slight variants of the same format...
Being a generic decoder, it is completely immune to the side effects of the sliding data window trick used by that protection, plus many other things.
This is by design, as doing those would undermine the sector recovery capabilities of the software.
Since so far everyone who has ever posted on this forum would prefer to have whatever could be salvaged from a bad sector, rather than have nothing, the host software does that.
Sorry Istvan but I do not understand the reply? Why is the "sliding data window trick" specific to any platform? It is true that each system uses different FDC to read MFM data but all of them (including WD1772 and KryoFlux decoder) should decode MFM flux as define by the MFM generic coding rules? The results might be slightly different for different FDC due to usage of different input PLL data separator but this does not justify the data returned in the above example?
In the KFAnalyze program that Christophe mention the PLL data window separator is totally independent of the WD1772. In fact the DPLL implement the algorithm described in the patent US4780844 which was largely implemented in FDC designed in the 80s-90s but I do not know if this is actually the one used in the WD1772
User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by DrCoolZic »

Christophe
New version of KFAnalyze that fix the problem of incorrectly read sectors. kfanalyze.exe attached
I have also an experimental program that write the .st file. dm.st file attached
Attachments
KFAnalyze.rar
KFAnalyze + dm.st
(423.11 KiB) Downloaded 250 times
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by IFW »

1, Yes, PLL/FDC behaviour is implementation dependant and ultimately that is why you see or don't see the intended protection content.
2, Other output formats are planned, but there are lots of things to do...
3, A detailed error report is also planned.
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by IFW »

Additionally, I think there might be an "advanced user" option someday where you could define some very specific behaviour, but it would only ever affect edge cases like this, so it's use would be very limited.
User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by DrCoolZic »

IFW wrote:1, Yes, PLL/FDC behaviour is implementation dependant and ultimately that is why you see or don't see the intended protection content.
I have been looking at "8272 family" on PC that also uses MFM encoding and I still do not see any reason why it would give different results?

It is true that this sector of DM uses position of the flux that is marginal to the inspection windows but any well design MFM PLL data separator should give the same result. I give a completer explanation about border bits in my document about protections http://info-coach.fr/atari/documents/my ... n-V0.9.pdf (version 1.0 to come soon)
User avatar
DrCoolZic
Posts: 172
Joined: Tue Jul 26, 2011 10:44 am

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by DrCoolZic »

Gothmog wrote: 2) Track 0, sector 7 contains fuzzy bits. My question is about the output produced by dtc.exe in the .st file for this particular sector. In this sector there are 489 bytes that each contain 1 fuzzy bit and 7 normal bits (the other bytes -- the first 20 and the last 3-- do not contain any fuzzy bit).
How do you know about the first 20 and last 3? I find the first fuzzy byte at position 39.
Gothmog
Posts: 11
Joined: Wed Oct 19, 2011 5:50 pm

Re: Dungeon Master for Atari ST disk image produced by dtc.e

Post by Gothmog »

I have disassembled and analyzed the game routines for copy protection and they do check for fuzzy bits only in 489 bytes, starting at the 21st byte in the sector.
However, it is unlikely that the fuzzy bits in the first few bytes would really be detected as fuzzy because the flux transitions are probably not close enough to the border of the inspection window.

Moreover, there are some values that I believe are not coincidental, although they are not used in any way by the copy protection routines:
The first byte in the sector is $07. It is followed by a string of 7 characters.
Then there is a byte $09 followed by "Seri" and a serial number value that is unique to each copy of the game, making a total of 9 bytes.
Then there is a word $1e9 = 489 followed by the 489 bytes containing fuzzy bits.
Also, there is the "FB" at the beginning and end of the sector. FB like Fuzzy Bits?
Post Reply