Does saving protected disks work with all supported disk controllers in dsk-pro?
All except Panasonic's, because their chipset (Toshiba) does not have all necessary commands.
I'm not seeing anyone bashing PDI here, I'm just seeing some friends trying to get a rational explanation on how and why PDI is a better format.
cbsfox, it seems that you're not aware that implementing your different file format will require precious personal time from the developers. So, if you want anyone to engage on coding PDI support, you'll certainly need more convincing arguments than the well known tactics like appeal to authority, appeal to novelty, and jump on the bandwagon. Those may work well in the latin cultures, but aren't welcome at all in many other cultures.
And it may sound that (oh, and it seems that you already explicitly stated) that you're the only one who knows everything about FDCs while anyone else don't and are too dumb to understand. Or might even let the impression that the insistent use of the mentioned tactics means that you consider the others to be fool enough to fall for them. You certainly don't want to give them that kind impression, do you?
I can assure you that Manuel is also an ages old friend of mine, and he was always very rational and polite. I can vouch for him anytime. Keep in mind that asking for information to allow someone to have his own opinion about a subject isn't rude. It's just rational.
Well, it looks like that some Dutch programmers think that they are the only ones to have the holy grail. Always saying the same negative critics just like Manuel does again and again and again before being able to use the announced tool and to make comparisons is really stupid. Stop this absurdity and wait silently for the release of this promising Brazilian tool.
The point is not about the tool, so it is not related to having it used and tried (and so I'm not making comparisons with other tools). The point was about the format, which is actually the topic of this forum thread. So, I have no critic on the tool as I haven't seen it. I merely state my disappointment on the fact that it will not be using a existing and already supported file format but a completely new file format.
There's no holy grail on the existing DMK format, it's just that it was already there and already supported by multiple tools and absolutely sufficient for any kind of MSX purpose. But apparently cbsfox got caught by Not Invented Here syndrome and decided to push his own format. Fine, but it's just a missed chance on getting some wider support for a fine format that is already in existence.
Anyway, as I am not seeming to get anywhere, I'll just give up on this. Just hoping that indeed someone will make conversion tools as was mentioned in an earlier post.
ok, lets concentrate on PDI here ok?
My friend Rudolf Gutlich will unleash the draft of PDI file format.
And my dear friend sd_snatcher, I never said I am the only one who knows everything about FDCs and everyone else are too dumb. You are saying that....
I can say by a HUGE MILE that I am TOP 3 in the world when talking about direct access to FDCs. I have 30 years of experience on that. So when I say something about that, it is what I am saying.
I am not saying that PDI is better or not than DMK, I don't even know a lot about that format, BUT I can say that PDI is the more appropriate format for my tool (DSKPRO). I decide that. Just me and myself.
And I can say by a MILE that PDI is the simplest format.
And for those who prefer to use DMK, we can all together create a tool to convert from PDI to DMK and from DMK to PDI. Everyone are free to use whatever they want.
So, here in this topic, lets concentrate to know more about PDI.
Hi everyone, here is the DRAFT for the PDI File Fomat.
The complete manual is being made and will be available as soon as possible.
If you have any doubts, let me know.
Thanks!
What kind of BS is this? If I understood correctly this thread is about internal file format that is currently supported by 0 = ZERO softwares AVAILABLE for MSX or PC where you have told about 0% of technical details and that should not be compared to anything existing? I'm totally puzzled about what kind of discussion you expect to come out from this kind of approach?
After 4 pages of ranting there is finally even DRAFT of the upcoming file format, but what I see is just advertisement of DSK-PRO that went horribly wrong from the start. IMHO now finally the two persons that seem to know something about the issue should start to explain why they started this discussion and why on earth this should be an interesting subject to anyone else? Do you want input for your project? Why "PDI is the future" ? Does it compress better than other formats? What are the features that other formats don't have? Why it suits MSX better than other similar formats? etc. (and naturally comparing with DSK is a joke, so if you have that in minds, don't bother.)
... and don't get me wrong here. I think DSK-PRO is a great project and software like this is very much needed by MSX community, but I don't think that you can make unfinished internal file format of it as "de facto"-standard without first making it popular in traditional means and also explaining the benefits in detail to community. It is not enough that you are the best and YOU KNOW that it will be "better than anything else" when it is ready. I know that currently only DSK has wide support among MSX-emulators and that is a bit sad, but still your way to try to fix this seems completely upside down. New standard should start from good, well thought out open documentation, examples, explanation of benefits and open discussion. It takes time and it seems to me that you are not ready to take that step yet.
It's a marketing strategy which makes one curious to read how people will reply to the message rather than to the software itself.
If I see commercials on TV with the same attitude, I choose the other brand.
I wish you good luck.
Why are you afraid, you of little faith?
Mt 8: 23-27
Hi everyone, here is the DRAFT for the PDI File Fomat.
The complete manual is being made and will be available as soon as possible.
If you have any doubts, let me know.
Thanks!
Hi cbsfox, mister.phr0zen,
I'm one of the openMSX developers, I'm currently evaluating how to add PDI support to openMSX (and whether it's worth it). I read the PDI file format draft with great interest. Unfortunately it's rather vague on some important details. Would this forum be a good place to discuss these details, or can I contact you in another way?
Some of the question that come to my mind are:
* How are disks with more than 40/80 tracks represented? Just append the extra tracks at the end? If so, what is the meaning of the byte at offset 1?
* What track layout does the PDI format assume? (Standard IBM format?) What is the length of a full raw track? (Always exactly 6250 bytes?) At offset 3 there are 5 bytes for "formatting gap bytes", are these the filler bytes for the 5 gaps in the standard IBM format? What about the length of those gaps?
* In the PDI spec I only see room to store 1 pair of CRC bytes, I assume this is the CRC for the sector data? Does this mean the CRC of the sector header is not stored?
* Per track there is a data buffer of 5120 bytes, does that mean PDI can store at most 10 sectors of 512 bytes per track? What if my protected disk stores more data?
With these details cleared up it should be possible to create a conversion routine from PDI to the internal openMSX format (internally openMSX uses something very close to DMK).
Unfortunately the inverse conversion, from DMK to PDI, is not always possible because PDI cannot represent all possible protections (or disk layouts). One very important example is the Sunrise copy protection (it stores 11 partially overlapping 512-byte sectors). Also PDI cannot represent copy-protections where the position (not just the order) of the sectors within the track is important, correct?
I hoped DSK-PRO would be able to replace READ-DMK (even though I wrote the latter tool). Unfortunately the above limitations mean it cannot yet. (I'm assuming DSK-PRO is only able to create PDI files, correct?). Can we somewhere discuss how to extend PDI/DSK-PRO so that it can also handle the Sunrise copy-protection? Any estimate for when DSK-PRO will be released so that I can take a closer look at it?
If it's useful to you (or anyone else) here's a link to the source code of the READ-DMK tool. The low-level FDC-stuff in the code is well documented, but feel free to ask questions if anything is unclear.
https://github.com/openMSX/openMSX/blob/master/Contrib/dmk/R...
Wouter