I am not sure what PDI support would buy. It seems that PDI project started to mirror similar development on the Amiga side (SPS, formerly CAPS) but still lacks both technical depth and very strict method. In case of SPS releases, one can rely on those being exact images. I already have my doubts about PDI releases -- I can see F-19 on the list and AFAIK that game was copy-protected in its original releases. Also, I would agree that structured format has some advantages over the existing raw dumps but PDI1 does not add anything useful besides CRC while taking away the ability to easily write to image.
However, the idea of adding extra format support to DOSBox is good and sound -- not just adding some particular format (either PDI, or older Teledisk/Anadisk, or whatever) but providing emulator side APIs and allowing plugins on those APIs, similar to WinUAE. Then, whoever maintains PDI can easily create plugin and extend it anytime. This would also be consistent with the way SPS works -- they are closed source. Of course, such an API would go through multiple revisions. Some things may not be doable in current DOSBox core -- I don't know how much of copy protection can be emulated with current implementation. On the positive side, PC is not Amiga - the percentage of copy protected floppies is not that high.

vasyl wrote:

[...] but still lacks both technical depth and very strict method.

I wouldn't say that based on the very few information on their website. They have already converted some copy-protected games to the PDI2 file format. So let's see how it develops..

vasyl wrote:

I already have my doubts about PDI releases -- I can see F-19 on the list and AFAIK that game was copy-protected in its original releases.

Microprose removed the keydisk protection shortly after the game was released, as it only caused problems. The version they preserved is one of those. I know it, because I dumped it.

vasyl wrote:

[...] while taking away the ability to easily write to image.

Err... You should *not* write anything to a PDI file! What's the point of preservation if an emulator can easily modify the file? A PDI file should always stay unmodified. Look how WinUAE works with IPF files. Modifications are stored in a diff file, that's the way to go.

They have already converted some copy-protected games to the PDI2 file format.

Yes, but did they do that correctly? There's a difference between reading and storing a copy-protected disk so that the game will recognize it, and actually understanding the disk layout. You can't do that by using an automated utility, at least with the standard floppy controller.

The project leader, Timo Weirich, seems to be one particularly paranoid fellow. Saturday I replied to a post on the discussion forum that there already exists a PDI to IMA converter. Next thing I saw was the whole forum taken down and the PDI1 spec released. Now the forum's back up, without my post, and with my user name deleted.

Also, he wants to sue "Olivier" for "violating several copyrights", and in the PDI1 spec he's claiming "intellectual property" on the file format, prohibiting anybody from writing a PDI-creating program. Of course, that's complete and utter BS. First of all, "intellectual property" is just an umbrella term for several distinct exclusive rights. Which one does he claim? You can't claim "copyright" on a format (and he also doesn't, as there is no explicit copyright notice), you can only patent it (as Microsoft did with ASF), which he hasn't, so unless he's joking, he's totally confused about this "intellectual property" matter.

Lastly, his reasons for using a proprietary format are a bunch of non-sequiturs (to avoid the word 'nonsense'). Preservation purposes don't require "integrity information" within the format, as anybody who modifies the data can also modify that "integrity information". CRCs exist to detect web transmission errors, not to prevent against modification. Disk images will be transmitted ZIPped or RARed anyway, so you don't need additional "integrity information" within the format itself.

His reason for using "RLE4" compression is even sillier: he doesn't want fixed file sizes (why not?), so he compresses them with "RLE4" because then there's no need to use ZIP or RAR. Of course, there is a need, as there's still a lot of redundancy in his compression. He claims to have used "RLE4" because for preservation purposes, you need a format that can be decoded without any documentation --- so why does he provide one, especially if that one has errors (see below)?

Of course, ZLIB is not just more effective, but also easier to get the source for than his strange method --- basically after three identical literals, the next byte tells you how many more times to repeat that same literal, i.e. F6 F6 F6 FD gives you 256 times F6. Quite obviously, that's NOT what is commonly understood as "RLE4"!

NewRisingSun wrote:

The project leader, Timo Weirich, seems to be one particularly paranoid fellow. Saturday I replied to a post on the discussion forum that there already exists a PDI to IMA converter. Next thing I saw was the whole forum taken down and the PDI1 spec released. Now the forum's back up, without my post, and with my user name deleted.

No sure if you tried to access the forum lately, but whenever I try, I'll get database errors all over the time. I don't think there was something deleted intentional, the admin probably just restored the board from a backup. Anyway, seems like you don't like that project. But you don't really have to. For the rest of your post, it's kind of crap. Just ignore the project if you don't like it.

Hi there,

"Guest" is right, we currently have serious problems with our database, the forum did crash yesterday and had to be restored from an old backup. It's still not working as it should.

@NewRisingSun:

I'm not going to defend why our file format is how it is, but let me reply to some of your wrong conclusions:

Preservation purposes don't require "integrity information" within the format, as anybody who modifies the data can also modify that "integrity information".

The first part of that statement can't be any wronger. Also, integrity information is not there to recognize modifications, but damage! The file integrity is checked every time the file is loaded to make sure that no damaged data is written back to disk.

CRCs exist to detect web transmission errors, not to prevent against modification. Disk images will be transmitted ZIPped or RARed anyway, so you don't need additional "integrity information" within the format itself.

"CRCs exist to detect web transmission errors" ? Should I laugh? Zipping or RAR'ing something does not mean that the file inside the archive was not damaged before. And again, integrity information has nothing to do with "prevent against modification".

As for "Olivier", he spread copyrighted games using our format, which can easily lead software companies to think that *we* spread these games. That's why we are going to sue him.

The first part of that statement can't be any wronger. Also, integrity information is not there to recognize modifications, but damage!

Where would the damage come from, once the file is on your disk, especially when the file is never going to be written to anyway? The greatest source of damage are either web transmission errors, or floppy disk malfunction. The latter is a non-issue nowadays, the former is taken care of through the CRC field in the ZIP or RAR archive used to download the game. That's why you don't need another CRC inside the image itself, also because most people are going to permanently archive their stuff in ZIPed form anyway, which already has its own CRC.

Your PDI1 format offers no new (actually less) functionality compared to zipped IMA (called .IMZ), but comes with several strings attached because you're frivolously claiming exclusive rights. That makes it very unattractive for preservation purposes, and unattractive for me to contribute to the project.

As for "Olivier", he spread copyrighted games using our format, which can easily lead software companies to think that *we* spread these games. That's why we are going to sue him.

What's the charge? Under which country's laws? I already pointed out to you that you can't copyright a format, only patent it, and you have not done so.

NewRisingSun wrote:

What's the charge? Under which country's laws? I already pointed out to you that you can't copyright a format, only patent it, and you have not done so.

You don't seem to understand English very well, or you don't want to understand, as you are still talking about something completely different. Anyway, why do you care at all? We've already informed Sierra and the other copyright holder of the games he spread and gave them all relevant information.

NewRisingSun wrote:

That's why you don't need another CRC inside the image itself, also because most people are going to permanently archive their stuff in ZIPed form anyway, which already has its own CRC.

Then go and blame CAPS/SPS for their file format as well, which has hundreds of CRCs inside. Seriously, you're talking shit, mate!

We've already informed Sierra and the other copyright holder of the games he spread and gave them all relevant information.

You said you are going to sue him, not Sierra. You don't have anything to sue for. You're the one who doesn't know what he's talking about.

Then go and blame CAPS/SPS for their file format as well, which has hundreds of CRCs inside.

Of course it has; you need the sector CRC fields for copy protection purposes. That's not the point; the IPF format does offer additional functionality.

I'm not going to dress you down any more, as you obviously don't know what you're talking about. I'm certainly not going to contribute to your project, however, and I can only advise others not to do that, either. I hope the SPS people finish their generic MFM support, so they can start preserving PC games.

(split this out of the DOSBox wishlist thread, as it was getting to be a long, off-topic discussion)

This project is an also ran, not that there's anything wrong with another source, but if he/they think he/they are going lock up this area and be the end all, he/they've already lost to open projects tosec and good, which are also much further along. BTW, there's a long standing side panel link to tosec at retrogames; retrogames is linked from dosbox's webpage.

I think the guy who runs this "project" just wants to play Doom II and Ultima VI. To me it seems the whole thing is just another way of asking for pirated games...

I found some PDI Floppy dumps, but my computer doesn`t have a floppy drive, and Virtual Floppy Drive dont work on Win 7 64-bit, because .sys files is not signed. In the test mode PDIwrite cant write to a floppy drive - Windows errors and denial of access.

NewRisingSun mentioned about PDI to IMA converter - if it will be possible, anyone PM me archive with it utility.

Follow the directions here and you can use VFD to your heart's content :

http://captainsubtle.com/articles/creating-a- … dows-7-x64.html

Result is same:
In test mode, if A: inst viewed in Explorer:

Windows Error N. 5
Access Denied

If skip it, data dont write to a drive - empty.

In test mode, if A: viewed in Explorer:

Floppy cant be acceded.
Check another application don`t use it.

If disable test mode, vfd dont run, because vfd.sys is unsigned, but I sign it in the test mode.

Here is a utility program written in Turbo C++ for DOS to convert PDI to IMA format. It will run in DOSBox, and is of course limited to 8.3 filenames. Only PDI type 1 images are supported; let me know if you find a type 1 image that doesn't convert correctly. DOS executable and source code are in the attached archive.

ripsaw8080 wrote:

Here is a utility program written in Turbo C++ for DOS to convert PDI to IMA format. It will run in DOSBox, and is of course limited to 8.3 filenames. Only PDI type 1 images are supported; let me know if you find a type 1 image that doesn't convert correctly. DOS executable and source code are in the attached archive.

this utility saved the day!! it was the only way I could open several of my old image disks. Thank you very much.