Vamiga: Issues with Kingsoft titles

[dirkwhoffmann]

I’ve run into problems with at least two Kingsoft titles:

• Cruncher factory
• Emerald Mine II

Both games freeze while booting. The drive motor remains on and the head is stuck on cylinder 80 or 79, respectively. Not sure if it related to copy protection, because the following cracked version shows the same issue:

• Cruncher Factory (1987)(Kingsoft)[cr Major ROM].adf

TODO: Check titles in SAE

[dirkwhoffmann]

Cruncher Factory (1987)(Kingsoft)[cr Major ROM].adf

Works in SAE with lowest compatibility settings (Intermediate Blitter, Turbo drive).

There is something fundamental going wrong here 🙈.

[dirkwhoffmann]

Cruncher Factory (1987)(Kingsoft)[cr Major ROM].adf

😧 It's the drive. It works with a turbo drive, but fails with every other "more compatible" drive type.

[mithrendal]

😄... You isolated the problem to a specific part in vAmiga code ... that is a good start ... no ?

One question are there any games which don't work with the turbo drive but only do when using "more compatible"🙄 drive types... If not then just make turbo drive the default and you are done...

[dirkwhoffmann]

that is a good start ... no ?

Yes, because it makes debugging much easier. I can run vAmiga against vAmiga and compare log output. I just checked that it also boots with the ALIGN_DRIVE_HEAD option enabled. That's my secret debug weapon. It makes drive operations deterministic and enables me to compare checksums 😎.

One question are there any games which don't work with the turbo drive

Actually, yes. Although I don't remember any specific titles at the moment, the sheer amount of them made me to select the "original drive" as the default option.

If not then just make turbo drive the default and you are done...

😱 Where did you get your degree from? ... Oh no, wait 😯 ... Don't answer that 🤐.

[dirkwhoffmann]

Actually, this „bug“ is interesting. I am going to briefly summarize what’s going on: After loading the splash screen Crunchman moves the drive head to cylinder 80:

Stepping up to cylinder 80
[2706] (237,211) 01817E  0 BCBSDA 202C 17A0 DiskController: pokeDSKSYNC(44A2)
[2713] (284, 96) 0181B8  0 BCBSDA 202C 17A0 DiskController: pokeDSKLEN(4000)
[2713] (284, 96) 0181B8  0 BCBSDA 202C 17A0 DiskController: DRIVE_DMA_OFF -> DRIVE_DMA_OFF
[2713] (284,104) 0181BE  0 BCBSDA 202C 17A0 DiskController: pokeDSKLEN(8080)
[2713] (284,112) 0181C4  0 BCBSDA 202C 17A0 DiskController: pokeDSKLEN(8080)
[2713] (284,112) 0181C4  0 BCBSDA 202C 17A0 DiskController: DRIVE_DMA_OFF -> DRIVE_DMA_WAIT

After reaching that cylinder, it changes the standard sync mark from $4489 to $44A2. After that it tells the disk controller to watch out for this mark. vAmiga can’t find the sync mark and freezes.

A standard Amiga disk has 80 tracks (numbered 0 … 79). Cylinder 80 is beyond specs and $44A2 a non-standard sync mark. We are clearly facing a copy protection here 😬.

Funny enough, my turbo mode breaks the protection. This is because the following simple function is utilized for searching SYNC marks in turbo mode.

void
Drive::findSyncMark()
{
    for (unsigned i = 0; i < disk->trackSize; i++) {

        if (readHead() != 0x44) continue;
        if (readHead() != 0x89) continue;
        break;
    }
    paula.raiseIrq(INT_DSKSYN);

    debug(DSK_DEBUG, "Moving to SYNC mark at offset %d\n", head.offset);
}

The function assumes that we are working under normal operation conditions which means that every track has SYNC marks. When the first mark is found, it triggers the DSKSYN interrupt. If it doesn’t find any (which can’t happen under normal conditions), it simply triggers the interrupt, too (which breaks the copy protection).

So far so good. Now, the big question is: Why does it work in SAE and UAE? 🤔 How do they get that non-standard sync mark on track 80? ADF files do not contains SYNC marks. Furthermore, there is no cylinder 80 in the ADF we are talking about.

[dirkwhoffmann]

Similar situation with Emerald Mine: The game is looking for $9245 on track 79. With a „turbo drive“, it works just fine:

Here are some brainstorming ideas about a possible solution:

1. Smart up the MFM encoder (which fills illegal tracks with random data). We could make the data „not so random“ by implanting some specific SYNC values into the random data.
2. Add an option that emulates a DSKSYNC interrupt if no sync mark was found after a complete disk rotation.
3. Add an option that ignores the value in the DSKSYNC register and lets the drive controller always search for the standard $4489 mark. However, this would break the copy protection only if we let the MFM encoder format all illegal cylinders, too (otherwise, no standard SYNC marks would be found there).
4. Do nothing because there is always the option to play the game with a turbo drive.

Unfortunately, all options have drawbacks:

• Option 1 only works for titles looking for the SYNC mark on illegal cylinders. Crunch factory does, but Emerald Mine does not. The latter game expects the mark on cylinder 79 (the largest legal cylinder).
  
  
  
  • Option 2 is not really transparent to the user. Why should he enable it if he doesn’t know anything about copy protection?
  
  
  • Option 3 is more transparent to the user, I think, but other programs might get confused if they find formatted cylinders above 79.
  
  
  • Option 4 confuses the user because it seems to break the assumption that an „original drive“ is more compatible than a „turbo drive“.
  
  

Any other ideas are very welcome…

[dirkwhoffmann]

I went for option 5: Adding a separate „Piracy“ section to the Compatibility settings 😎.

The first option (red arrow) locks the value of the DSKSYN register to the standard value. It makes it impossible to let the disk controller search for sync words other than the default.

The second option (yellow arrow) forces a DSKSYNC interrupt to be triggered even if no SYNC marks are present on the current track.

As expected, the first option breaks the copy protection of Emerald Mine (because it now finds a (standard) SYNC word on track 79), but not the copy protection of Crunch Factory (because track 80 is filled with random numbers). The second option breaks both copy protections, because there is a DSKSYNC interrupt for all tracks now, no matter what data they contain.