Dungeon Master Amiga V2.1 availability?

[rhester72]

For me, this is the 'holy grail' release, as it's the version I bought and played many, many, MANY years ago (and thus no longer have).

IPF preservations of all other versions exist...but 2.1 is notably missing.

I've attempted to reconstruct it from an untouched ADF dump of 2.1 merged with the weak bitcell protection track from both 2.0 and 2.2 without success...the game loads and plays, but fails on the save check for reasons unknown.

If someone with 2.1 would care to create a raw dump of it, sell it to me, loan it to me for preservation...I'm open to any options. =)

[ChristopheF]

Sorry I don't have that version nor any raw dump.

[ChristopheF]

I saw your post on EAB about this version.
I found an email message that someone sent me a very long time ago about that version 2.1. It was in French, here is a Google translation:

Regarding the changes between versions, I would also very much like to know about them. Perhaps in some cases it relates more to the "system" than the game itself. For example, Amiga version 2.1 does not have "standard" floppy disk handling; if you remove a floppy disk from the drive (internal or external), it doesn't make any "clicking" at regular intervals as is usually the case on this computer. And if you reinsert the disk, there is no automatic detection either. In version 2.2, this was corrected. It also seems to me that this version 2.1 is one of the only ones I own that accepts loading a saved game even if the save disk is write-protected. Usually, DM always asks you to unprotect the save disk even for loading (I think this is so you can rename a "dmgame.bak" file to "dmgame.dat" when the disk only contains a .bak file). However, I have a doubt; version 2.2 might have the same behavior.

Maybe this can help in your quest and your tests.

I have not seen your home made IPF, but the method you have used should work and I doubt that the copy protection is causing the issues.

[rhester72]

I'm going to retest all three 2.x versions, but my vague recollection is that at least under emulation, all three behaved the same (with respect to diskchange and idle click at least).

[rhester72]

OK - I thoroughly tested all three, and behavior (in terms of auto disk recognition, clicking, etc.) are identical between the three releases except that 2.1 will format the save disk, however it will not *recognize* either the save disk or master disk after. Completely bizarre.

[ChristopheF]

however it will not *recognize* either the save disk or master disk after

Does that happen only right after formatting while the game is still running, or also after rebooting the game from scratch ?
If you format a save disk floppy with v2.1, is it recognized by version 2.0 or 2.2, with only version 2.1 failing to recognize it ?
If you format a save disk floppy with v2.0, is it recognized by version 2.1 ?
AFAIK, there is no difference in the floppy disk format code between 2.0, 2.1 and 2.2. So I suppose each scenario should show exactly the same behavior no matter which version was used to format the floppy.
Does that happen when using a single floppy disk drive or also two disk drives (one for the game, one for the save disk) ?
Don't you think that the inability of the game to recognize the floppy could be caused by an auto detection issue?

I've never played version 2.1 in an emulator because I only have a copy protected ADF of the original. Could you please share your custom made IPF ?

[rhester72]

For some reason, it won't let me quote you.

Does that happen only right after formatting while the game is still running, or also after rebooting the game from scratch ?

Both. (I really thought you were on to something here!)

If you format a save disk floppy with v2.1, is it recognized by version 2.0 or 2.2, with only version 2.1 failing to recognize it ?

It is recognized by both 2.0 and 2.2. While testing this, I noticed there actually is a difference unique to 2.1. On 2.0/2.2, inserting the save disk results in a track seek after insertion. This does not happen in 2.1.

If you format a save disk floppy with v2.0, is it recognized by version 2.1 ?

No.

AFAIK, there is no difference in the floppy disk format code between 2.0, 2.1 and 2.2. So I suppose each scenario should show exactly the same behavior no matter which version was used to format the floppy.

I still believe there's some subtle difference on the protection track that is being detected by the code and deliberately tanking the ability to save on 2.1. Despite its short shelf life, I do not believe it possible that 2.1 was shipped into retail with the save function completely broken. I do want to try swapping the protection tracks between 2.0 and 2.2 to see if either of them break.

EDIT: I swapped the protection tracks between 2.0 and 2.2 and both worked properly, so either 2.1 had a protection track unique to itself or protection isn't the issue.

Does that happen when using a single floppy disk drive or also two disk drives (one for the game, one for the save disk) ?

Multiple drives are not supported on Amiga, despite the game clearly recognizing the difference between unformatted disks, save disks and master disks.

Don't you think that the inability of the game to recognize the floppy could be caused by an auto detection issue?

Possible (noting the lack of a seek at all after inserting either the save or master disk on the save screen), but it still seems to be an underlying copy protection check failure versus a bug.

I've never played version 2.1 in an emulator because I only have a copy protected ADF of the original. Could you please share your custom made IPF ?

I'd love to, but I can't seem to attach a zip archive. Is there another type supported?

[Gambit37]

Multiple drives are not supported on Amiga, despite the game clearly recognizing the difference between unformatted disks, save disks and master disks.

Are you sure? Back in the day, I played DM on an Amiga 1000 with an external 3.5 inch drive: the DM disk went in DF0:, the internal drive, while the save disk went in the external drive, DF1:

Perhaps you mean multiple drives beyond those two drives?

[ChristopheF]

I'm quite convinced the copy protection track is not the issue here.
The fact that you did not have the automatic track seek after disk insertion with 2.1 is in line with the mail I got (and posted previously in this forum topic).
This automatic track seek after disk insertion is a standard Amiga feature, it is not at all specific to DM and its copy protection.
When the drive is empty, the Amiga tries every few seconds to read from the drive in order to detect if a floppy disk was inserted. That is how the Amiga can automatically boot from a floppy disk a few moments after it was inserted, without needing to press any key or restart the computer or any other manual action.
I think the game does not recognize the save disk when you insert it simply because the Amiga OS does not detect the disk change. So the OS, and thus the game, thinks the game disk is still in the drive and refuses to save. Not because of the copy protection, but because a save disk was not detected.

I rather suspect that a change between version 2.0 and 2.1 floppy disks broke this default Amiga behavior. And maybe that is what prompted for the creation of version 2.2 to fix that issue.

Given that the issue was fixed in version 2.2, I have compared the files in both 2.1 and 2.2 floppy disks, and the only differences are:
- The game executable (file 'dm'). Same file size, but 5 bytes were changed in 2.2 compared to 2.1
- Version 2.2 adds the file 'DungeonB.dat' (the kid dungeon). Irrelevant to our issue, as it is not loaded unless you press ALT key while the game is loading.
There might be other differences on the floppy disks, outside of the files themselves (the boot sectors are identical, but maybe some file system structures differ).

The ReDMCSB source code shows the executable differences from 2.1 to 2.2:
- There are only 3 changes compared to version 2.1
- The version 2.2 executable is most probably a "hacked" variant of the 2.1 executable made with a hex editor rather than recompiled from the C source code. I say that because a branch instruction test was bypassed using a 'nop' instruction (2 bytes changed). There is no way that a developer would make such a change in the source code (like I did in ReDMCSB to reproduce the same 2.2 executable), they would have simply deleted or commented out the if statement.
- The version number visible in the upper right corner of dialog boxes was updated from 2.1 to 2.2 (1 byte changed). However they they did not update the version number used by the "version sensor", which is still "21" instead of the "22" that it should be. This also points to a hasty fix through hacking.
- Versions 2.0 and 2.1 allocate all chip memory except 2400 bytes left to the OS. Version 2.2 allocates all chip memory except 12000 bytes left to the OS (2 bytes changed).

There are differences in file 'exec' between 2.0 and 2.1 regarding memory. Maybe that cause the issue, and it was worked around by modifying the 'dm' file.
I would need to look deeper into that issue to understand what really happens.


DM does indeed support two drives on Amiga, as stated on the referenced card supplied with the game. The game disk must be in DF0:, and the save disk may be inserted in DF1/2/3.

You cannot attach zip file here. Can you please upload your zip archive to an online free file transfer tool, like https://limewire.com/ ? You just go there, drag and drop your file, click the 'Share' button and you get a download link to post here.

[rhester72]

Multiple drives are not supported on Amiga, despite the game clearly recognizing the difference between unformatted disks, save disks and master disks.

Are you sure? Back in the day, I played DM on an Amiga 1000 with an external 3.5 inch drive: the DM disk went in DF0:, the internal drive, while the save disk went in the external drive, DF1:

Perhaps you mean multiple drives beyond those two drives?

No, I'm talking about the fact that no matter how many drives are attached or what disks are in them when you attempt to save, the game still prompts for "INSERT SAVE DISK IN DF0:" =)

Hrm. I may need to revisit this. The manual clearly states it supports two drives:

https://amiga.abime.net/manual/0401-050 ... .pdf?v=546

It's possible that since I was testing with initially-unformatted floppies (on purpose), it couldn't recognize anything in DF1:. I'll retest.

[rhester72]

This automatic track seek after disk insertion is a standard Amiga feature, it is not at all specific to DM and its copy protection.

If using trackdisk, yes. Especially given observed behavior, it seems more likely they aren't using OS calls for floppy management at all (and thus behavior is however they coded it).

I rather suspect that a change between version 2.0 and 2.1 floppy disks broke this default Amiga behavior. And maybe that is what prompted for the creation of version 2.2 to fix that issue.

Possible, but that would be a MAJOR thing to miss in most fundamental QA testing, especially to ship a completely broken-from-the-start product (surely not!).

It also seems hard to imagine that it was in retail channels in that state for 7 months before being fixed.

- The version 2.2 executable is most probably a "hacked" variant of the 2.1 executable made with a hex editor rather than recompiled from the C source code. I say that because a branch instruction test was bypassed using a 'nop' instruction (2 bytes changed). There is no way that a developer would make such a change in the source code (like I did in ReDMCSB to reproduce the same 2.2 executable), they would have simply deleted or commented out the if statement.

Good information. What operation did it branch to in 2.1?

- Versions 2.0 and 2.1 allocate all chip memory except 2400 bytes left to the OS. Version 2.2 allocates all chip memory except 12000 bytes left to the OS (2 bytes changed).

This indirectly reminds me of something. I've never tested with Kickstart 1.3, only 1.2. Added to my to-do list.

DM does indeed support two drives on Amiga, as stated on the referenced card supplied with the game. The game disk must be in DF0:, and the save disk may be inserted in DF1/2/3.

Agree, I observed the same. I find it interesting that if the disk is unformatted, it very specifically instructs you to insert into DF0: for formatting.

IPF uploaded to https://limewire.com/d/yDPOP#kfUdLEGrwP (looks like it's for one week only).