ijor

Sounds right. It also makes sense. Didn't Trip Hawkins complain bitterly about copying and Omnimon-type mods? EA might have put some protection in there. 845822[/snapback] All (or at least most) EA programs have a protection check against Omnimon. It is performed early during the boot stage. If you run the original MULE, for example, with Omnimon active, you get a message “REMOVE CUSTOM O.S”. But this doesn’t look like being related to Omnimon. The code checks for RAM at $C000, and nothing is done if there is no RAM. It seems to be a break into a custom monitor/debugger. This is typical in many games. The monitor code was obviously removed for production release, but for some reason the entry point was left. And the message might be some sort of Eastern Egg for the beta testers perhaps (where the monitor was still there)?

WoW !!! Could you provide more details please. Which files are missing? What you mean they were "too spurious"? In which form the original source disks were (hard disk, floppies, dat)?

Nowadays, probably the best cracking tools are the debuggers included with the emulators. You can do lot of things that are impossible in a real machine (even if you were using a hardware debugger).

Bad sector is sometimes used as a generic term (sector with any kind of error). And sometimes it is used for a specific type of error (Sector Not Found). Weak bits is a very special protection, it is known also as fuzzy, phanton, wondering, flakey, and some more terms I don't remember. Weak bits is my prefered term, but feel free to use whichever one you like. It consists on bits that change every time you read them. So each time you read a sector with weak bits, you get different data. Yes, there are some copiers that hack the program instead of actually copying the protection (because they usually can't really "copy" the disk).

Most copy protected disks (which means most games) can't be copied by any ST software (nibbler) copier. Software copiers can copy earlier US releases and some european ones. But most protections simply can't be reproduced without extra hardware.

Not that I really care if they did, but it makes no sense to me. The 800 was so well documented, and had so many patents, that reverse engineering makes no sense at all. The only reasonable purpose could be to make a perfect clone (or nowadays, a perfect emulator), but this is obviously not the case here. Of course, and as many pointed out already, I’m sure they borrowed some ideas and some concepts. This is natural and doesn’t require any reverse engineering. Furthermore, those days hardware reverse engineering was extremely expensive and difficult. Not a smart idea for saving money or time.

How do you know that this was probably the reason? How do you know it wasn’t something else? Hmm, you said before it “usually fails”, now you say it fail always … Let’s talk numbers: What is the precision of the CopyLock density? What precision an analog copier achieves? What precision can you measure using your tools? What precision the CopyLock software expects? And what is more important. Explain why an analog copier will fail at all to reproduce a “cell density” precisely enough? LOL. Your own "expert" acknowledged that “weak bits” intentionally produced are usually not “as you define them”. But this doesn’t matter. How many Amiga games with flakey bits (I will use your own terminology to avoid confusion) were produced “as you define them”, and not by “causing a similar effect”? How do you know at all which “type” of flakey bits are present in a specific disk? The only reliable way is by reading at the flux transition level. But you already acknowledged you don’t. I would like to know which game has flakey bits that they don’t change anymore when copied by an analog copier? And don’t answer me with a game that an analog copier can’t copy, this is not the point. The point is if the flakey bits are not flakey anymore and the program fails for that reason (and not for other reason). And are you saying that the Cyclone can’t copy any disk with flakey bits at all? An analog copier can perfectly reproduce flakey bits. There are plenty of ST, PC, and Atari 8-bit examples. Want me to list games that an analog copier can perfectly copy? And again, explain from the theory why an analog copier won’t copy flakey bits?

That’s precisely the point. Analog copiers do NOT transfer any data to RAM. And that’s why they are called “analog copiers”. It might be unusual or not, but that’s what we were talking about here, about the degradation of copies made with an analog copier. And no, an analog copier doesn't work exactly as you describe. It is not an analog copy at the voltage/flux level. The signal is digital TTL, otherwise you'd indeed require a very specialized equipment. It is analog at the waveform level.

The Discovery Cartridge has almost no relation to the Happy 1050 (or 810) enhancements. The same company produced them all, and, if you want, they have the same purpose (copy copy-protected disks). But that’s all they have in common. They are technically completely different. The Discovery Cartridge is far much more powerful. Up to now I consider it to be, by far, the best hardware copier ever made for a personal computer. The newer version of the Catweasel (MK4), a PCI card, will probably match it or at least come very close. Hey, but the DC was produced ~18 years ago ! Edit: MK5 was a typo. Corrected to MK4

Atari drives use a standard controller at a standard clock, so it uses standard bit-rates. It is 125 Kbps for FM (single density), and 250 Kbps for MFM (double and enhanced densities). Note that all densities actually have the same transition rate. Only the different encoding results in a different data rate. As somebody point out, the bit-rate only makes sense when matched with the same drive RPM. Put an Atari disk in a “standard” drive rotating at 300 RPM (instead of 288 RPM), and the bit-rate is altered. Some copy protections have a slightly different (usually slower) bit-rate. Hmm, I don’t see what’s the relation with this and using 288 RPM. The reason is probably something different. It is again the small sector size of 128 bytes plus the lack of index hole. The small sector size requires more sectors, and then increases the overhead. So you need a bigger unformatted capacity. The lack of index hole makes formatting less precise, and then the last and first gaps must be bigger (more space is wasted). Again, this requires extra unformatted capacity, which you get by reducing the RPM.

This is the key (APE for DOS). You won't be able to use this trick with the Windows version. What's happening is that the driver for the USB adapter is creating a virtual serial port. APE "thinks" he is talking to the hardware, but instead the driver redirects the input/output to the USB. The whole virtualization process is usually slow. Interesting it still works. Did you try using Warp speed? Any other USB devices on the USB bus were active?

Do you have the older Option Board or the DOB (Deluxe Option Board)? I don’t know about the older OB, but the DOB works with computers much faster than a 286. It won’t work with a Pentium IV, but it does with a 386, 486 and might work even with some Pentium I. Actually, the hardware works at the fastest computer. It’s the software that fails. It might be possible to use it with those programs that simulate a slower CPU. Of course, you still need an ISA slot. The hardware is capable to copy almost anything the Option Board can, plus much more. But AFAIK, there is no software released for copy protected disks. For years I used the Catweasel to copy protected disks … with my own software. Specific versions for Atari 8-bit and ST will be released shortly. You probably would be able to use the ST version for PC DD disks. Btw, if anybody here has a Catweasel and a considerable amount of Atari copy protected disks, please leave me a message. I would be interested in beta testers.

No, no fabrico nada. Si, ya se que muchos equipos dicen fabricados en San Luis. La respuesta esta en lo que se llamo "La Promocion Industrial". No se tu edad, si eras muy joven y no sabes lo que fue la Promocion Industrial preguntale a tu viejo. Ahi vas a entender la verdad de la milanesa.

Re: analog copiers You are wrong Fiath. Analog copiers easily can reproduce the variable bit rate of ST Copylock (and probably the Amiga version as well). The reason that it usually fails is because the software can easily identify a copy made with an analog copier, but NOT because of the bit-rate (density). Some earlier Copylocked programs don’t have this check and then the program runs fine. Most later ones added this extra check and then they fail. Weak bits is a more or less common protection in US releases (but not the most popular). It is rarer on euro releases. Most euro protections are based on bit-rate variations. The reasons that checking the copy protection sometimes seems to be slow are several. Most european protections are encrypted with the Copylock packer. At runtime, the decryption is done by tracing each CPU instruction. Each instruction is individually decrypted at the exception handler and the previous one is re-encrypted. This obviously is very slow. Some protections are run in seudo-code using a custom interpreter. This is also slow. As you said some protections need to be retried to be confirmed, but not many times, usually only twice. Reading the inter-sector data requires many passes when is done by a copier that doesn’t know what and where the protection is. The protection itself usually don’t need many attempts. Fiath is correct here. The degradation of the signal when using an analog copier is true. The data on a floppy might be digital, as is indeed the case of unprotected disk and even on many protections. But this is not the point. The point is that you are using an analog process. Multi-generation copies made with an analog copier fail faster than you think. And is also true that floppies recorded with an analog copier has more chances to develop data corruption, mainly because no pre-compensation is performed. However all the problems associated with an analog copier disappear if you use a hardware digital copier such as the Discovery Cartridge, Catweasel, Copy II PC Option board, etc. This “emulation” would work only in naive implementations of the protection. The protection can easily check if there aren’t multiple (dup) sectors, it can verify that all the rest of the sectors are full and present. And it can sync the reading of the weak sector to make sure he is always reading the same physical sector. There are indeed some naive implementations that allow this kind of emulation. And sometimes software copiers can make a working copy of a disk with weak bits. Most of the cases the protection is smarter and there is nothing you can do with a software copier (except cracking). Protections actually based on double/duplicate sectors are very rare on the ST. The main reason is that this protection can easily be copied with a software copier. I recall only some earlier US titles and some french ones. It is possible to combine double sectors with other variation, and then make a protection that you can’t copy with software. This was very popular in the 8-bit. But I don’t recall to see this on the ST, probably because it doesn’t make much sense in the ST as in the 8-bit. The probable reason why you don’t recall weak-bits too much is, because as said above, it is more common in US than in Euro releases. But it is not as common as Fiath believes either. Not everything that looks “weak” is actually a weak-bits protection.

The cartridge doesn’t have any built-in ROM. Depending on the “option” model it includes sockets for ROMS. In theory you could put any ROM. But it was explicitly designed for MAC ROMs and I'm no sure if you could use anything else. As I recall, the initial design was for 64k Mac Roms. I think you need a mod for 128k Roms and later versions of the software include documentation on how to do that. Happy Computeers didn’t copy the Magic Sac. But with the DC and Mac Roms, you could easily use pirated copies of the Magic Sac. With the additional benefit that the DC could read/write native MAC disks and the Magic Sac couldn’t. That was the reason of the conflict with Small. He later developed the GCR for accessing MAC disks. I think you can still use the DC with a pirated copy of the GCR “software”, but you can’t access MAC disk with the emulator as you can with the GCR. You must convert them outside the emulator.

It is possible to make a SIO2PC for the ST, but there are some complications. It is not too difficult. I’d say that emulating the MFM signal is even easier than emulating the SIO protocol. The main problem is the speed. SIO works at 19,200 bps, or at maximum around 57,600 with a SIO2PC cable. But the MFM signal has a 250,000 bps, and you can’t use the serial port for the serialization because the signal is not async. A standard parallel port doesn’t work that fast. And even if it would, you can’t afford that rate under a multitasking OS. So you have to use an external device, which could be inside the ST if you want, or even a custom PCI card. It would probably be micro-controller based it could possible done with a FPGA. You would need quite some memory though, because contrary to SIO, the ST computer will not wait and you can’t afford any interrupt/CPU latency. The amount of memory would depend on how intelligent the device would be (a dumber device will need the MFM encoding/decoding done at the PC). And it would also depend if you want to “emulate” standard disks only or you also want copy protected ones. As somebody said, you will need a minimum hardware mod in the ST to disable the internal drive. Only earlier ST models without an internal drive could use a plug-in solution. My guess is that eventually we’ll see something like this. Eventually all floppy drives will stop working and won’t be manufactured anymore. But computers will probably last longer, and could also be cloned. Then everybody will want a floppy drive emulator.

I will be very interested if you can remember the game. I’m not actually interested in the game. What I want to know is the year that this protection was released. The reason is that a very similar technique is used in most 16-bit protections (Atari ST and Amiga). And just out of curiosity, I want to know if that c-64 protection was earlier or not. Doing brute force disassembling might be unfeasible for some protections. Try to follow Synapse ones, they take ages to reach the protection (disk stop for about half a minute) running seudo-code. You don’t necessarily need a freezer, but it is certainly helpful. I never actually had a “freezer”, but manytimes I used Omnimon for a similar result.

No. Alternate Data marks (not address marks) is just one of the protections. Btw, you can only detect two types of data marks on the Atari, and you can’t detect any variation on the address mark. Yes, and I believe that it was used to write some protections for Atari. But most 1050 enhancements (probably all besides the USD) give you full control of the FDC as well. That’s the reasons that later protections used more advanced techniques, where direct control of the FDC doesn’t help. Actually, “Bad/deleted Data mark” (that’s how they were usually called in the 8-bit) is not a very popular protection on the A8. Probably because is one of the easiest to handle for devices like the Happy.

Well, I’m a bit late here. And in the meantime I had some email exchange with Nir, so he already knows the answer. But for others that might be interested … I can copy the Super Archiver disk. I can copy it with either the Discovery Cartridge for the ST or the Catweasel for the PC. Contrary to what is written in some FAQs, I don’t believe the protection was created using a non-Atari drive. It seems it was written with the SA hardware itself. Probably with a custom version of the firmware. The software for copying and imaging this disk will be released. They will be part of the tools for handling 8-bit copy protected disks that I announced in the newsgroup some time ago. In the meantime, if somebody has an urgent need to copy this disk, send me a message. But I understand it was already cracked …