Thanks hbarcellos for your support. We all in Brazil know(do we?) you are a very good assembly coder. You are an expert. kkkkk
No any country is perfect .... take a look at Belgium :
http://www.investinwallonia.be/2013/01/belgium-17th-most-com...
Good places in the ranking for competitive economy, education system, innovation, etc ... but also
• exceptionally burdensome tax system (140th);
• labor market efficiency (50th), where it does worse than The Netherlands (17th) but better than France (66th) and Germany (55th);
• and government inefficiency (55th).
That's true mars2000you. You are right. My friend hbarcellos always likes to come to my threads to show himself to the community. He is a good friend.
Aqui está o DRAFT da versão 2.0 do padrão PDI.
http://1drv.ms/1ZndHYm
Hi,
I'd like to point out a design mistake in the PDI-v2 format. The main difference compared to the previous version is the addition of fields for the 5 gap lengths and fields for the absolute positions of the sector headers. There are only 5 numbers to represent gap lengths, this means the same gap type must have the same length wherever in appears in the track. This new information is either redundant or inconsistent (pick one).
* If you know the absolute positions of the sector headers you can deduce all gap lengths. So in this sense the gap length fields are redundant.
* On the other hand if you try to use the sector position fields in a non-trivial way (e.g. to try to represent a Sunrise or MicroCabin disk protection), the gaps between the different sectors have different lengths (sometimes there even is no gap). This conflicts with the 5 fixed gap length fields. So in this sense the information is inconsistent.
I'm surprised to see an experienced programmer like you make such a basic mistake.
Also note that you're still missing one other ingredient before you can represent the Sunrise copy protection. I did send you a dmk of such a disk (in private) together with a detailed explanation of how it worked. If you had bothered to look at that file or listened to what I said, you would have known what that ingredient was.
But all-in-all PDI-v2 is an improvement over v1. It's one baby step closer to dmk. Though be careful to not go too far, you might end up with a file format that was not specially designed for DSK-PRO.
who are the TOP 1 and 2?
It's correct. The real size of each sector is to make things easier to dskpro.
Actually there is a mistake in the draft. It is not the physical offset for the ID address. It is the physical offset of the sector data. But I don't even know if I will use it.
I think I will just use the real Size of the sectors.
But in this version of DSKPRO I will not use both of them. Just the GAPS and it's sizes.
And its correct. Just 5 gaps. I know that gap 3 and 4 repeats but I have no intention to make differences on them.
Remember that DSKPRO will not copy every protection..
He's right wouter_! Let's just accept that his format is the best for his own personal tool.
Now, why not take BlueMSX code, add PDI support and rename it with another color name prefix?
Exactly my friend hbarcellos. I thought you would never understand that. Finally!
For some people, it takes longer to understand it...
Actually there is a mistake in the draft. It is not the physical offset for the ID address. It is the physical offset of the sector data.
Really? The only smart thing you added in PDI-v2 turned out to be a mistake. If you point to the sector data instead of to the sector header you cannot represent sector headers without accompanying sector data. Didn't I show/explain you a dmk containing exactly this kind of stuff?
But I don't even know if I will use it. I think I will just use the real Size of the sectors.
In other words: "Damn I screwed up, but I don't want to admit it. I'll just say I'm not going to use the field I just added.
That brings you back in capabilities to PDI-v1 level. So yes, you're a really good low level FDC programmer.
Remember that DSKPRO will not copy every protection..
I seem to remember, just a few days ago, you claiming DSK-PRO can handle all existing copy protections. So how many times have you been proven wrong now?
For those of you who notice my more hostile attitude towards cbsfox, here's the background story:
* post of 06-10-2015, 04:25, cbsfox asks to send him disks containing the Sunrise copy-protection.
* I contact him via mail, explaining i can't send any disk, but i do the next best thing, send a dmk plus instructions for how to create a real disk from it
* cbsfox replies the dmk thing is too difficult for him, he needs to have real disks
* cbsfox asks me to beta test DSK-PRO 9
* I agree, I spend the majority of an evening on it, overall I'm not very impressed with the tool, I find at least 4 bugs, I create a detailed report explaining the bugs and give various suggestions for how to improve DSK-PRO so that it's better suited for my typical tasks on typical European MSX machines.
* I get an angry reply from cbsfox containing among other things quote: "you don't know what you are talking about. I am sorry, but thats the truth."
But I guess it's my fault. From the first few posts I should have seen what kind of person Maecos Daniel really is.
Dear Wouter, be happy with your dmk files. I will not argue with you.
Let's people say what they think about DSK-PRO 9.
We will see who is right...
By the way, why don't you choose another thread that talks about the incredible DMK that has a lot of tools that support it?
What is funny is that you are here in my thread say bad things about me when you should be creating a tool to support your DMK file format...
I will just release DSKPRO 9.0 with PDI support and let people decide if it is good or not.
Thanks for your "great" support and lack of intelligence.