Disk copy protections

Page 1/2
| 2

By wernerkai

Champion (357)

wernerkai's picture

23-11-2018, 00:59

I found an excellent doc covering many types of disk copy protections.

It's for ATARI, but for sure many of these schemes apply for MSX disks.

Link for document

Login or register to post comments

By TheKid

Paladin (703)

TheKid's picture

23-11-2018, 08:24

Nice find Smile

By ro

Guardian (4012)

ro's picture

23-11-2018, 10:13

like!

By wernerkai

Champion (357)

wernerkai's picture

24-11-2018, 00:11

The author has a site with some tools to deal with Kryoflux disk images. Two called KFAnalyze and KFPanzer are made to detect the copy protections (for ATARI disks) covered in the document.

I made a SCP flux file from a plain MSX-DOS disk. Then I converted the SCP file to a RAW (Kryoflux) file with the HxC Floppy Emulator software, in order to make some tests with that tools.

As I read before doing the conversion, the conversion between the two formats may not work because the sample period of SuperCard Pro is 25nS, while for Kryoflux is 41,67 nS.

And it seems the ATARI disks spin at 360 rpm, whereas MSX disks spin at 300 rpm. So I expected not-so-good results...

The KFAnalyze program found many "protections" in the plain MSX-DOS disk I dumped.

Anyway, it's just for curiosity's sake, as now we can store any disk in flux image format for preservation purposes. Most of games sold in Brazil with copy protecions are European tape games or Japanese ROM games.

By Manuel

Ascended (14788)

Manuel's picture

24-11-2018, 09:25

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

By wernerkai

Champion (357)

wernerkai's picture

25-11-2018, 05:08

I think "fuzzy bits" cannot be represented in any "logic" disk image format, because for these bits is expected a random read value for each revolution of the disk, in real hardware. But they can be preserved in flux files, and reproduced when a flux file is written back to a disk. As special hardware was needed to create them, I doubt brazilian disks make use of this kind of protection.

By TomH

Master (249)

TomH's picture

26-11-2018, 16:02

wernerkai wrote:

It's for ATARI, but for sure many of these schemes apply for MSX disks.

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.

Manuel wrote:

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

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.

By sd_snatcher

Prophet (2880)

sd_snatcher's picture

26-11-2018, 20:45

TomH wrote:

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.

I beg to disagree.

1) There's no standard FDC on the MSX system. Not even the addresses used by the FDC chip were standardised (only a range of I/O ports was reserved, without any specs on what each port should do). Many totally unrelated disk controllers (*1) were used, and the BIOS nicely abstracts the differences between them.

2) Thankfully, because of (1), no advanced protection schemes could be made for original MSX software, because all they could produce and that the diskBIOS would recognise were invalid sectors. Amongst the very few exceptions are one or another Brazilian software and some disk copiers here and there. The rest are just problematic cracks that you can find original versions without any of the hassle.

3) Thankfully, also because of (1), it's possible to easily implement disk emulators like SofaRunIt and the MFRSCC+SD, done entirely in software.

*1: Amongst the disk controllers, are:

WD1793, WD2793, TC8566AF, MB8877A, WD37C65, and more recently: IDE, MB89352, WD33C93A, SDHC, USB

By TomH

Master (249)

TomH's picture

26-11-2018, 21:17

sd_snatcher wrote:

*1: Amongst the disk controllers, are:

WD1793, WD2793, TC8566AF, MB8877A, WD37C65, and more recently: IDE, MB89352, WD33C93A, SDHC, USB

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!

By sd_snatcher

Prophet (2880)

sd_snatcher's picture

28-11-2018, 21:38

TomH wrote:

So the diversity isn't anywhere near as great as a recitation of part numbers would make it appear.

Take a look at the openMSX FDC source codes. Then you'll realise that's not only a mater of the chip(s) used, but also:

- If it was memory-mapped or I/O mapped
- The addresses used
- Any complementary circuits (digital status read, hardware/software drive stop, etc)

This results in multiple possible combinations for each chip. For example, here's a small list of some incompatible implementations, per chip:

  • WDx793 family: Philips/Sony v1, National, Microsol, Sony v2 (HB-F1X* family), Victor
  • uPD765 family: Panasonic/Sanyo MSX2/2+, MSX Turbo-R, TDC-600

8 different implementations just from memory. And I'm sure that there are many more. So the diversity is way greater than one can guess just by looking at the chip families.

A software made to run with direct I/O on a Microsol interface won't by any chance run on a different WDx793-based interface without heavy modification. But if you think differently, please feel free to prove me wrong.

Quote:

The WD33C93A is a SCSI controller so isn't used for floppy drives

Back then, I've seen quite some people using LS-120 and floptical drives connected to their MegaSCSI interfaces, along with a hard disk, because this saved one slot by using a single interface. So, yes they can be used for floppy drives, and will even work with 1.44MB disks. The same goes for the IDE version of the LS-120 drives.

But that's not the only point: mass storage interfaces can use SofaRunit to emulate floppy drives without any expensive hardware juggling.

Quote:

Separately, and not what I originally argued but worth mentioning, 90% of the stuff in that document would fool any disk controller.

My point is: from the MSX software point of view, all that black magic doesn't matter, except maybe for fuzzy sectors/tracks. The majority of the other tricks would just be translated as sector read errors. That's all the user software would receive. IOW, anyone with FDC skills could easily replicate a read error for that sector/region just by using whatever simpler trick they wanted.

By NYYRIKKI

Enlighted (5045)

NYYRIKKI's picture

28-11-2018, 22:54

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

sd_snatcher wrote:

So the diversity is way greater than one can guess just by looking at the chip families.

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.

Quote:

So, yes they can be used for floppy drives, and will even work with 1.44MB disks. The same goes for the IDE version of the LS-120 drives.

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.)

Quote:

But that's not the only point: mass storage interfaces can use SofaRunit to emulate floppy drives without any expensive hardware juggling.

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.

Quote:

from the MSX software point of view, all that black magic doesn't matter, except maybe for fuzzy sectors/tracks.

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)

Page 1/2
| 2
My MSX profile