Copy Protection Information: Weak Bits, Bit-rate ...

A forum about Atari protected floppy disks analysis, preservation, emulation, tools

Moderators: DrCoolZic, Brume

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 01, 2006 8:17 am

ijor wrote:
DrCoolZic wrote:But it add a nice touch: a slowly sliding bits that will for sure result in fuzzy bits ...
It is not a nice though, it is required to get the desired result using this technique. If you just make the transitions fixed on the middle range, then the result would depend on the drive.

In fact it is not necessary. As you are aware (because I think you reproduce that it in Pasti) drive rotation speed is far from beeing constant and vary randomly and therefore if you have a transition on cell border this will result in random value returned.
You might argue that it is impossible to make sure that these transitions will be positioned correctly at the extreme border of a cell due to the fact that beyond the small random variations of rotation speed of the drive the "center" value is quite different on different drives. But this is where the DPLL of the WD1772 comes into play. I do not know if you have looked at the us patent that describes it, but it explain quite well how the DPLL does phase corrections (on top of frequency corrections) that will center the inspection window on the transition stream perfectly (please refer to my doc or patent for more info). As I have explained I have implemented the DPLL, as described in the patent in my prog, and indeed it does that very efficiently. This also explain why very often when you have this kind of "fuzzy bits" technique used you will find what I call "fuzzy bits pairing". That is two very close transitions: one at the extreme begining of the inspection window, and the pairing transition at the extreme end of the window. By using this pairing neither the frequency nor the phase correction are affected.

Actually if you look at the actual values used in DM (that I provided in my doc) they are mostly 0 or 1 (extreme left) and 9 or : (extreme right) but no sliding transitions. Actually i believe that this is probably more efficient than the "sliding transitions" that would affect the DPLL phase/freq correction.

Ps the other method for getting fuzzy bits are much more difficult to realize and I do not think were used for Atari diskettes?

ijor wrote:I didn't read it detaily, but if you are talking about using track misregistration, or physical alteration for producing weak bits, then AFAIK not.

The two other methods described are: slightly moving the head while writing (misalignement) resulting in weak signal during read, and writing 2 tracks between tracks (tracks overlaps). These two methods are resulting on "analog" variation of the signal and are probably more difficult to control/predict and this why I do not think they were widely used.

What is interesting is that the patent describes the concept of the fuzzy/weak bits (acyually it even provides a flowchart to verify ramdomness of the read) and incidentally indicates some techniques to acheive this.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 01, 2006 8:26 am

gothmog wrote:By the way, I am the webmaster of the DM & CSB Encyclopaedia http://dmweb.free.fr/. Thanks for the link to my website in your document.
I know!

For one I have spent literally years playing with DM/CSB with (but mainly without) my kids and I was completly addicted...

... and already long long time ago I discovered your site and I just loved it. So many "souvenirs" and useful informations.

One regret: you used to have a section on "eyes of the beholders" that I can't find anymore???

Thanks again for this wonderful site ...
Jean

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 01, 2006 8:31 am

ijor wrote:
DrCoolZic wrote:A have completed a new version (0.4) of the Atari FD protection mechanisms.
...
As usual I am interested in getting feedback to correct errors, ambiguities, etc.


I intended to make some comments. But seems you protected the PDF, then it is quite cumbersome, because I would need to retype every quote :(

Sorry for that I did not realize. This is due to the default setting I have for Acrobat distiller in MS Word.
I intend to update the doc quickly with the above info and I will make sure that it is possible to annotate the pdf doc in the next release.
Thanks for the info.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1161
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Fri Dec 01, 2006 8:33 am

DrCoolZic wrote:By the way Greenious
The project you are talking about what is it exactly? Is there a description available somewhere???


No, not really. Since work is slow, for various reasons, and since I don't want people putting pressure on me (since I do it for fun), I have deliberately not made any "official" information about this project available.

I have mentioned it on several occassions on this board though, like I am doing now.

Once I got some real progress, I am going to put up more official information, aswell as start taking preorders (to see how many I will make).

I'm making the board for myself, so the features are those that I want.
In short, these are the features of the board:

- 16 MHz CPU accelerator with cache (think Adspeed)
- Fastram (8 or 12 mb, I have yet to decide)
- IDE interface
- Alternative PSG rom select signal (add shadowregisters back into STE)
- Some other small things I've been thinking about.

Additional features that will be optional, or things that the design of the board, will allow to be fairly easy to add later
- FPU
- some kind of expansionbus. Perhaps for adding a DSP later on.
- other things I don't know as of yet.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1161
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Fri Dec 01, 2006 10:55 am

ijor wrote:You need more than just I/O pins. But nothing that couldn't be implemented in a small FPGA/CPLD. Perhaps the most expensive aspect is the ROM stuff (remember what we talked about in the overscan thread). But you don't need to execute from ROM if you have fast RAM. I'm not sure, but with the knowledge that we currently have about pairing, it is possible that it could be done running from plain RAM. But without ROM you lose DC compatiblity, which is a good thing to have.


Well, if the goal is to make a DC compatible cartridge, you would need code in ROM. But then the project gets more complicated, and I think it would be an entirely different one too. Personally, given the relative scarcity of good external diskdrives today, I think that it has to be something that adds to the internal drive, or a complete external unit, with built in floppy.

My idea was more like making something similar to DC. Something that would be simple to implement, and able to benefit from a faster CPU & fastram. Adding some sort of analog to digital converter to be able to properly read & analyze a floppy in the internal drive is relatively simple, but I think most users also would like the ability to write a perfect copy.

If I put it this way. As it is now, DC is only able to write a good copy on an external diskdrive that it can control directly. How do we make it possible to exert the same level of control to the internal diskdrive, while still maintaining normal function for everyday use? And perhaps most important, at a cost most ppl is willing to pay?

If you ask me, something that I would like is a programmable ripper/freezer. That is, something like the Ultimate Ripper but with flash instead of EPROM. Or even better with NVRAM, or anything that you could easily rewrite as much as you want. Actually even volatile RAM could be good enough, because you can cold boot without power cycling.

A step forward with the same idea would be a programmable TOS. Again, in flash, NVRAM, or just RAM.


I am a bit weary against putting a cartridge rom on a daughterboard to the CPU. For many reasons, but most because I think it is a bad idea to risk that someone inserts a cartridge in the cartridge port, while having the daughterboard rom active.

An alternative would be to use a cartridge with a bootstrap code that simply jumps to somewhere in fastram, or, using a cartridge like AN Cools mentioned below, that lets you run code from a debugger.

Flashrom, while useable, is also something that I feel is a function most users will very seldom use. I could use one myself, otoh, I have the equipment & skills to do it with eproms, and I seldom need it, so... I kinda believe it just something that would add to the cost, while few would really appreciate it & use it. I might be wrong though.

There are other variants though, especially on ST, you could use if you really want to.

One way, if you have a 2 rom TOS ST(FM), is to use 2 of the other 4 sockets to add your cartridge roms, bend up the pin for chip select. Use a switch, and connect ground & cartridge rom select line to the switch, and let the output go to the eproms chip select. Now you have a "cartridge" that you can enable whenever you need, and disable when you need to connect other things. The remaining 2 sockets could be used for a full 128kb cartridge (most cartridges are 64 kb), or as a second cartridge.

About ultimate ripper, have you seen AN Cool's "The Explorer"? He released it with full source a while back. Much more powerful than ultimate ripper.
http://home.earthlink.net/~chhome/explorer.html
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 01, 2006 1:38 pm

ijor wrote:
Thanks again mr Gothmog
Thanks indeed. I wasn't aware they were granted a patent. Strange, I'm not sure, but I think they weren't the first neither the last using this technique.
I do not think that the patent was granted for DM as it is used in other games, and DM use a variation of what is described. But the patent definitively cover the protection used by DM.

Ok based on the feedback here is a new version of the document:
V0.5 Incorporated feedback from Gothmog about the DM protection patent, added a section with several US patent about protection, modified the section on fuzzy bits, modified the fuzzy bit section in WD1772 DPLL.

You should also be able to annotate the pdf file if you'd like to add comments.
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 01, 2006 3:46 pm

Greenious wrote:If I put it this way. As it is now, DC is only able to write a good copy on an external diskdrive that it can control directly. How do we make it possible to exert the same level of control to the internal diskdrive, while still maintaining normal function for everyday use? And perhaps most important, at a cost most ppl is willing to pay?

Not sure I follow you on this one ? DC does not need an external disk drive (although it supports it) and works perfectly with the internal one

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Fri Dec 01, 2006 4:29 pm

Greenious wrote:Well, if the goal is to make a DC compatible cartridge, you would need code in ROM. But then the project gets more complicated, and I think it would be an entirely different one too. Personally, given the relative scarcity of good external diskdrives today...
Adding some sort of analog to digital converter to be able to properly read & analyze a floppy... As it is now, DC is only able to write a good copy on an external diskdrive that it can control directly. How do we make it possible to exert the same level of control to the internal diskdrive, while still maintaining normal function for everyday use?


I think you have a very wrong idea of how the DC works. In first place it perfectly works with internal drives. You don't need an external one. In second place the DC doesn't perform any analog to digital (or viceversa) conversion.

The reason that the DC can work with internal drives is because all the FDC outputs are open collector.

One way, if you have a 2 rom TOS ST(FM), is to use 2 of the other 4 sockets to add your cartridge roms, bend up the pin for chip select.


But I don't want just a TOS switcher. I want much more. I want to be able to patch the ROM and use patched TOS (or even my own OS). And I want to be able to this as much times as I want and easily (means, not burning EPROMS for every change).

About ultimate ripper...


Again, this was just an example. The idea was to have a cart whose ROM I can easily and quickly modify.

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Fri Dec 01, 2006 4:34 pm

DrCoolZic wrote:I do not think that the patent was granted for DM


It was granted for the company that made DM:
Assignee: Software Heaven, Inc


Ok based on the feedback here is a new version of the document:
V0.5 ...
You should also be able to annotate the pdf file if you'd like to add comments.


Sorry, still protected. Btw, it wasn't my intention to annotate the PDF. Just to cut & paste individual lines from the PDF, for and adding comments here.

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Fri Dec 01, 2006 4:46 pm

DrCoolZic wrote:In fact it is not necessary. As you are aware (because I think you reproduce that it in Pasti) drive rotation speed is far from beeing constant


The problem is not the rotation speed. The problem is the analog components of the drive. The analog components are much more than ADC, they have filters, equalizers, cross detector, etc. So what you get out of the drive is not exactly what is recorded on the disk surface.

User avatar
Greenious
Hardware Guru
Hardware Guru
Posts: 1161
Joined: Sat Apr 24, 2004 5:39 pm
Location: Sweden

Postby Greenious » Fri Dec 01, 2006 5:10 pm

ijor wrote:I think you have a very wrong idea of how the DC works. In first place it perfectly works with internal drives. You don't need an external one. In second place the DC doesn't perform any analog to digital (or viceversa) conversion.

The reason that the DC can work with internal drives is because all the FDC outputs are open collector.


Hmm, I thought that DC had to cut off the FDC, even with open collector, so that DC would be able to feed it's own signal without the risc of the FDC interfering, or at least be able to delay/speed up the signals coming from the FDC. I just recently (last week) got my hands on a DC, and have yet to actually try it out.

But I don't want just a TOS switcher. I want much more. I want to be able to patch the ROM and use patched TOS (or even my own OS). And I want to be able to this as much times as I want and easily (means, not burning EPROMS for every change).


TOS switcher? er... It is a cartridge switcher! ;)

Most people would probably want to put TOS in fastram anyway, but making the option to boot OS directly fom RAM, should not be that difficult.

Again, this was just an example. The idea was to have a cart whose ROM I can easily and quickly modify.


It is a developers tool that you are looking for, while I don't really see any major problems doing it, I suspect that very few would be interested in it. but I'll do some thinking about it. Maybe I can come up with something that is both convenient, and doesn't cost too much.
Updated my guides as of june 28th, 2016. Check'em out and feedback!
viewtopic.php?t=5040

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 01, 2006 9:31 pm

ijor wrote:It was granted for the company that made DM:
Quote:
Assignee: Software Heaven, Inc

Interesting this would explain why other like DrT had to come with other way to produce fuzzy bits.

ijor wrote:
DrCoolZic wrote:In fact it is not necessary. As you are aware (because I think you reproduce that it in Pasti) drive rotation speed is far from beeing constant


The problem is not the rotation speed. The problem is the analog components of the drive. The analog components are much more than ADC, they have filters, equalizers, cross detector, etc. So what you get out of the drive is not exactly what is recorded on the disk surface.

Sorry but I do not see your point? Small disturbance in rotation speed results in "marginal transition" falling into one or the other of the inspection window.


The attached pdf should allow you to do cut and paste.
You do not have the required permissions to view the files attached to this post.

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sat Dec 02, 2006 3:01 am

DrCoolZic wrote:The attached pdf should allow you to do cut and paste.


Thanks!

All the following quoted paragraphs from your article are wrong, at least partially. I understand that on most cases they might be not much more than typos, or simple oversights. Or at least you will probably realize immediately about the mistake. So I avoided elaborating. If in some cases are not clear what or why it is wrong, or you don't agree, let me know:

Each Sector is composed of blocks:
Gaps (GAP 1, GAP1a, GAP2, GAP3a, GAP3b, GAP4, GAP5),


- Example: Dungeon Master (FTL Inc.) sector track 0, sector 247 replace the sector 8
- Duplication: Easy by software.


Sector with no Data Address Mark
Example: X-out (Rainbow art games)


Sector passing over Index Pulse
Duplication: As mentioned such a track cannot be created by the FDC as a result it is necessary to use special hardware (analog or digital copiers)


...Rob Northen in the so called Copylock protection mechanism... Note that the sector also contains fuzzy bits.



You seem to miss two very popular protections. Intra-sector variable bitrate, and inter-track variable bit-rate.

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sat Dec 02, 2006 3:39 am

DrCoolZic wrote:Sorry but I do not see your point? Small disturbance in rotation speed results in "marginal transition" falling into one or the other of the inspection window.


No, it might be not. Depending on the drive (and other minor factors) instantaneous speed variation might be too small. So if the transition that you intended to record exactly on the border of the window, might always fall on the same side of the window.

This is an extract of a raw dump with the DC:

Code: Select all

000000   40 3F 40 3F 40 3F 40 3F 40 3F 40 3F 41 3F 40 3F
000010   40 3F 40 3F 3F 40 3F 40 3F 40 40 3F 40 3F 40 3F
000020   40 3F 40 3F 40 3F 40 3F 40 3F 40 40 3F 40 3F 40
000030   40 3F 3F 40 40 3F 3F 40 40 3F 40 3F 40 3F 40 3F
000040   40 40 3F 40 3F 3F 3F 40 40 40 3F 40 40 3F 40 3F
000050   40 3F 40 3F 40 3F 40 3F 40 3F 40 40 3F 40 40 3F
000060   3F 40 40 3F 40 3F 40 3F 40 3F 40 40 3F 40 40 3F
000070   40 3F 40 3F 40 3F 40 3F 40 3F 40 40 40 3F 3F 40
000080   40 3F 40 3F 40 3F 40 3F 40 3F 41 3F 3F 40 40 3F
000090   40 3F 40 40 3F 3F 41 3F 3F 40 40 3F 3F 40 40 3F
0000A0   40 3F 40 3F 40 3F 40 3F 40 40 3F 40 3F 40 40 3F
0000B0   40 3F 40 3F 40 3F 40 40 40 3F 40 3F 40 3F 40 3F
0000C0   40 3F 40 40 3F 3F 40 40 3F 3F 41 3F 40 3F 40 3F
0000D0   3F 40 40 3F 3F 40 40 3F 40 3F 40 40 3F 3F 41 3F
0000E0   40 40 3F 40 3F 40 3F 40 40 3F 40 3F 40 3F 40 3F
0000F0   40 3F 40 3F 40 40 3F 3F 40 40 3F 40 3F 3F 40 40
000100   3F 40 40 3F 3F 40 3F 40 40 3F 40 3F 40 3F 40 3F
000110   40 3F 40 3F 40 3F 40 3F 40 3F 40 3F 40 3F 40 3F
000120   40 3F 40 3F 40 3F 40 40 40 3F 3F 40 40 3F 40 3F
000130   40 3F 40 3F 40 40 40 3E 40 40 40 3F 40 3E 41 40
000140   3F 3F 40 3F 40 3F 40 3F 40 3F 40 40 3F 3F 40 3F
000150   40 40 40 3F 3F 40 40 3E 41 3F 40 3F 40 3F 40 40
000160   3F 40 3F 40 40 3F 40 3F 40 3F 40 40 3F 3F 40 40
000170   3F 40 3F 40 40 3F 40 3F 40 3F 40 3F 40 3F 40 3F
000180   40 40 3F 40 40 3F 40 3F 40 3F 40 40 3F 3F 41 3F
000190   3F 40 40 3F 40 3F 40 3F 40 3F 40 40 3F 40 3F 40
0001A0   40 3F 40 3F 40 40 40 3F 3F 40 3F 40 3F 40 40 3F
0001B0   40 3F 40 40 3F 40 3F 40 40 3F 3F 40 40 3F 40 3F
0001C0   40 40 40 3F 40 3F 40 3F 40 3F 40 40 3F 3F 40 40
0001D0   3F 40 3F 40 40 3F 40 3F 40 3F 40 40 3F 40 3F 40
0001E0   3F 40 40 3F 40 3F 40 3F 40 3F 40 40 40 3F 40 3F
0001F0   40 3F 40 3F 40 40 3F 40 3F 40 3F 40 3F 40 3F 40


See that the range (between the biggest and smallest transition) is just two DC clock periods. And if you remove a handful of transitions, then the range is just a single period! But as you know, the DC frequency is twice the one of the FDC. So this means, that the FDC will virtually see no speed variations at all on this block.

Now, if you want to write transitions exactly on the border of the window, you have no guarantee that they will read back indeed on the border. Let's forget for the moment the imprecision of the writing channel (that even an industrial duplicator has), and let's also forget the magnetic aspects. Let's assume that the transition was indeed recorded exactly on the border:

So let's say you have one transition at 5 microseconds (window border). At a constant rotation speed, and for the mentioned reasons, a specific drive might always read back that transition a few nanoseconds earlier. As long as this "earlier" is bigger than instantaneous rotation speed variation, it will always fall on the same side of the window. And you won't have any weak bits effect.

Add to this that something similar might occur on the write channel. And then what you wanted to recorded exactly on the border, might be not so exactly.

So the only way to make sure your transitions are really close enough to the window border, is by not using a constant transition period.

ppera

Postby ppera » Sat Dec 02, 2006 1:19 pm

ijor wrote:But I don't want just a TOS switcher. I want much more. I want to be able to patch the ROM and use patched TOS (or even my own OS). And I want to be able to this as much times as I want and easily (means, not burning EPROMS for every change)..


Solution could be usage of FLASH EPROM instead EPROM. And there is space for more TOS in machine at once.
2 x 2Mbit Flash chip have place for 2 TOS versions. Switch is easy - just change highest adress lines on both chip. And it has big advance: if user screws one TOS, and machine will not boot, there is other half to fix problem...

In case of having 1Mbit chips same thing can be solved with 4 chips, but it needs some logic for addressing, what is required in any case if want to put TOS 2.06 in ST(FM).

P.S. actually, additional logic will be needed in any case, I think. Because glue will generate bus error in case of write in ROM address area (when programm Flash).

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Wed Dec 20, 2006 8:23 pm

ijor wrote:All the following quoted paragraphs from your article are wrong, at least partially.

Each Sector is composed of blocks:
Gaps (GAP 1, GAP1a, GAP2, GAP3a, GAP3b, GAP4, GAP5),

I have a created a full documentation on FD that includes the GAPS description and I did not realize that no description was given here ... but anyway if the way people identify GAPS and the naming convention are often different they should all endup with the same (thing they better do):
GAP1 is the post index GAP
GAP1a is the post IAM GAP (only for PC formated diskette)
GAP2 is pre ID GAP
GAP3 is Post ID GAP (not very often use, the decomposition into two "subgaps" allow a finer description of the track. Here it is decomposed in GAP3a - Post ID and GAP3b Pre Data GAP. But if someone does not like it, it is easy to make GAP3 = GAP3a + Gap3b)
GAP4 is Post DATA GAP
GAP5 is Pre Index Gap (in practice can't really be distinguished from last GAP4)
I will add a detail description in the next version.

- Example: Dungeon Master (FTL Inc.) sector track 0, sector 247 replace the sector 8
- Duplication: Easy by software.
Yes duplicating diskette with "out of sequence" sector ID should be no problem? But may be you though that I meant that DM was easy to reproduce???

Sector with no Data Address Mark
Example: X-out (Rainbow art games)
I have no idea about this game - I probably have msinterpreted this:
ijor wrote:The problem is how the sectors and headers are arranged. This track has two sector headers right after the other. Note that the headers themselves, and not the sectors, are too close (otherwise it wouldn’t be a problem). This is fooling the analysis performed by the imaging tool.
Will remove it for next version.

Sector passing over Index Pulse
Duplication: As mentioned such a track cannot be created by the FDC as a result it is necessary to use special hardware (analog or digital copiers)
Any Write command is terminated by reaching the index and therefore yes such track can't be reproduce by wd1772 (but of course read works as not terminated by index pulse)

...Rob Northen in the so called Copylock protection mechanism... Note that the sector also contains fuzzy bits.
Yes may be not known but well described in my document. Copylock stay within data capture range of the DPLL and would therefore result in perfect reading of the sector. However extra fun was added by Rob in having ONE fuzzy bit in the sector that results in random read. :lol:


You seem to miss two very popular protections. Intra-sector variable bitrate, and inter-track variable bit-rate

Intra sector vriable bit rate is in fact described at the end of the "bit rate/timing violation". Originally I had it at the end of the long/short sector. I guess I should probably have a separate paragraph for it. Do you know of games that uses it?

I did not know about the inter-track variable bit rate. 8O
I know about what I call the "track timing layout" which consist in using different number of bytes for the same gaps in different position of a track resulting in a unique signature for the lenght of each "part" of a track.

Can you elaborate how inter-track variable bit-rate is used? Would it be that you write gap with bits at faster or slower rate? For what result? shorter longer gap? Would not be easier in that case to just add/remove few bytes in gaps as I describe above to change signature?
Realy like to here about games that uses that protection.


Side note: I have a problem with the forum. I used to receive notification each time a new message arrived in one of the trhead I was participating to. But currently it works one time out of ten ? :evil: I need therefore to manually check all the threads and I am discovering a lot of new post I was not aware. Anybody from the forum can let me know what am doing wrong and why it has changed ? I alway check the "notify me when a reply is posted" ....

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Wed Dec 20, 2006 9:10 pm

ijor wrote:
DrCoolZic wrote:Sorry but I do not see your point? Small disturbance in rotation speed results in "marginal transition" falling into one or the other of the inspection window.
No, it might be not. Depending on the drive (and other minor factors) instantaneous speed variation might be too small. So if the transition that you intended to record exactly on the border of the window, might always fall on the same side of the window.
...
Now, if you want to write transitions exactly on the border of the window, you have no guarantee that they will read back indeed on the border.
....
So let's say you have one transition at 5 microseconds (window border). At a constant rotation speed, and for the mentioned reasons, a specific drive might always read back that transition a few nanoseconds earlier. As long as this "earlier" is bigger than instantaneous rotation speed variation, it will always fall on the same side of the window. And you won't have any weak bits effect.
...


What you says sound very reasonable and I would not have known what to answer few weeks ago ... but this was before I read, analyzed in great detail, coded in C (for my program), and coded in VHDL the DPLL used in the WD1772 as described by the patent.
The patent is complex and bit cryptic but once you fully understand it it is a beauty.
To answer all your questions you need to understand the "phase correction" used in the DPLL. I can't enter in too much detail here but I can't either just tell you to read the patent. Therefore I'll try my best shot at an easy explanation:
First lets get rid of the problem of the drive speed. Assume you have a drive with 0% fluctuation but a not perfect rotation speed. The "frequency correction" circuit will quickly adjust the DPLL clock so that it compensate perfectly the "deviant" rotation speed.
Now that we have solved the problem of frequency lets see what is hapening with the latching of the data.
The "phase correction" circuit of the DPLL is responsible to center exactly the "inspection window" with the data stream transitions. This is done by checking if a data transition is before or after the border of the inspection window. If it is before it pushes the window in the right direction and if it is after it pushes it in the other direction.
Therefore if we take your assumption of a perfect transition every 5µs and uses a drive with 0% fluctuation the bit will be alternatively latched as one and zero. This is because one time the transition will be for example before the begining of the inspection window (resulting in a zero) and the DPLL phase correction will push the window resulting in the next transition being after the begining of the inspection window (resulting in a one) ... and so on ...
You may argue that due to the chanel, blablabla ... the transition is always slightly on the same side of the inspection? No because again mister "phase correction" will perfectly center the things for you.

Actually if you look at the patent for DM it describes a possible way to create fuzzy bits by using a "sliding pattern" but if you look at the actual DM disk it is not actually implemented like that and the bits are positioned exactly (with the precision of analog components) at the border of the window.
And this is acually pretty smart they have used the behavior of the WD1772 DPLL to implement a very smart protection much simpler that the "sliding pattern". Note that the patent is not on the way to produce fuzzy bits (although they give some examples) but on the concept of fuzzy bits.

I would like to have more time and try to simulate the VHDL model with the actual data read from the DC but this is probably a dream, but the actual implementation in my "analyze" program gives results very close to what I can read on my Atari...

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Thu Dec 21, 2006 1:27 am

Hi DrCoolZic,

You don't seem to be a bad guy, quite the contrary. But you seem to have a tendency to talk about things you don't know and/or you didn't check.

There is nothing wrong talking about something without being certain, we all do it. It is also human to make mistakes, we all make them. And we certainly don't double-check everything we say. Otherwise, we'll all be checking things all the time and we won't ever speak, not really useful for anybody.

But when somebody argue with us, and just as a matter of respect for the other, most of us will double-check it before arguing again. If I say it is white, and you say that no, it is black; then I will double check it is indeed white. Even when I was quite sure I was right from the start, I will check it once more. And again, it is a matter of respect for the other.

Otherwise, and when for some reason we cannot check it, most of us will reply something along the line of "I was sure, but I need to check it again … I think … it seems … at least, this is correct on my system …" etc. Again, just as a matter of respect for the other.

Lastly, when other argues with us, most of us would give things a second thought. We do it just in case the other was right, and again, as a matter of respect for the other.

But you obviously didn't check what you were saying, you just keep arguing. Some things don't even need to be checked, just thinking about it twice would be enough to realize about the mistake (e.g., creating a sector with sector number 247). Other times you argue without reading what the other said, and then your answer is irrelevant to what the other said in the first place. Other times you might have checked it, but you wrongly assume that what you have found in your case (the behavior of a couple of disks in one drive, may be two) is universal.

So if you are happy believing that all what you say is correct, then please be my guest.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Thu Dec 21, 2006 3:33 pm

ijor wrote:Hi DrCoolZic,
You don't seem to be a bad guy, quite the contrary. But you seem to have a tendency to talk about things you don't know and/or you didn't check.
Hi Ijor,
Thanks for the compliment; you also seem to be a nice and smart guy. It is true that I like to learn about things that I do not know or did not have time to check. I therefore make mistakes but I always enjoy learning from others. I know that a proverb says "turn your tongue in your mouth seven times before you talk" but personally I like to be more spontaneous.

But when somebody argue with us, and just as a matter of respect for the other, most of us will double-check it before arguing again. If I say it is white, and you say that no, it is black; then I will double check it is indeed white. Even when I was quite sure I was right from the start, I will check it once more. And again, it is a matter of respect for the other.
...
Lastly, when other argues with us, most of us would give things a second thought. We do it just in case the other was right, and again, as a matter of respect for the other.
Actually I really do not understand why you tell me that? I definitively like to argue but I believe that I profoundly respect others and particularly you.
What did I said that justify such anger from you? In most case I did not denied or even argue with what you were saying despite the fact that it was not obvious to guess what was wrong in the quoted text. For example when you say without further explanation:
All the following quoted paragraphs from your article are wrong, at least partially.
- Example: Dungeon Master (FTL Inc.) sector track 0, sector 247 replace the sector 8
- Duplication: Easy by software.
Is it the fact that sector 247 replaces sector 8 that you don't like? or is there a problem with number 247 for an ID? or is it the fact that DM is difficult to copy? As writing a sector with ID value of 247 did not look any special, I figured out that you meant DM was difficult to duplicate.
But based on your last reply it does seem that indeed sector 247 is what is bothering you. Therefore I gave a second thought by reading the WD1772 DS just another time. I still could not understand why writing a value of 247 in an ID field may be a problem. Therefore I gave a third thought by reading a chapter on formatting in a book dedicated to FD on Atari. But I still could not understand what is the problem and therefore I would be interested to learn why it is seems obvious that we cannot write a sector with an ID of 247 (this shows that what is obvious for someone might not be for somebody else)?!? The obvious next step would be to actually try it but unfortunately I have not yet found a program that allows full control of the write track buffer.
But certainly the most cryptic quote was
...Rob Northen in the so called Copylock protection mechanism... Note that the sector also contains fuzzy bits.
??? At first I could not guess what you did not like in this sentence. After second thought I figured that you may contest the fact that the sector contained fuzzy bits and provided information that seems to indicate that on the few disks I have tested it seems that indeed the sector has fuzzy bits. But now based on your feedback I am not sure anymore? I thought it was a known fact that Copylock sector had fuzzy bits but I may be wrong?

Other times you might have checked it, but you wrongly assume that what you have found in your case (the behavior of a couple of disks in one drive, may be two) is universal.
The process I follow is: first I collect background information, second I experiment, and third I try to extract rules from my experiments. But, as you mention, I know that it is dangerous to generalize discovery done on few test cases, and this why I usually seek for feedback from others so that we can confront our results. It is true that until somebody, or me, presents some contradictory results I present it as a possible universal rule. But again if I describe it precisely in a document, publish it, and seek for feedback it is to provide the opportunity to others to contest the discovery.

So if you are happy believing that all what you say is correct, then please be my guest.
As I have explained above it is the entire contrary. I joined this forum and created this thread and document because I believe in cooperative work. If I knew everything, was sure of everything, and wrote only correct thing I would be God and not waste my time arguing with others.
I am extremely interested in understanding the FD protection mechanisms used in the Atari and, as I like to document what I learn, I have decided to write a document that might be of interest for people that share the same interest. I would perfectly understand that, due to the fact that you already know everything on the subject, you are not interested in loosing time with this document/thread but I would be sorry. I personally believe that sharing (especially knowledge) is an enjoyable activity and I feel sad that we cannot better communicate.

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Thu Dec 21, 2006 9:21 pm

DrCoolZic wrote:It is true that I like to learn about things that I do not know or did not have time to check...I know that a proverb says "turn your tongue in your mouth seven times before you talk" but personally I like to be more spontaneous.


There is nothing wrong about that. But as I said, it is not correct to keep arguing and debating without checking.

Actually I really do not understand why you tell me that? I definitively like to argue but I believe that I profoundly respect others and particularly you.


I didn't mean you intentionally was not respecting me. I am sure you didn't mean any harm.

In most case I did not denied or even argue with what you were saying...


If you read your post again, you will see that you definitely were. And again, there is of course nothing wrong in arguing (disregarding who is right and who is wrong).

despite the fact that it was not obvious to guess what was wrong in the quoted text. For example when you say without further explanation:


It might have been not obvious. I just thought it would be, and I was lazy to elaborate.


But I still could not understand what is the problem and therefore I would be interested to learn why it is seems obvious that we cannot write a sector with an ID of 247 (this shows that what is obvious for someone might not be for somebody else)?!? The obvious next step would be to actually try it but unfortunately I have not yet found a program that allows full control of the write track buffer.


You don't need a specialized tool. Any format tool that you can somehow (debugger, source, etc) alter the buffer manually, changing the sector IDs would be enough.

But I have an easier way for you: Try copying the disk with a software copier (A-Copy or Procopy). Forget of course about the sector with weak bits. See what happened to "your" sector. Then, when you are convinced something is wrong, read the WD data-sheet again. There is a small nice table in the Format section of the datasheet (can't give page number because they vary) that should reveal the mistery :)

Yes may be not known...

I thought it was a known fact that Copylock sector had fuzzy bits but I may be wrong?


You seem to contradict yourself. Before you said it was (possibly) not known at all. You now say you thought this was a known fact.

Check exactly where the weak/fuzzy bit is. Think how the Duplicator hardware created the variable bit-rate. This bit is sometimes weak but not by design, sometimes it is not. It varies in different copies of the same disk. And also with the same disk on different drives.

I would perfectly understand that, due to the fact that you already know everything on the subject, you are not interested in loosing time with this document/thread but I would be sorry.


I certainly don't know everything about protections. As a matter of fact, I'm sure you investigated some issues more than I did. Pasti doesn't need, and hence the tools don't have a comprehensive knowledge about all possible protections and combinations. The tools just have a generic knowledge that let them (hopefully) deal with all the protections.

And I obviously took the time to read your document, didn't i?

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Fri Dec 22, 2006 3:27 pm

ijor wrote:
But I still could not understand what is the problem ... write a sector with an ID of 247 (this shows that what is obvious for someone might not be for somebody else)?!? ...

.... There is a small nice table in the Format section of the datasheet (can't give page number because they vary) that should reveal the mistery :)

Ok I solved this enigma! And yes it was easy specially with the hint you gave: 247 = $F7!
I have modified the documentation accordingly and added a new protection mechanism: invalid sector address (245-247)

Open issues: I still do not understand what you do not like in
...Rob Northen in the so called Copylock protection mechanism... Note that the sector also contains fuzzy bits.
as we seems to agree that copylock contains fuzzy bits? But again I may miss an obvious point?

Can you please elaborate on sector passing over the index pulse. As I mentioned the documentation says that the write track command start with an index pulse and terminate with the next index pulse. I therefore assumed it was not possible to write a sector that crosses the index pulse.

And I obviously took the time to read your document, didn't i?
Yes I see and thank you.

Based on your feedback I have generated a new version that includes: a new section that explain the notation I use for GAP so it should be more clear, and 2 new protection mechanisms: invalid sector and intra-sector variable bit-rate. Also clarified the track timing layout pattern.
It is easy to find what has changed: Vertical bar on the left, new text in red and indication of deleted text. So people do not need to read full text again.

I would also be interested in getting example of games with intra-sector varaible bit-rate and explanation and example for inter-sector variable bit rate.
You do not have the required permissions to view the files attached to this post.

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Fri Dec 22, 2006 8:49 pm

DrCoolZic wrote:I have modified the documentation accordingly and added a new protection mechanism: invalid sector address (245-247)


It is not just about the sector ID. There is actually a whole "family" of protection based on the same concept that some bytes can't be written at format time. For example, suppose any of those bytes are placed in a Gap.

Btw, if you want to be picky, you can say that a sector $F7 can be created. But not that sector as in DM.

...Rob Northen in the so called Copylock protection mechanism... Note that the sector also contains fuzzy bits.
as we seems to agree that copylock contains fuzzy bits?


Hmm, no, we don't agree. Please read again what I said about that.

Can you please elaborate on sector passing over the index pulse.


From your previous post:
Any Write command is terminated by reaching the index ...


From your last post:
As I mentioned the documentation says that the write track command ...


You changed your wording (as the bolding shows). So it seems you realized how that sector could be created, don't you? :)

I would also be interested in getting example of games with intra-sector varaible bit-rate and explanation and example for inter-sector variable bit rate.


I'm not sure we are using the same terminology, so may be we are talking about different thing. Intra-sector is used in the protection known as Speedlock.

Inter-sector is, of course, CopyLock. CopyLock has also an intra-sector variable bit-rate, but the program doesn't check that. It checks the different average bit-rates between two different sectors.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Sun Dec 31, 2006 3:35 pm

ijor wrote:You changed your wording (as the bolding shows). So it seems you realized how that sector could be created, don't you? :)

Why the riddles? Why not just explain in full without leading him to the solution or getting him to read back to previous messages? It's very patronising.

DrCoolZic: The sector can span the index pulse by formatting the track with the header placed close to the end of the track, then performing a separate write to the data field of that sector. Of course, you can't put sectors too close to the start of the track or it'll be overwritten by that late write.

Was that so hard? ;-)

ijor
Hardware Guru
Hardware Guru
Posts: 3165
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Sun Dec 31, 2006 4:22 pm

obo wrote:Why the riddles? Why not just explain in full without leading him to the solution or getting him to read back to previous messages?


You are right, I should have given a plain detailed answer.

But the whole story didn't start with a plain question. It started by me pointing about some mistakes in his article. As I said, I assumed that the errors were obvious and that he wouldn't need a detailed explanation. I also expected, that if he wouldn't understand something, he would ask.

But he didn't ask, he just kept claiming he was right and I was wrong. Again, the right thing to do would have been to give a detailed explanation at that point. But I got tired of that attitude of him, which was almost a constant in threads that we were both involved. In many cases I needed to repeat things twice, three or even more times until he realized/acked he was wrong.

So I reacted humanly, a bit angry a bit tired. OTHO, it seems it was needed. Because it was only then when he reacted and started giving things a second thought.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Postby DrCoolZic » Sun Dec 31, 2006 5:46 pm

obo wrote:DrCoolZic: The sector can span the index pulse by formatting the track with the header placed close to the end of the track, then performing a separate write to the data field of that sector. Of course, you can't put sectors too close to the start of the track or it'll be overwritten by that late write.
Was that so hard? ;-)
Thanks for all you said obo.
I did figure it out about the writing over index (as you said the riddle was not so hard) but I am tired of the way the conversation is evolving and consequently I will probably not continue to publish anymore on this thread ?
But, nevertheless I will continue to collect information, perform test on the subject and update my document accordingly (at least for me). Obviously it would have been easier to get help but I know that not all people like to share their knowledge.

Anyway I am not sure that the subject is of much interest to many people... but at least during the learning process I have been able to help Wolfgang Foerster who is writing a VHDL model of an Atari ST/STE (Suska Project) and he has modified his latest version (2K7B not yet published - my initial are jlg) of the WD1772 DPLL model based on my feedback...

As I have colected many many games, I should hopefully be able to do more findings, by using the analysis program I wrote. It will just take more time without information and there is a bigger risk to misinterpret some results... Beyond just understanding the protection mechanisms, I have started to write a "protection analyser" program that should also generate automatically a "Discovery Cartridge control file" to help in copying Atari diskettes...

Will see how things moves ... next year ...
Jean


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest