Disk copy protections

like!

Did someone already find an existing copy protection that cannot be represented by the DMK format?

Almost every single one of them should apply; that's a document for the Atari ST, which uses a member of the same family of disk controllers as the MSX. The main difference I can think of is that early members of the family leave a lot of the analogue stuff to external electronics, so different MSXs might have very different implementations of things like gain control, potentially affecting how weak a weak bit needs to be.

For the MSX? Presumably not — surely you'd already know by now if not? Somebody would have mentioned it in the context of openMSX for sure — though it'd be pretty trivial to do so, since the file format is so high level. Straight off the top of my head:

• any IDAM whatsoever that is not exactly aligned with the decoded byte stream cannot be stored, which means that 15 out of every 16 possible sector-in-sectors cannot be stored;
• different data densities cannot be stored, but can be detected by a simple timing loop;
• unformatted sections of tracks cannot be stored, but can easily be detected because they return 'random' data.

The WD1793 and WD2793 are the same chip with slightly different inputs; the MB8877A is a clone of them.

The WD33C93A is a SCSI controller so isn't used for floppy drives; the TC8566AF is an oddball, being an 8272 clone, but is used in only one TurboR such as I can make out. EDIT: I was wrong about that; it's used a little more widely than that; Panasonic preferred it from somewhere in its MSX 2 line-up onwards, and Sanyo was on board for its MSX 2+.

So the diversity isn't anywhere near as great as a recitation of part numbers would make it appear. Any piece of software you intended to launch prior to the existence of the TurboR could assume the WD1793 instruction set (give or take some slight changed in status register, and a distinction as to whether an external head load signal is used to detect spin-up versus watching the index hole go by sufficiently many times, which at a pinch you could argue was an instruction set difference?) and quirks.

Separately, and not what I originally argued but worth mentioning, 90% of the stuff in that document would fool any disk controller. Leaving a blank area so that the gain is amped up until you're reading noise, or maliciously putting a flux transition right on a window boundary so that whether it falls one way or the other depends on temperature, aerodynamics, voltage fluctuations, etc, is universal.

Ditto both the 8272* and 1770 would react in essentially the same way to things like sectors in sectors that are basically impossible to recreate on consumer drives**.

* though the 8272 would react only after much more verbose and modal programming, after performing much more vaguely-defined actions, obviously. That's the Intel bonus!

** that is, assuming you don't align the IDAM for the inner sector to a logical byte boundary of the outer sector. Otherwise you can do it directly on the 1770. But not the 8272, which is also a master of dedicating silicon to providing thorough and thoroughly-unnecessary assistance for very occasional uses. That's the Intel bonus!

sd_snatcher: As general feeling I think you are just very hard trying to misunderstand the point TomH is trying to make.

Yes, the diversity is great, but that is mostly problem of a person who is trying to access the chips directly. As MSX standard does not really allow you to do this, this is problem is pretty much limited only to the person, who is originally trying to write the protection to the disk surface... Naturally he needs to know his own setup. The tricks on disk tracks are interpreted by the chip and the result is sent to the standard layer. How the chip is connected is therefore not very relevant, how the chip internally works is what counts here.

From MSX point of view these devices are handled more like HDD than a floppy. AFAIK you can not launch even normal trackloader games from these devices, so I think there are much bigger problems than the copy protections and these should be left out of this discussion. (I must say though that I have no personal experience about the subject, so please correct my claims if I'm wrong.)

I think here is what is your "hidden agenda" behind. You are trying to say that no one should use disk based protections because they will cause gray hair to users... especially when they are not using floppies, but the definition of floppy becomes standard definition of storage format instead.

I must say that I agree with your point, but it is not a reason to start fighting against the information it self and claim that it is wrong or useless because of this. I find this very interesting especially from the history point of view although I would not recommend any developer to use these methods today anymore.

Well that is not true... If you read the article you find that ie. renumbering of sectors and using duplicate sector numbers are perfectly fine working tricks even on MSX standard disk implementation and I've even seen them used successfully in commercial MSX games. Practically you can rule out only the tricks that require "read track" to be performed. (There is no standard implementation to do this on MSX)