X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Ari Lukumies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp Subject: Re: Creating a copy protected floppy References: <1121199731 DOT 361001 DOT 326030 AT g43g2000cwa DOT googlegroups DOT com> <1121251420 DOT 008623 DOT 117040 AT f14g2000cwb DOT googlegroups DOT com> <1121304613 DOT 063822 DOT 249190 AT g14g2000cwa DOT googlegroups DOT com> <42d68df0$1_2 AT spool9-west DOT superfeed DOT net> <42d6a361$1_2 AT spool9-west DOT superfeed DOT net> In-Reply-To: <42d6a361$1_2@spool9-west.superfeed.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 172 Message-ID: Date: Fri, 15 Jul 2005 03:53:36 +0300 NNTP-Posting-Host: 81.175.144.229 X-Complaints-To: newsmaster AT saunalahti DOT com X-Trace: reader1.news.jippii.net 1121389175 81.175.144.229 (Fri, 15 Jul 2005 03:59:35 EEST) NNTP-Posting-Date: Fri, 15 Jul 2005 03:59:35 EEST Organization: Saunalahti Customer To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hello wrote: > "Ari Lukumies" > >>IMNSHO, this is more caused by the drive's rw-heads capabilities and speed >>tolerances. > > Out of spec floppies are always a problem, of course. (That's one of the > reasons copy protected floppies are such a pita.) > But even allowing for that, there are issues, since the floppy controller in > the standard PC is so unforgiving. > A too short index hole gap was a very common problem. Infamous, really. > The PC controller just couldn't always handle it, even if the floppy was in > spec. In these sentences, you did not once mentioned the physics of the hardware (drive, if you'd prefer). Do you know, there are also physics involved? Other than the floppies themselves? A controller is just one piece having to do with electricity dealing with hardware, it is not /the/ hardware. A 'too short index hole gap' is an aspect that can be dealt with either the hardware or the controler (althoug, as you say, it shouldn't always be). >>Later, IBM introduced the 1.2MB floppy disk. It had even more problems, >>since it used narrower rw-heads than the previous 360kB > > Yup. But often, the problems were still things such as too short gaps, etc. But most often, this was caused by the /hardware/, gaps could still be programmed to a proper length, taken the /hardware/ into account. > Things that were within official specs, but just not quite what some PC > floppy controllers expected. > Or just barely under the official specs. They'd work fine in other > controllers, but not the ones in most PC's. Here, you failed to mention the tolerances I talked about (-4% to +4% for the head positioning, that's a fact for this tolerance, the speed tolerance percentages I do not recall after so many years of engineering and maintaining the drives). Not that the tolerances were necessarily met by custom manufacturers, I admit. >>BTW, this goes for hard disks, also: if you use one in one computer and >>move it to another, it may require reformatting before being usable (or >>reliably stabile, at least). > > Not for IDE drives. The IDE drives have the controllers built into the > drives. They have an internal clock, but that's scaled when you warm the IDE disk for about 40 minutes before the first installation. Afterwards, the speed of the input from the system where you use the drive does matter to timing of the data transfer to/from the disk subsystem, and for high-speed disks, that speed gap may either work or render your disk unusable, unless you reformat it in another system. > The only case where you might have problem is in the older mid 90's > computers that used several of the early methods to get past the 8g (and > various other, smaller sizes) size limitations. What I said above goes even more for nowadays' greater capacity and speed SATA and PATA disks; the SCSI ones are one different branch altogether, with their own control mechanism, and thus do not apply here. A slight change of temperature, even, may render your new hard disk unusable. > Eventually, computers standardized on a single LBA mode, but there for a > while, taking a hard drive from one computer to another was a gamble. The disks geometry was using LBA-style addressing long before anybody knew MS-DOS existed. The term for most of the people (like you, apparently) surfaced when Winchester/IBM standard 1024-track system came to its end and people needed more storage capacity for their home use; the small-systems (PC) disk manufacturers took it in and started marketing it, with the help of the BIOS manufacturers (thank god). > But that's really more of an OS problem, not a hardware problem. If you do not have hardware to support post-1024 tracks, how do you make software make use of it? (NB: software here means both the OS support and the BIOS support; some geeks use pure FDC to access the tracks, but how many of those made it to the market?) > There are thermal tolerances and so on that can cause a hard drive to have > problems. But that's not dependant on any particular computer etc. And it > wont effect taking an IDE drive to another computer. Ok, build me a computer with a hard drive that works from, say, minus 40 degrees of Celcius to, say, plus 35 degrees Celcius without cooling or heating (yes, here in Finland, we do have that much of temperature variation). Whether this will have an effect on another computer is not the question, the question is that, it /is/ dependant on a particular computer, whether the thermal tolerances matter or not. Or do you disagree? > Older mfm, rll, etc. drives could be picky, but those aren't exactly common > these days. Did I ever mention them? (I may now: I have a few of both, the RLL are better, but not so much supported on the older machines.) > I've written programs to feed each byte to the > controller, etc. And written programs to read each byte. To copy floppies. > (Although my copy programs were never as sophisticated as the commercial > stuff.) As you have done so, you also know what's behind it, and how it changes due to the changes of the /hardware/ related to the chips that are just a way to give commands to it? > But the standard PC controller can be unforgiving at times. If the gap is > just a byte too short, the floppy becomes unreliable. It may work fine in > one system and totally fail in others. That's what I started my post with. Now you finally accept it. > And the gap after the index hole is infamous for causing problems. That's > one you dare not shorten. Have you often came across a situation where it caused a problem? Once? Twice? I bet, not 'regularly'. > Modern PC's *may* be a bit more reliable with the floppy, but I wouldn't bet > on it. After all, they are designed to be completely compatbile, and that > usually means the same limitations and problems, just on the off chance some > floppy or program might depend on it. And they are such a low end, > uninteresting piece of hardware, I doubt much effort actually goes into > making them reliable, beyond the minimal they have to. Nowadays, the PC (and OS) manufacturers tend to make the floppy drives totally compatible by totally annihilating them - eventually no one will have one. So much for the trouble, here comes another one: the CD/DVD-swing! > However, you have to remember, they were written explicitly to copy the copy > protected floppies! [copying programs] > So it's not too unreasonable to assume they use every trick the authors can > think of to find out exactly how that track is done. Ranging from doing a > full "read raw track" kind of command, to reading each sector and timing the > rotation delay, to counting bits, to switching head positions (to detect a > sector (real or home made) on an otherwise unformatted track), to whatever. I suspect, the programs used even more tricks than there were in the book. I once tried to make a copy of a disk. It was perfectly legal, but somehow it got partly unreadable in sunset (didn't like to be on a windowsill I guess). I launched CopyIIPC, which to that time was the best copier I'd ever encountered (for making the one backup that was allowed by the program license, of course), and it did make a copy of that partly demolished floppy. Only, it copied the demolished parts also, so that the resulting floppy also was partly demolished. That's what I call software engineering. :) > The point was, though, that if somebody does try to make a backup and it > doesn't work, unless they are absolute newbies or brain dead AOL'ers, they > are going to do a search to find out what's wrong. > > They aren't going to do it once and then give up. Unless the program is > uninteresting and they don't really want a copy. > > And they'll find instructions on how to go ahead and do what they want to > do. And now they'll have a few more posts to wander through. No offence, (I should be offended myself, having done so much posting), -atl- -- A multiverse is figments of its own creations