Copy Protection & Image Formats

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-20 @ 01:12

truth5678 wrote:However, I wouldn't consider that the very beginning of computer games. :) For example: http://en.wikipedia.org/wiki/Category:C ... _PET_games and http://www.commodore.ca/gallery/Commodo ... _shots.htm.

Maybe it would be more accurate to say it was the very beginning of the game industry. There, of course, were games that came out before that, but it wasn't yet considered a serious industry. There weren't many, if any, companies that were exclusively game producers. Computer games were considered frivolous and "you can't make money producing video games. There just isn't enough of a market for them," was the general attitude. When a company did produce a game, they didn't put a lot of effort into it.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby truth_deleted » 2014-12-20 @ 01:36

FeedingDragon wrote:When a company did produce a game, they didn't put a lot of effort into it.

Sounds like today!
truth_deleted
 

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-20 @ 23:35

Well, finished going through a single "parameter" crack utility looking "Only" for those marked "Key Disk", meaning they check the floppy for copy protection validation. There are 3 that I'm not sure if they are games or not (marked them,) and I filtered out those that obviously were not games. Back in the day, since I hate using originals, I trolled the BBS files collecting every utility I could find. I collected them because, while there was almost always some overlap, there were also almost always games that would only exist on one. So, the list I have so far can, in no way, be considered a complete list of games that are "officially" unsupported by DOSBox.

I've also added 2 more games that I personally have (Ultima 4 & 5.) On the advice received in another thread, I just edited the link post to update the text file. If I ever convert to Excell, Access, or Word format, I'll also just replace the TXT file.

I guess, other than continuing to update the list when I find games that have on-disk protection, my next step is to start looking at the individual games to see how many have "alternate" versions (compilation CD's etc...)
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby truth_deleted » 2014-12-21 @ 00:10

Another problem is whether these copy protected diskette based games are available. If you have the only copy, how can others test it against the emulation; this is an extreme example, but even if there are just physical copies on ebay for a high price, the same problem exists.

It may also be an interesting note to associate the incompatible floppy games with alternate versions on other operating systems which are emulated by MESS, at least those that meet this criterion but are not copy protected under the "alternative" OS (thereby providing the ability to run the game, with some possibility of running it via an emulator in dosbox).

If there was a core set of unsupported games which have any kind of common availability, then it may generate a lot of interest from others. In any case, these are just thoughts and your plan to provide a list will be very helpful, especially if a set of those games are unique in any way.
truth_deleted
 

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 01:05

Well, the main issue I had was for those games that I, personally, don't have alternatives for, or where the floppy game differs in one way or another from the alternative. One example is Leisure Suit Larry, as I only have the disks. The copy protection on the disk does not convert to IMG format (I've tried.) Also, even when I had a 5.25" drive installed and working on my DOSBox system, it still wouldn't work - but that was with 0.6x, I've lost the ability to put a 5.25" floppy in my main system at all now (without adding in an expansion card.)

However, while researching alternatives to cracking all my games (some of which I can't find cracks for,) I started seeing more and more that fall into the same issue as LSL. It occurred to me, that I might not be the only one that owns games in only one copy protected version. At this time, I have an incomplete list of 140... 137 games (3 might not be games,) that if someone is unlucky enough to have but really want to play, they can't. Their choices are, spend money to buy an alternate version (if it even exists,) spend money to build an entire vintage system for that game, get the game quasi-illegally, or not play the game at all.

Over the last year & a half, I've spent around $700+ on a single vintage system just to convert floppies & play some of the games. The prices I paid for my parts was considerably lower than I would have paid if I had actually been aiming for anything more specific. I'm sorry, but the prices some people demand on eBay is out-right ridiculous. The price of some of the vintage games get just as bad, if not worse. That's assuming you can even find an alternate version of your beloved game on eBay in the first place.

The authors of DOSBox have said in the past that they are not going to work on functionality just to support a couple of games. I'm trying to show that, in this case, it's more than a couple. Also, as is my habit, I'm trying to also supply possible solutions to the problem. If I was a better programmer, I'd also supply code that might fix the problem as well. But, while I'm better than I used to be, I'm still not up to this particular task. I'm not trying to demand a change. If they say, "not at this time," I'd be disappointed, but I'd accept it. Though, I'd still work on coming up with a solution myself :)

Currently, my goal is to learn as much as I can about copy protection methods. What they check for, how they check for it, etc... I'm also learning how the floppy drives are accessed (for determining the types of responses they give.) One of the simpler forms of copy protection just involves reading a specific location and making sure it gets a CRC error response (the standard controller is incapable of intentionally creating a CRC error on a disk.) So, with my "info" file system, DOSBox would know that when a specific location is read, it generates a CRC error as well. Viola, that game now works just fine. That game cannot be written back to a physical disk (without special hardware,) but it can now be played in DOSBox without cracking it. Further, any other game that uses the same method of protection can now be played as well.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby truth_deleted » 2014-12-21 @ 03:41

That's a very reasonable strategy. I'm curious how PCem, along with its floppy emulation, will provide compatibility with copy protected floppy diskette images and its capability in logging relevant information. As you said, a database will show good candidates for testing and determine which games are most problematic.

Where there are very few copies in existence, the right of preservation should outweigh the property concern. Fortunately, archive.org has offered the former.

I think a mixed approach will eventually provide modern use of many problematic (old PC) games, if in fact these exist in such numbers.
truth_deleted
 

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 05:46

Thought I'd post the protection methods I've read about so far. Some of these may not apply to the PC, as they are methods I read about on other systems. I can't believe that this list is 100% complete, but it's all that I could read up on or remember in 2 days. These methods can be used in conjunction with each other (Errors + Fat Tracks + Gap Data for example.) These are not specific protection schemes (such as OSI-1,) but the individual methods that such schemes use in different ways. Such as one scheme will put an error on Track 3 Head 1 Sector 5, while another could put the same error on Track 20 Head 0 Sector 3.

Errors:
    Intentional errors placed on disk. May contain data as well.
Damage:
    Physical damage to disk, reports as an error but may not hold
    data. Some cases test by writing to the location and/or tries
    to repair error.
Spiral Stream:
    Data is aligned so that as the information is read the program
    steps the heads in or out but does not stop reading. Correct
    information can only be read if the stream continues seamlessly.
Fat Tracks:
    Simular to Spiral Stream. Data is identical on 2 tracks and in
    alignment with each other. Program tests by randomly switching
    between tracks. If they are not aligned properly, the data
    becomes corrupted.
Non-Standard Track/Sector Sizes:
    Tracks that contain fewer or greater sectors than the rest of
    disk, or Sectors that are larger/smaller than the others.
Overlaping Sectors:
    Sectors whos data overlaps. Reading one sector also contains
    all or part of the data of a neighboring sector.
Half Tracks:
    Data recorded between 2 tracks.
Gap Data:
    Data is encoded into the gap between sectors.
Altered ID:
    Sector ID is altered to incorrect values.
Extra Tracks:
    Disk is formated with extra tracks beyond 39/79. Can usually
    only have 1 or 2 extra tracks (depending on system.)
Offset Track:
    Tracks that are not correctly aligned to the index. Normally
    a track is formatted so that sector one is right after the
    index signal. These tracks will have a different track after
    the index, or have a track straddling the index signal.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby NewRisingSun » 2014-12-21 @ 15:05

It would be great if you could update your list with the type of protection scheme used. You can find out in many cases by reading the disk with TeleDisk and looking at the end of the created .TD0 file with a hex editor --- in many cases, the name of the protection scheme is in a hidden FM-encoded track that TeleDisk reads into the image as well. For example, King's Quest 1 (128K PC version) reads: "IBM-PC (NM,9/512) COPYLOCK-2.0 DUP 5"-48/40 2S". That's how I discovered the names of many of the protection schemes, as the .EXE files themselves usually do not reveal that.

"Spiral Stream", "Fat Tracks", "Half-Tracks" certainly are not possible to read with the PC floppy controller, and I doubt that "Offset Track" can be reliably detected given the differences in PC speeds.

(the standard controller is incapable of intentionally creating a CRC error on a disk.)
I'm not sure that this is true. If one were to closely monitor the DMA registers and select another drive directly after the last data byte has been transferred but before the CRC bytes are transferred from the FDC to the drive, it should be possible to intentionally write a bad CRC. Writing overlapping sectors would be possible as well if one found a way to encode the "A1 sync".
NewRisingSun
Oldbie
 
Posts: 852
Joined: 2005-9-02 @ 02:26

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 16:29

NewRisingSun wrote:It would be great if you could update your list with the type of protection scheme used. You can find out in many cases by reading the disk with TeleDisk and looking at the end of the created .TD0 file with a hex editor --- in many cases, the name of the protection scheme is in a hidden FM-encoded track that TeleDisk reads into the image as well. For example, King's Quest 1 (128K PC version) reads: "IBM-PC (NM,9/512) COPYLOCK-2.0 DUP 5"-48/40 2S". That's how I discovered the names of many of the protection schemes, as the .EXE files themselves usually do not reveal that.

I might be able to do that with some of the games I own. Right now, the only ones I have direct access to are the Ultima games. The others of mine I only have access to the non-working archived image files I made back when I didn't know what I was doing. I'll take a look at those anyways. However, the only reason I can think of to know the scheme is to use it to search for possible additions to the methods list, or for figuring out which games to use to test emulation of method support.

NewRisingSun wrote:"Spiral Stream", "Fat Tracks", "Half-Tracks" certainly are not possible to read with the PC floppy controller, and I doubt that "Offset Track" can be reliably detected given the differences in PC speeds.

I can't speak (at this time,) about "Spiral Stream" & "Fat Tracks" on the PC, as they depend on moving the head independently of the read function. Start the controller reading (using DMA from what I've read so far,) while using a stable timer (IRQ 1 or IRQ 8) to send a track up or track down pulse while the drive is reading. I know that the timing of IRQ1 & IRQ 8 are both constant despite the system speed. The only direct effect is if the drive's RPM is not what the game is expecting.

I don't know about "Half Tracks" on the PC as well. Does a DD floppy drive use double stepping as well? I know that with a HD drive reading DD floppy, the heads are double-stepped between tracks. Does a DD drive do the same? If so, then half tracks on the PC are easily possible, just single step instead of double step. If not, then it is unlikely as many of the games are written before HD drives were available.

As for "Offset Track", of the systems I have experience with, the PC is the only one that can use that method. The C64 & Apple II don't use the index. The PC's controller can be set to start reading as soon as the index pulses. Or it can be set to start reading at a given interval after the pulse. Again, the timing of read start can be made stable with IRQ1 or IRQ8, but the drive's RPM could effect the outcome.

In all the cases above, a "smart" program can measure the timing between index pulses and adjust accordingly.

NewRisingSun wrote:
(the standard controller is incapable of intentionally creating a CRC error on a disk.)
I'm not sure that this is true. If one were to closely monitor the DMA registers and select another drive directly after the last data byte has been transferred but before the CRC bytes are transferred from the FDC to the drive, it should be possible to intentionally write a bad CRC. Writing overlapping sectors would be possible as well if one found a way to encode the "A1 sync".

I only said that it was incapable of intentionally creating errors because several sources stated as much. The one most remembered right now was when I was reading up on Sierra Track 6 Copy Protection found HERE, which I mistook for the protection on my Ultima 1 & 2 games. I've since discovered that the actual method is OSI-1 with details found HERE instead.

They use "Non-Standard Sector Size", "Non-Standard Track Size", and "Altered ID". Track 6 has 10 Sectors (instead of 9.) The 2nd, 4th, 6th, & 8th sectors are 1024 bytes instead of 512. Finally, the sector ID #'s are 1, 2, 187, 3, 188, 4, 189, 5, 190, & 170 instead of being numbered 1-10. Everything except the "Non-Standard Track Size" can be written back to disk with a standard PC controller.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 16:34

I've been seriously considering starting an Access database for the list instead of just a plain text file. This would allow me to create a table of methods and a table of schemes. They would be cross linked so that the schemes would refer to the methods they use. Finally, the games could be referenced to the scheme each game uses. I'm not overly familiar with Office 2010's Access, though, and would have to learn as I go on how to do a lot of this (meaning, it will take quite a bit of time.) Do you think that would be better than the text file?
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby NewRisingSun » 2014-12-21 @ 17:33

FeedingDragon wrote:as they depend on moving the head independently of the read function.
That's not possible with the FDC.
FeedingDragon wrote:to send a track up or track down pulse while the drive is reading.
You cannot just "send a pulse" to the drive.
FeedingDragon wrote:Start the controller reading (using DMA from what I've read so far,)
Read operations are initiated by sending a Read Data or Read Track command to the FDC. The DMA controller just takes bytes from the floppy controller and puts them into RAM and vice-versa. It is useful though to monitor its registers to tell how for into a read/write operation the FDC is at any given point in time.
FeedingDragon wrote:while using a stable timer (IRQ 1 or IRQ 8 )
IRQ 1 is the keyboard. You must mean IRQ 0, which is triggered by the 8254 Programmable Interval Timer.
FeedingDragon wrote: Does a DD floppy drive use double stepping as well?
A double density 5.25 inch drive has a wider magnetic head than a high density 5.25 inch drive. Therefore, a high density drive's "double stepping" is a double density drive's "single stepping". This should make "half-tracks" impossible to use with double density drives, and no one would write a copy protection routine that only works with high density drives reading double density disks.
FeedingDragon wrote: The PC's controller can be set to start reading as soon as the index pulses. Or it can be set to start reading at a given interval after the pulse.
How? I don't see anything like that in the µPD765A data sheet.
FeedingDragon wrote:Everything except the "Non-Standard Track Size" can be written back to disk with a standard PC controller.
But not on a 360K disk, unless you find a way to write overlapping sectors.
FeedingDragon wrote:Do you think that would be better than the text file?
I have never used MS Access, and imagine it to be way too complicated for the given purpose. Just make a text file with one section for each protection scheme, describing what it does and which games use it.

I can tell from your writings that coming from the Apple/Commodore world, you don't fully appreciate how little control the PC's FDC gives you over the drive. :)
NewRisingSun
Oldbie
 
Posts: 852
Joined: 2005-9-02 @ 02:26

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 19:32

Sorry NewRisingSun, not going to quote everything this time :)

I haven't read far enough into floppy controller info to know if it's possible to move the read head during the middle of a transfer. I do know that DMA is used to take the CPU out of the transfer loop. The computer can keep on doing other things while the floppy controller is moving data to/from the disk directly from/to a specific memory location. That is why I said to use DMA for the transfer so that the program could, by either timing (and you're right, I meant IRQ 0, the "first" hardware interrupt,) or monitoring the data flow, then shift the head at the proper time. But if that can't be done, it makes no difference. As a note on interrupts, it's also possible to use PIT 2 (usually used for programming digital sound on a PC speaker, but can be used for other things.)

As for the track shift. I'm redoing my search right now because I didn't save that particular page :(. However, one of the pages that I went to had a snippet of code to reprogram the DOS/BIOS drive access routines INT 0x13. Normally, when beginning a format or a write, you watch the index bit and wait for it to change (usually twice,) then start. The new code introduced a delay between the second change and beginning the write (or read I would assume.) This resulted in a track shift. In order to read the disk correctly, the program would have to introduce the same delay during the read function. When I find the page again, I'll post the link... I'm not 100% sure which of the search phrases I used to find that page :( I do know that I had never heard of "Track Shift" until then (a title I invented, most of the others I got from elsewhere.) It had never occurred to me that it was possible. Of course, I'm not used to dealing with index synch either. IIRC, it could only be done on a full track read/write, not with sector access.

I would also like to note that I may not be remembering the page 100% :( A lot of my searches took place on little sleep. I would have to say that my confidence in this is only around 90%. I remember my conclusions perfectly, the actual text imperfectly. I do know that I wrote down the "Track Shift" method while reading that page. I also remember thinking that it was "cool" :) It was something new to me at the time.

Finally, you're right, I learned most if this in the 80's on a C64 and Apple II (mostly the C64.) I'm absolutely fanatical about not using originals, so I did a lot of research (and spent quite a bit of money,) insuring that I wouldn't have to. As a matter of fact, I felt a huge amount of vindication when I read the details on the Kryoflux when I heard about it. I spent months arguing with people trying to convince them that magnetic media (floppy disks,) were actually analog, and that rigging an analog copy method would bypass most (if not all) copy protections. Yes, the data is digital, but the medium is analog. Someone actually managed to create a dual drive that could do it. IIRC, the MSD SD-2 drive, with a purchasable modification kit, could cross link the read head of drive 0 with the write head of drive 1. Then all the software had to do was spin the disk, link the heads, then walk the head in & out a few times. The same process was repeated with the Amiga (Cyclone & Apex, maybe others.)

Access is fairly easy to read, it's the creation that's a PITA. It's the cross-linking and look-ups that I don't yet know how to do in Access 2010. I actually did it rather regularly in a much earlier version (..cough.. Windows 3.1 ..cough..) Building the tables is easy, its the cross-linking that I will have to re-learn. Look-up tables, data entry scripts, and reports are the areas that would need to be used IIRC. I built a database for Bard's Tale 1-3 to help determine which items were usable together, by what class, and how they transferred to later games. It is fairly simple, but I'll post it here in case anyone wants to look at it.
Attachments
Bard's Tale.zip
Bard's Tale 1-3 item list
(34.54 KiB) Downloaded 81 times
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 20:37

Based on NewRisingSun's information, and I'm going to assume for now that I'm wrong about track shift, the current list of protection methods has been changed to:

Errors:
    Specific Error place on the disk. May contain data in the Sector as well.
Damage:
    Disk is physically damaged in some manner. May not contain data, and cannot be "repaired"
Non Standard Track Size:
    Tracks with more or fewer sectors than the others on the disk.
Non Standard Sector Size:
    Sectors that are larger or smaller than the others on the disk
Overlaping Sectors:
    Sectors that also contain all or part of the data from an adjoining sector
Gap Data:
    Data stored in the gap between sectors
Altered ID:
    Sector ID has incorrect data, or is otherwise altered.
Extra Tracks:
    Disk is formated with extra tracks above 39/79 (count starts at 0.) Can usually only have 1 or 2
Altered Gap:
    Gap size is changed.
Weak Bits:
    Every bit is surrounded by bit patterns because if a "flux" read has no changes the results are random. This makes the surrounding bits all the same to intentionally generate a random result
Track Offset may still be possible, but until I find the page again, I'm going to go with the assumption that it doesn't on the PC. I also separated the Sector & Track non standard sizes into 2 different types instead of as one. This brings the total number of protection methods that I've confirmed to 10. The different schemes could use any combination of these. I've also discovered games that not only have one of these on-disk methods, but also has a document or code wheel check as well. I'm still working on a way to encode these in a way that the effects could be simulated (not necessarily emulated.) I'm also still looking to see if I can find any others that might be applicable. One that I have not listed is the non standard format. These are exclusively (as far as I can discover,) found on booters, and DOSBox seems to be able to handle those just fine.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby NewRisingSun » 2014-12-21 @ 21:44

FeedingDragon wrote:then shift the head at the proper time.
But to shift the head, you have to send a seek command to the FDC, and the FDC will not accept a second command while it executes the Read Data/Read Track command. That's why this cannot work.
FeedingDragon wrote:Normally, when beginning a format or a write, you watch the index bit and wait for it to change (usually twice,) then start.
You most certainly do not do that. If you have seen code that waits for a bit to change before sending something to the floppy controller, it is waiting for the RQM bit to be set which indicates that the floppy controller will accept command or data bytes from the processor. The data sheet is nicely clear about how a Write operation is initiated: "After the Write command has been issued the FDC loads the head (if it is in the unloaded state), waits the specified Head Settling Time (defined in the Specify command), and begins reading ID fields. When all four bytes loaded during the command (C, H, R, N) match the four bytes of the ID field from the diskette, the FDC takes data from the processor byte-by-byte via the data bus, and outputs it to the FDD".

The FDC on the PC actually does not even provide an index bit to the processor. The IBM PS/2 series does in two "diagnostic registers" at 3F0/3F1, but implements them differently between PS/2 models. These are not carried over to AT-compatible designs and are used for Plug-and-Play configuration in Plug-and-Play motherboards.
NewRisingSun
Oldbie
 
Posts: 852
Joined: 2005-9-02 @ 02:26

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-21 @ 23:29

I did remove the head movement while reading protections already. I haven't yet found any way to do that, and am willing to accept you can't. As for the index sense, rebuilding from memory based on reading other sources I've found trying to find the page again. The generic commands (common only, not including the AT or PS/2 specific,) does not include an index line. However, the controller can issue a hardware interrupt when the IDX line from the floppy drive is triggered. Reading other sources more closely, I don't see a way of pushing a delay on the controller itself. That being said, I will continue trying to find the page, but have also removed that method from the list as well. When I find the page, I'll try the code myself and see what happens.

It was in assembly, so I didn't pay any more attention to the code other than to read the comments. There was a section labeled "wait for index signal", which from reading another page HERE, leads me to believe it was a case of waiting for an interrupt generated when the controller detects the index (it gets the index, but doesn't pass that particular line along.) There was another sections labeled "force controller to delay x ticks before writing". I have not discovered how they "planned" to force that delay, it may not be possible, or it may depend on specialized HW. As I said, I've removed that method from the list, and unless I find that page, and maybe not even then in case I had read it wrong, it will stay off the list.

I did discover that it seems to be absurdly simple to format a track with multiple sector sizes. What happens if the sector count/sizes adds up to too much over 4.5K (the normal size,) I'm still unsure of. I'm also still looking into information on the GAP and so forth. When you format a track, you send information for the ID and Size for each individual sector. Either through a DMA buffer, or through an interrupt driven data transfer program. The GAP size is sent with the format command, along with track length, sector size, and fill byte. So, the GAP size is only set once during the format, while the sector sizes are sent multiple times (1 during the format command, then again for each sector.) Still researching.....
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby NewRisingSun » 2014-12-22 @ 00:04

FeedingDragon wrote:That being said, I will continue trying to find the page,
Well, you've certainly made me curious. :)
which from reading another page HERE, leads me to believe it was a case of waiting for an interrupt generated when the controller detects the index (it gets the index, but doesn't pass that particular line along.)
The interrupt it is waiting for is issued at the end of the execution phase, in other words, when the read/write operation has been completed. Basically, you send Read Data to the FDC, then do something else, then after all data has been read, get interrupted to service the FDC which has issued IRQ2. The dumb PC BIOS of course sends Read Data, then sits there waiting for the IRQ doing nothing, then returns to the calling program.
FeedingDragon wrote:What happens if the sector count/sizes adds up to too much over 4.5K (the normal size,) I'm still unsure of.
Including gaps, a 360K disk has about 6300 bytes of data. According to the µPD765 data sheet, the FDC will terminate the format command upon encountering the index hole a second time (first time is when it starts formatting).
NewRisingSun
Oldbie
 
Posts: 852
Joined: 2005-9-02 @ 02:26

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-22 @ 02:22

I must have read it wrong. In non-DMA mode, I thought it said it triggered an interrupt when it was ready to format the next sector (which for the first sector would be right after the index sense.) I'll pull it up again later and read it again (sort of in the middle of 3 different things right now.) The interrupt, in normal operation, is the controller saying, "OK, send me the four bytes I need to format this sector." Considering how, well - I can only say "dumb" - the controller seems to be (I don't mean dumb in design here, I mean non-programmable,) it would seem that if you just "waited" to send the data it would probably error out. Or maybe reset itself to "count" all over (wait for the index, then count past what it's already done, then use the bytes you send.)

Does the data length vary by track number any? 6300 seems a little small for the data stored in a couple of protection methods I've read. Sierra's track 6, for example is holding at least 8192 bytes. ORI-1 has 7168 bytes on track 6, though it also reports incorrect gap sizes for some of them. In the case of Sierra's, there are no gaps, a full read of sector 1 also reads sectors 2-8 (all sectors with a length of 1024 bytes.)

Considering the difficulty I'm having finding the page again, I'm starting to suspect I found it during a different search. Some of which involved looking for one of the option boards. Maybe it was some code for one of those? I don't think so, but I guess it could be :( Just out of curiosity, would skewing a track off the index with specialized hardware have an effect on a disk read by normal hardware? If normal hardware can't skew the read, what would even be the point?

It's all really moot, though. All we are really concerned with is simulating the reading of such, it's already understood that a standard controller cannot write some of them back. We are also only worried about methods that are confirmed to exist. If done correctly, the simulation will have expandability built in. The "flags" byte I mentioned. Go ahead and extend that to 2 bytes or more. Then, sticking with just the 10 I have listed so far, some of them get encoded into the information itself (extra tracks, extra sectors, variable track or sector sizes.) The rest can be added later as the need appears. Don't include track skew. Then, if by some miracle it turns out that there is a way to interpret a skewed track (remember, copy protected disk are usually created with specialized mastering hardware,) the method of simulating it can be added later. I got so intent on covering both reading and writing of things, that I started grouping everything (even the standard controller,) into the same read/write category. Writing isn't the issue, it's reading only that we are covering here. This is about simulating things so that someone that owns a game, but not the hardware to play it, has the ability to play it in DOSBox. Not with figuring a way out for them to run off copies of the game.
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

Re: Copy Protection & Image Formats

Postby Zup » 2014-12-22 @ 07:43

I usually play ZX Spectrum games, that use most of these techniques and also some others. Maybe I could bring some light to some things written here.

FeedingDragon wrote:Fat Tracks:
    Simular to Spiral Stream. Data is identical on 2 tracks and in
    alignment with each other. Program tests by randomly switching
    between tracks. If they are not aligned properly, the data
    becomes corrupted.


The FDC can not switch tracks between operations, but it can be useful combined with "non-standard sector ordering".

FeedingDragon wrote:Gap Data:
    Data is encoded into the gap between sectors.


There is a FDC command that allows to read an entire track (not sectors), so this is possible.

FeedingDragon wrote:Altered ID:
    Sector ID is altered to incorrect values.


On ZX Spectrum, "normal" sectors start at 0xC1. If you don't use standard DOS formatting, there is no point in using any sector number in any order (more on this below). As the FDC can cope with any sector numbering, there is no such things as "incorrect values".

FeedingDragon wrote:Extra Tracks:
    Disk is formated with extra tracks beyond 39/79. Can usually
    only have 1 or 2 extra tracks (depending on system.)


Used in 2M disk tools. But, I've seen some disks (booter) that actually have less formatted tracks than expected (45 tracks instead of 80).

FeedingDragon wrote:Offset Track:
    Tracks that are not correctly aligned to the index. Normally
    a track is formatted so that sector one is right after the
    index signal. These tracks will have a different track after
    the index, or have a track straddling the index signal.


I should call this "sliding tracks", "sliding sectors" or "non-standard sector ordering". The trick is that when you format a track, you have to give a list of sectors to the FDC, and no one mentions that it has to start from 0 (see Altered ID). There were some utilities for ZX Spectrum (and I guess for DOS) that introduced some interleaving to enhace performance.

When you move the head, the floppy motor is running and data is passing below the head. If you read sector 3, move the head and then try to read sector 4, sector 4 has already fallen behind the head and needs another turn of the floppy to be read. In the Spectrum, some utilities formated track 0 with sector numbering 0,1,2,3..., track 1 with numbering 3,4,5,... so sequential readings could be faster.

In disk protections, you could:
- Format track n as sectors 0,1,3,4,5,6,7,8,2.
- Format track n as sectors 0,1,2,3,4,5,6,7,8 and track n+1 as sectors 3,4,5,6,7,8,0,1,2.

In the first case, you may time how much cost read sector 2. If it is read fast, you know that disk was formatted by DOS (sector 2 is right after sector 1).
In the second case, you read a sector from track n and then next sector from track n+1. If it took too much time, the disk is formatted by DOS (tracks always start from 0). I guess this if the technique behind Fat Tracks.

I don't know if PCs floppy heads are ready to read sectors right after reading the previous, or they could benefit from some sector interleaving.

Also, keep in mind that (in DD disks) track lenght is 6250 bytes, so you have space to get 10 sectors (512 bytes) per track without any trouble (as DMF and 2M disks do) and you could find that in any protected disk.
I have traveled across the universe and through the years to find Her.
Sometimes going all the way is just a start...

I'm selling some stuff!
User avatar
Zup
Oldbie
 
Posts: 1263
Joined: 2003-10-04 @ 12:16

Re: Copy Protection & Image Formats

Postby NewRisingSun » 2014-12-22 @ 11:55

FeedingDragon wrote: it would seem that if you just "waited" to send the data it would probably error out
That's right. If you don't send the sector ID byes in time, the FDC will just set the "Over Run" flag and terminate the current operation.
FeedingDragon wrote:Does the data length vary by track number any?
No, the PC does not use zone bit recording.
FeedingDragon wrote:6300 seems a little small for the data stored in a couple of protection methods I've read. Sierra's track 6, for example is holding at least 8192 bytes.
That's because the sector size fields in the sector IDs are fake. Hence "overlapping" sectors. The 8192-byte sector 1 indeed incorporates one-and-a-half revolutions of the medium.
FeedingDragon wrote:would skewing a track off the index with specialized hardware have an effect on a disk read by normal hardware?
Probably not: As I understand the data sheet, the FDC does not start reading at the index hole during normal "Read Data" commands but at the Index Address Mark. It only makes use of the index hole to (1) start reading using the "Read Track" command, which is normally not used, (2) start formatting, and (3) to signal "sector not found" when it encounters the index hole a second time without finding the desired sector ID. (The PC drive itself will also require the index hole to accept anything from the FDC, hence the modification needed to read flippy disks with only one index hole.)
NewRisingSun
Oldbie
 
Posts: 852
Joined: 2005-9-02 @ 02:26

Re: Copy Protection & Image Formats

Postby FeedingDragon » 2014-12-22 @ 13:59

NewRisingSun wrote:
FeedingDragon wrote:would skewing a track off the index with specialized hardware have an effect on a disk read by normal hardware?
Probably not: As I understand the data sheet, the FDC does not start reading at the index hole during normal "Read Data" commands but at the Index Address Mark. It only makes use of the index hole to (1) start reading using the "Read Track" command, which is normally not used, (2) start formatting, and (3) to signal "sector not found" when it encounters the index hole a second time without finding the desired sector ID. (The PC drive itself will also require the index hole to accept anything from the FDC, hence the modification needed to read flippy disks with only one index hole.)


(1) "Read Track", could be used as a test maybe? But then use regular sector reads to actually get the data. If a track read would come back with an error or garbled, but the individual sectors can be read normally, it would actually make for a good copy protection. It can't be re-created with normal hardware (since my searches for programming the FDC have still failed, I'm going to assume the page concerned special hardware for now.) You can still read, and maybe even write all the data on the track (as long as it's done on a sector by sector basis.) Reading the full track would show that it is skewed either by garbling the data or causing a read error. Would need that hardware to test the theory though, or already know how the FDC would respond to a skewed track with a Track Read. If the FDC would just adjust, then the theory goes out.

"Incorrect Values" does not necessarily mean error generation. As an example, I've seen sectors labeled (in order of appearance on the track,) 1, 2, 187, 3, 188, 4, 189, 5, 190, 170. That's 10 tracks, with tracks 2, 3, 4, & 5 set to 1024 bytes. What's confusing is every sector has data. Now, there were also 3 (not sure of the number, but it was 2-4) cases of changed GAP size (the GAP was smaller or larger than normal - it didn't specify.) However, not including the GAP data, that's still 7168 bytes. So, is the 6300 byte limit based on the physical floppy, or on the limitations of the controller? Since Ultima 3 re-masters just fine, I would assume it was the physical floppy that's limiting things. That being said, the inner tracks will have less "physical" space than the outer tracks. So, if 6300 refers to track 0, it wouldn't be hard to imagine that track 9 could hold the 7168 bytes + reduced GAP values. That assumes, though, that the 6300 is based on physical space and not on how fast the FDC can read the data (outer tracks are also moving faster than inner tracks.)
Feeding Dragon
User avatar
FeedingDragon
Oldbie
 
Posts: 821
Joined: 2003-8-24 @ 03:25
Location: Central Texas

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests