Hadou no Hyouteki version differences

Página 4/4
1 | 2 | 3 |

Por Manuel

Ascended (15682)

Imagen del Manuel

02-09-2019, 23:51

Great reverse engineering!

Got some questions:
1. how exactly did you create the DMK dumps? Which tool used, exactly?
2. If I understand you correctly, those 2 extra sectors are not relevant at all, correct?
3. Can you elaborate somewhere what exactly is not cloneable in the DMK format? Or explain what you meant with "not clone-able with DMK" exactly?

Por max_iwamoto

Champion (466)

Imagen del max_iwamoto

03-09-2019, 00:32

Manuel wrote:

Great reverse engineering!

Got some questions:
1. how exactly did you create the DMK dumps? Which tool used, exactly?
2. If I understand you correctly, those 2 extra sectors are not relevant at all, correct?
3. Can you elaborate somewhere what exactly is not cloneable in the DMK format? Or explain what you meant with "not clone-able with DMK" exactly?

1: Before starting this project I didn't know much about DMK, PDI, etc... I was learning as I was doing it. And this is why I want to create a topic where this can be discussed since there is many variables to this process and not easy to find tools / explanations.

So, I used DMK 6.3, DSKPRO 11.6 & PDT tool. All found trough forum topics on MRC.

I created DMK using DMK6.3 and also created DMK converted from PDI thinking it may do a better job. But if DMK cannot run, it conversion from PDI also cannot run. But PDI gives you more correct and detailed track/sector/error information. You need to use PDT tool to extract it.

2: So far I didn't find any evidence that those sectors are used, but it is better to have them there in case they are. It required long and dedicated search or somebody needs to complete the game to make sure they are not required.

3: I created few DMK dumps when I was practicing, such as Galaxy Hero, Ambers Will, etc... They are working correct on openMSX and protection check's out. So I consider them clone-able to real disk and 100% perfect for preservation. The games like LEGEND OF MELVEL or CRIMSON are not clone-able since they will not run as DMK on openMSX (there is possibility that they can be written back to real floppy and work correct, but I highly doubt it; but I will check).

Por Manuel

Ascended (15682)

Imagen del Manuel

03-09-2019, 07:40

If you can run it, please also try the READ-DMK.COM tool. It uses slightly different methods to read the track data than DMK Creator, which you used now.

Note that it is not always possible to write a DMK file back to real disk on an MSX, due to details of how the FDC works. That doesn't make it a bad dump though.

Por max_iwamoto

Champion (466)

Imagen del max_iwamoto

03-09-2019, 19:35

Manuel wrote:

If you can run it, please also try the READ-DMK.COM tool. It uses slightly different methods to read the track data than DMK Creator, which you used now.

Note that it is not always possible to write a DMK file back to real disk on an MSX, due to details of how the FDC works. That doesn't make it a bad dump though.

I found READ-DMK.COM on openMSX website Smile Also found info on how to run it. Is it possible to use drives C: and D: instead of A: & B: ? Or A: & B: are a must?

I am using Yamaha YIS503III, I assume type = NATIONAL ?

I have Philips MSX as well, is it better to dump DMK compare to Yamaha?

Por Manuel

Ascended (15682)

Imagen del Manuel

03-09-2019, 20:46

I only ran it myself on a Philips NMS 8255, so two disk drives. Not comfortable, but it works fine.

That type parameter depends on how the FDC registers are mapped into memory. As your MSX has no built-in disk drive, I can't tell Smile

Por max_iwamoto

Champion (466)

Imagen del max_iwamoto

04-09-2019, 00:35

I did it. I went trough long and painful process of creating the file with read-dmk.com... Assembled the DMK file from tracks and got the same result. Game knows it's a copy. I think issue here is not in bad dump, more like how openMSX handles it. The game read same sector twice and if data at +12h offset is the same, it considers it a copy, if different, it's an original. Maybe when DMK handler on openMSX reads same sector with bad CRC twice it can generate random numbers coming from controller so the game will think it's real? Because I think now DMK emulation in openMSX only handle CRC erros and if game checks for CRC error, it will handle it properly otherwise it will fail.

Por wouter_

Champion (417)

Imagen del wouter_

04-09-2019, 20:16

@max_iwamoto: So the game reads sector C=78,H=1,S=9 multiple times and expects different results, right? I know 2 methods for how a disk can be made to behave this way:

1) Have multiple sectors in the track that all identify themselves as C=78,H=1,S=9 but that have different content. Variations of this schema are used by e.g. Sunrise and MicroCabin protected disks.

2) Have actual 'fuzzy bits' on the disk. Reading those bits 'randomly' results in either 0 or 1. See this very detailed post (about 2/3 down the page) for what exactly 'fuzzy bits' are. So far I haven't seen any MSX game that uses this method, but it's definitely possible.

Here's part of the output of the openMSX 'analyze-dmk' tool. Compared to 'PDI file analyzer' or 'DMK file analyzer' this one also shows the position of the sector-header and sector-data blocks in the track (respectively AOfst and DOfst).

-- physical track 78, head 0
 0: AOfst= 149 C= 78 H=  0 R=  1 N=  2 ACrc=06a9,ok  DOfst= 193 T=n DCrc=c40b,ok 
 1: AOfst= 803 C= 78 H=  0 R=  2 N=  2 ACrc=53fa,ok  DOfst= 847 T=n DCrc=c40b,ok 
 2: AOfst=1457 C= 78 H=  0 R=  3 N=  2 ACrc=60cb,ok  DOfst=1501 T=n DCrc=c40b,ok 
 3: AOfst=2111 C= 78 H=  0 R=  4 N=  2 ACrc=f95c,ok  DOfst=2155 T=n DCrc=c40b,ok 
 4: AOfst=2765 C= 78 H=  0 R=  5 N=  2 ACrc=ca6d,ok  DOfst=2809 T=n DCrc=c40b,ok 
 5: AOfst=3419 C= 78 H=  0 R=  6 N=  2 ACrc=9f3e,ok  DOfst=3462 T=n DCrc=c40b,ok 
 6: AOfst=4072 C= 78 H=  0 R=  7 N=  2 ACrc=ac0f,ok  DOfst=4116 T=n DCrc=c40b,ok 
 7: AOfst=4726 C= 78 H=  0 R=  8 N=  2 ACrc=bc31,ok  DOfst=4770 T=n DCrc=c40b,ok 
 8: AOfst=5380 C= 78 H=  0 R=  9 N=  2 ACrc=8f00,ok  DOfst=5424 T=n DCrc=c40b,ok 
-- physical track 78, head 1
 0: AOfst=  67 C= 78 H=  1 R=  1 N=  2 ACrc=3199,ok  DOfst= 112 T=n DCrc=c40b,ok 
 1: AOfst= 655 C= 78 H=  1 R=  2 N=  2 ACrc=64ca,ok  DOfst= 699 T=n DCrc=c40b,ok 
 2: AOfst=1243 C= 78 H=  1 R=  3 N=  2 ACrc=57fb,ok  DOfst=1287 T=n DCrc=c40b,ok 
 3: AOfst=1831 C= 78 H=  1 R=  4 N=  2 ACrc=ce6c,ok  DOfst=1876 T=n DCrc=c40b,ok 
 4: AOfst=2420 C= 78 H=  1 R=  5 N=  2 ACrc=fd5d,ok  DOfst=2464 T=n DCrc=c40b,ok 
 5: AOfst=3008 C= 78 H=  1 R=  6 N=  2 ACrc=a80e,ok  DOfst=3053 T=n DCrc=c40b,ok 
 6: AOfst=3596 C= 78 H=  1 R=  7 N=  2 ACrc=9b3f,ok  DOfst=3640 T=n DCrc=c40b,ok 
 7: AOfst=4184 C= 78 H=  1 R=  8 N=  2 ACrc=8b01,ok  DOfst=4228 T=n DCrc=c40b,ok 
 8: AOfst=4772 C= 78 H=  1 R=  9 N=  2 ACrc=b830,ok  DOfst=4816 T=n DCrc=0419,ERR

Notice how the sectors in the protected track (head=1) are closer together (smaller gaps in between the sectors) than the sectors in the other tracks (I've only shown one non-protected track, but the others are similar). This denser packing might be because the track needs to hold 10 instead of 9 sectors. This suggests method 1 (duplicated sector) is used.

On the other hand the openMSX READ-DMK tool should be able to detect duplicated sectors in a track (I'm not sure about the DMK6.3 tool). But since the tool did only detected 9 sectors, this instead suggests that method 2 (fuzzy bits) is used.

The DMK file format cannot represent fuzzy bits. For this an even more low level disk format is needed. It also requires an even more low level FDC emulation (the PLL circuit needs to be emulated). OpenMSX does not do that at the moment.

@max_iwamoto: you suggest to return random bits on sectors that have CRC errors. That would fix this game, but it will probably also break other games (games that do use the data contained in sectors with a CRC error). So I prefer not to do that.

@max_iwamoto: because there are indications for both method 1 (denser sector packing) and method 2 (only 9 sectors detected), I'd like to double check the dump. Could you again dump this track using the openMSX READ-DMK tool and show me the status output of the tool while this track is being dumped (e.g. take some photos of the screen). With the options 'start=78 end=78' it's possible to only dump this specific track (this should greatly speedup the process). Thanks.

Por max_iwamoto

Champion (466)

Imagen del max_iwamoto

05-09-2019, 00:53

@ wouter: I believe they using fuzzy bits. I will dump track 78 again and take some pictures and post them here. Also I will try to read same track from debugger on real MSX and present result here as well.

Por max_iwamoto

Champion (466)

Imagen del max_iwamoto

05-09-2019, 05:35

Here is the update... track 78 dump info:

And this is how track 78 with CRC error looks in the debugger after reading:

Read 1-1:

Read 1-2:

---

Read 2-1:

Read 2-2:

---

As you can see the select 10h+ ffset for a reason. Most chages are from 10h to 1Fh!!! In both cases +12h offset not the same.

Página 4/4
1 | 2 | 3 |