VOGONS


IPF support

Topic actions

Reply 20 of 70, by jklaiho

User metadata
Rank Newbie
Rank
Newbie

Well, that got lively fast. Frankly, I'm puzzled why there seems to be such a frequent streak of hostility on these forums. Be that as it may, let me try and address various points made here.

You know what, before going deeper into this, you should compile a list of games that *really* need this imaging, for which normal images made in dos with a good floppy image program, do not work in dosbox

Someone has compiled a list of booters and DOS games that have copy protection here. I have no idea how exhaustive it is, but it is a nontrivial list of games. The funny thing is, many (perhaps most) of those are also on the DOSBox compatibility list, despite them only being playable as pirated copies (or cracked, which is still shady if not technically illegal, and this can vary by jurisdiction). Not a ding on the developers, I know the compatibility list is user-submitted, but for DOSBox to be truly capital-c Compatible with them, it would need to deal with authentic disk images in some way.

As for GPL and IPF openness, I highly recommend this thread on the KryoFlux forums: IPF and openness. It's sixteen pages long and from 2011, but it's the big discussion that took place when the IPF library license choice was up for debate. The intent of the developers there is plainly in view: they want it to be used as widely as possible, since that's the only way to make a preservation format credible in the long run. The thread attempts to explain why they felt GPL wasn't a good fit for them, but they very much want GPL software to be able to use IPF. (To that end, note that the Developer Library and Access API are licensed differently on the SPS site, with the latter allowed static linking to any program, open source or commercial.)

A quote from "mr. vince", one of the devs, in the thread that was spawned off the first thread after the license choice was made: We really encourage you to ask us if you feel you need the source licensed under a different licence. They share your free ideals, it's just that their specific implementation is a little (not a lot) different, and can apparently be made to mesh with yours in one way or another.

Sufficient freedom and actual intent are what's important, the choice of license shouldn't be seen as more than an implementation detail, certainly not as an ideological blocker.

Regarding the IPF, the first issue with implementing it is that DOSBox does not fully, if at all, emulate the NEC 765 Floppy Controller. DOSBox instead emulates Int 13h floppy writes and DOS calls. The copy protection schemes which the IPF seeks to preserve rely on the behavior of that controller. So there is the first obstacle.

I'm on unsure footing on the technical side, so excuse misunderstandings. As I've understood it, there are two ways to approach this: either let the library feed your emulated floppy controller the data (which, I take it from your comment, is not possible since DOSBox does not emulate the controller), OR use the floppy emulator built in to the library. See this post on page 3 of the thread. I'm not familiar with the functionality myself, but would this approach theoretically be applicable to DOSBox without entirely rewriting the current floppy handling scheme?

Second, due in part to its high price and limited appeal, relatively few DOS gamers own a Kyroflux. Why bother implementing a feature that only 10-15 people may use?

Third, there are no tools available to the public to turn KF streaming files into IPF files, and even less support if you actually want to rewrite them to a disk. Also, if its not an Amiga game, especially a pristine one not yet in the SPS, good luck getting attention.

...Kyroflux is not a good solution for DOS gamers at this time, and judging by the antipathy to any platform not released by Commodore or Atari, it may never be.

First, SPS has in recent times been quite welcoming of dumps on any platform that KryoFlux supports. I've been explicitly told to submit any dumps I make for IPF conversion. Before KF existed, they couldn't easily source preservation-quality dumps of games for a larger variety of platforms. They can now, and it is apparent in their recent communications.

As for the presumed limited appeal of KF, I was about to reply to this detailing the philosophical reasoning for the inclusion of KryoFlux support as the only realistic way (not widely used, but still the only way) to keep playing legally owned copy-protected games in the time where people no longer bother to have a floppy drive inside their machine (but do keep one around for connecting to the KF). But I decided against it. Let's just shed the pretense, shall we?

DOSBox users overwhelmingly use it to play at least some games they don't own. In the best case, they might have once owned them in the early nineties or something, but they've long since sold them or given them away or lost them or see them succumb to bit rot and be thrown away. That doesn't mean they won't get the occasional pang of nostalgia and want to relive those memories. Sure, some shining beacons of human virtue may actually hunt down a copy from eBay, if and only if they possess the means to transfer the game to DOSBox. That is rare and will only become more so. Of the people who have upgraded their computer in recent years or will do so in years to come, only nerds like us have floppy drives, even USB ones. Others, the majority, will just go look for it on abandonware sites or The Pirate Bay. Soon enough (and already for users of new Mac Minis or MacBooks), it'll be the same for CD games since optical drives are slowly fading away. Remember, we should be forward-thinking, looking 10-20 years into the future at least.

To anyone about to ragereply to this: kindly skip the "Well I NEVER..!" outrage and face facts. The developers (perhaps wisely) stay quiet about it, but it would be living in denial to not tacitly acknowledge that this is the practical reality of things. Just because YOU own all the games you play doesn't mean everybody else does, or that even the majority does.

So. Currently your average abandonware site or retro torrent haven hosts a mishmash of cracked, preinstalled games; disk images if you're lucky; TeleDisk images of copy-protected games if you're REALLY lucky (though PCE is your only option there). As more and more serious game collectors get KryoFluxes, and SPS accordingly ramps up IPF production of them, they will become more widely available via ever prevalent casual piracy.

Look at the Amiga side of things. People could just as easily play the cracked .adf games, but there is still a lot of demand for IPFs. It's the packrat mentality of a lot of retro game hobbyists: collect, store and preserve the most "pure" representation of a game available.

It would be silly to assume that if DOS and PC booter IPFs become available, there wouldn't be demand for them in the DOSBox user base - whether they consist of people dumping their own collection or (more frequently) playing games others have dumped and then shared via piracy.

In the end it comes down to this: there will be PC IPF images in increasing numbers. There will be users who want to use them. Some DOSBox ports or other emulators like PCE or MESS will pick up the slack and support them. Will DOSBox? If not, why not? Don't think now, think 2023.

Supporting IPF images is no more or less conducive to piracy than the mere fact of emulating DOS is in the first place: to pirate or not pirate is still the exclusive choice of the user, the emulator itself is not to blame. The only thing an emulator developer can do to discourage piracy is to provide the users the most comprehensive means of playing legally owned old games, not just right now but in the future as well. (This means no reliance on physical floppy drives existing in the machine that is used to play the game.) For copy-protected games, IPF support is the only realistic way to go about doing it.

Your choices are the following:

1. Implement IPF support, either yourself or through a GSoC project or equivalent. You are philosophically consistent by providing the means for users to play even the most problematic copy-protected games legally, which is in line with your stated anti-piracy stance. (The "putting your money where your mouth is" option.)

2. Do not implement IPF support, but explicitly state that you do not support games that have physical copy protection on the floppy disks. You are philosophically consistent: even though users can run cracked versions of these games, you are disclaiming any part in it. The fact that they can run is incidental, not intentional.

3. Do not implement IPF support and do not express non-support for the physically protected games. This is philosophically inconsistent, since you frown upon piracy, yet tacitly acknowledge that it is the only way to play a number of games that are considered supported. This is the worst option, and effectively the situation right now.

I'll finish with this:

The concept of DOSBox is firmly rooted in the GPL and open source. The developers are trying to rid themselves of any vestiges of non GPL-MAME code. It is simply contrary to the aim of DOSBox to have most of DOSBox released under the GPL and some portions released under a different license.

Consider: is the point of DOSBox to enable its users to emulate the DOS games of days gone by and to serve the users' needs as well as it can, or is it to be a good GPL citizen for its own sake?

Reply 21 of 70, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

for which normal images made in dos with a good floppy image program

It's not the floppy image program that is the problem, it's that the regular .IMA file format contains no metadata whatsover. Even the disk size itself can only be deduced from the file size. Any time a disk uses sector sizes other than 512, uses non-sequential sector numbering, expects a "CRC error" or "sector not found" from reading a certain sector, the regular .IMA file format can't store that data. Here's a very incomplete list of games that are affected:

Copylock:
Ultima II (Sierra On-Line version)
Ultima III (1984/1985 version)
King's Quest (128K version for PC)
Sierra Championship Boxing
BC's Quest for Tires (Sierra On-Line copyright)

Softguard (something, I believe Superlok) version 2.3 with Sierra On-Line custom loader (SIERRA.COM together with CPC.COM):
The Black Cauldron (version 1.1J, 1.1K, 1.1M, 2.00, not 2.10)
King's Quest (256K version 2.0F)
King's Quest II (versions 1.0W, 1.1H, 2.1, 2.2)
King's Quest III (versions 1.01, 2.00, 2.14)
Space Quest I (versions 1.0X, 1.1A, 2.2)
Space Quest II (versions 2.0A, 2.0C, 2.0D, 2.0F)
Thexder

dito, version 3.0
various Taito Games, i.e. Bubble Bobble, Arkanoid 1/2...

Origin Systems custom ("OSI"):
Ultima I
Ultima II (1989 Origin Systems version)
Ulitma IV
Ultima V

Scheme with name unknown to me:
Test Drive 1
Test Drive 2
Grand Prix Circuit (earlier version, a later version ships completely unprotected)
California Games

This thread lists several other games.

Fun fact: some industry disk duplicators put a string with a serial number into a hidden sector at the very end of a disk. That string in many cases also identifies the copy protection method, which is how I know that Ultima III (1985 version)'s method is called "COPYLOCK", because the protection code itself doesn't give its name. Regular imaging programs won't find that, but Teledisk did. 😀

Reply 22 of 70, by robertmo

User metadata
Rank l33t++
Rank
l33t++

I think cracking is the only future option:

Modern games require constant Internet connection. In the future when the company no longer supports the game server or simply goes out of market there will be no way to play games without cracks.

Also companies would like all old games to just disappear as you only have a limited time to play games so if you spend it on playing old games you don't give them money for new games.

Hence I wouldn't care about it at all.

The more important thing is that DOSBox project is dead 😉

Reply 23 of 70, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Modern games require constant Internet connection.

You could have a virtual machine emulate the publisher's authentication server. 😀

Hence I wouldn't care about it at all.

Well, there is still the whole preservation aspect.

The more important thing is that DOSBox project is dead

I know that the original developers aren't actively pursuing the project anymore, but as I understood it, there will still be future releases containing accepted patches.

Reply 24 of 70, by VileR

User metadata
Rank l33t
Rank
l33t

Even if IPF support was added to DOSBox tomorrow, you'd still need to go through the SPS to get your Kryoflux dumps converted. Besides the fact that they're limited in time and manpower, they quite openly state that they won't bother with anything that doesn't meet their project's goals. IIRC, the criteria are rather stringent - "pristine and unmodified" means that something as trivial as saved high scores renders the image unfit for preservation. Never mind that, in many cases, simple common sense can be enough to correct tiny imperfections like that.

That's probably the right approach for the SPS's own stated goals, but not necessarily for yours (just playing your game in DOSBox).

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 25 of 70, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

It has yet to be shown that either well-understood (Teledisk & Anadisk) or open source formats (ImageDisk, IBM PCE pdfc) would be insufficient to play copy protected games on DOSBox if support for them were added. Whomever writes a patch for DOS to support these formats would be contributing GPL code.

Kyroflux is indeed better to write disks back for use in real vintage hardware, but that is not the goal of DOSBox.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 26 of 70, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Well, there is still the whole preservation aspect.

that doesn't need Dosbox support 😉
And as for Dosbox being dead... Seemingly the last active developer has vanished last month...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 27 of 70, by P4R4D0X

User metadata
Rank Member
Rank
Member

I'm pretty much confident that this will not happen until the guys at Software Preservation Society don't make up their minds. Clearly their license is just a really bad choice. Also I have a mixed feeling abut the .IPF format. In theory it's awesome for preservation, however the downside is that the format is not really open. You can't generate your own .IPF files even if you have a KryoFlux, you can write them to disks but not create them. That's just wrong! The only way to obtain these is by uploading them to their FTP server and the guys at SPS will create you the files.

So they are clearly doing this to sell more and more KryoFlux boards and to have more and more stream data and .IPF dumps. Also I hate the fact that they don't allow you to download you to get the .IPFs if you don't have a KryoFlux unit and you have the real authentic disks. Now that's just wrong. This is wrong again. They have everything backed up on several servers across the globe and obviously they don't own every single game.

WinUAE has .IPF support, but only if you download and place the CAPSImg.dll file where the emulator is installed which will never happen to DOSBox. This is the only way to play those Amiga games. Of course you can grab the .adf versions from a ton a websites, and even the .IPFs thanks to CAPSDI, because at least they care. The guys from SPS has been bugged a lot about distribution on the English Amiga Board, but they tell us the same over and over again.

Anyway, adandonware, roms, disk images of old unsupported games is still a grey zone. If we need to crack copy protected games we will do them. For MS-DOS games we have a bunch of unprotectors like Neverlock, RawCopy PC, Crock, CrackAid, DProtecter, Locksmith, The Patcher and even more which I'm probably not aware of. They support a bunch of games, and you don't need to download any cracked version when you have the boxed game and you must defeat the copy protection.

Here's the same topic from the KryoFlux forums opened by Zorix on the same date:
http://forum.kryoflux.com/viewtopic.php?f=4&t=584#p5125

I contacted one of the maintainers of DOSBox ages ago. The answer was something like "unless this is free (GPL), get lost". Now the decoder is free under a modified MAME licence. I think it still does not fit for them... It could also be that the code is still in a state where low level floppy support - which would be needed for correct IPF interpretation, is missing.

There's no reason to convert IPF to another format, at least not if you want to keep everything IPF stands for. Otherwise a solution to access and extract the data, like a plugin for Total Commander would make more sense.

They would love if more and more emulators would support their proprietary file format which only they can generate from user submitted data. Currently they are working on Commodore 64 .IPF support. And by looking at their outdated database they only have three IBM PC games, and who knows how many more on their servers. And I wonder how many people are waiting to receive their .IPF files...

So yeah, to sum up everything. We would love to support .IPF files and it would be awesome, but we can't in the current state. IPF is a great concept, but it's too locked down and proprietary format. It won't make in the mainline, maybe in other builds. Just GPL the format and everything and it's a win-win.

The DOSBox developers are not the one to blame. We are just trying to explain why there's no IPF support yet. Anyway by looking at the last DOSBox SVN commit is from more than a month, let alone the DOSBox 0.74 is from 2010. 😒

Reply 28 of 70, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

It has yet to be shown that either well-understood (Teledisk & Anadisk) or open source formats (ImageDisk, IBM PCE pdfc)

There's also the .FDI format from DISK2FDI. 😀

would be insufficient to play copy protected games on DOSBox if support for them were added.

Well, having just tried some of my TeleDisk images with PCE, I have observed the following:

With the same original disk (SQ1 version 2.2 AGI 2.917) at the same Teledisk settings, Teledisk versions 2.15, 2.16 and 2.23 all yield slightly different images, all of which work in PCE provided that I fiddle around with certain PCE settings that I don't fully understand yet. The PCE author writes that he only uses TeleDisk version 2.1x, so apparently 2.23 is a bad one. I noticed that when using images created with 2.23, PCE complains about "phantom sectors"; this doesn't occur with images created using 2.15 or 2.16.

From the Teledisk images that I have created myself from original media, the following worked:
- Bubble Bobble
- Space Quest I version 2.2 AGI 2.917
- Space Quest II version 2.0D
- Ultima I (from Ultima I-III trilogy)
- Ultima II (1989 Origin Systems re-release from Ultima I-III trilogy)
- Ultima III (1987 file date, from Ultima I-III trilogy)

And the following didn't:
- Ultima II (1984 Sierra On-Line version)
- Ultima III (1985 Origin Systems version)

Apparently there's a problem with the COPYLOCK protection method. I don't know whether it's because of Teledisk or PCE. I noticed that there are no COPYLOCK-protected games listed here. From debugging the copy protection code, I don't really know what's going on there: it reads a certain sector using Int13, expecting that to fail with "sector not found", then reads the exact same sector by writing directly to the floppy controller using the standard sequence of command bytes, and then for some reason the sector can be read after all. I speculate that this is due to the sectors not being ordered sequentially (e.g. 1-2-3-5-6-7-8-9-4), with BIOS stopping the read operation once it encounters a higher number than the one requested.

Well, there is still the whole preservation aspect.

that doesn't need Dosbox support

True enough, but keeping two different images from the same game - one for preservation, one for playing - feels awfully suboptimal, especially if the only reason is that no agreement on licenses can be reached.

If I read correctly, given that PCE does support TeleDisk and the floppy controller and is licensed under GPL, its code could be reused for DosBox, could it not?

They would love if more and more emulators would support their proprietary file format which only they can generate from user submitted data.

I can sort of understand why they do that. If they made their "ultimate preservation format" completely open, some jackass would just convert an old bad dump to IPF, which then gets spread so no one will bother imaging his good original medium any more, assuming it has already been preserved. I've seen that happen with some idiots releasing supposedly pristine .flacs that in reality were just converted .mp3s.

Last edited by NewRisingSun on 2013-05-03, 16:40. Edited 2 times in total.

Reply 29 of 70, by robertmo

User metadata
Rank l33t++
Rank
l33t++
P4R4D0X wrote:

Anyway by looking at the last DOSBox SVN commit is from more than a month, let alone the DOSBox 0.74 is from 2010. 😒

I see some annual similarity 😉
2012-05-20 18:41 qbix79 * [r3780]
2012-03-28 15:26 qbix79 * [r3779]
2012-01-27 19:09 qbix79 * [r3778]
Though this year it still looks way more active for now 😉

Reply 30 of 70, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

I have now taken a closer look at both the Teledisk and Kryoflux images of Ultima II (1984 Sierra On-Line version) to find out why the Teledisk image doesn't work in PCE, to answer Great Hierophant's question about whether there are games with copy protection that the Teledisk and similar formats can't handle.

Quick background on how the copy protection works: the main executable ULTIMAII.COM (turned into an .EXE file for the 1989 Origin release) has its first 16 bytes replaced with a jump to the copy protection checking routine. That one tries to read cylinder 20 sector 5 (head 0 since it's a single-sided disk) using interrupt 0x13, expecting failure with an error code of 0x04 (sector not found). It then programs the floppy controller directly using the "Read Track" command (0x42), requesting cylinder 20 sector 1 sectorsize=512 as a start point. The floppy controller then reads and sends the data for cylinder 20 sector 5 (?!?!), which contains, among other things, the original 16 bytes from the start of ULTIMAII.COM, which are put there and given control, thereby starting the game.

I was at first puzzled why reading the whole track 20 from sector 1 on could possibly return this hidden sector 5. Then I read how the "Read Track" command actually works: unlike the "read sector" command, it ignores the requested sector ID and just reads whatever data is at the current head position, which happens to be the hidden sector.

I then used Kryoflux to image the raw data, then KFAnalyze to see how the track is actually laid out. The result:

GAP1 145 bytes length=4638.33 us
-----------+------------------+-----------+---------------------------+------------
GAP2 |ID |GAP3 |DATA |GAP4
Bt Lgt |Sct Pos Lgt CRC|Bt Lgt BS|Bt Lgt CRC TMV BRD Clk |Bt Lgt BS
-----------+------------------+-----------+---------------------------+------------
15 459 |1 5098 223 OK |37 1177 0|515 16446 OK 0 0 3.99|80 2555 0
15 476 |2 25978 226 OK |37 1179 0|515 16408 OK 0 0 3.98|81 2556 1
15 458 |3 46807 222 OK |37 1181 0|515 16403 OK 0 0 3.98|80 2546 0
15 476 |4 67638 225 OK |37 1176 0|515 16396 OK 0 0 3.98|80 2552 0
15 474 |5 88464 223 BAD|37 1179 0|515 16363 ? 0 1 3.97|81 2566 0
15 465 |6 109262 224 OK |37 1168 0|515 16307 OK 0 0 3.96|80 2531 0
15 472 |7 129966 221 OK |37 1172 0|515 16312 OK 0 0 3.96|80 2534 0
15 472 |8 150680 222 OK |38 1173 1|515 16388 OK 0 0 3.98|988 31511 0
-----------+------------------+-----------+---------------------------+------------

So sector 5's sector ID (not the sector's data) has a bad CRC. The dump of the sector ID shows:

= ID=5 7 bytes @88464 length=223.75 T=20 H=0 S=5 Z=512 CRC=e60b *** BAD *** TMV=0 BRD=0 BS=0
0ad9 88464 3938 fe 14 00 05 01 e6 0b .......

Whereas normal sector IDs look like this:

= ID=3 7 bytes @46807 length=222.85 T=20 H=0 S=3 Z=512 CRC=7d5b OK TMV=0 BRD=0 BS=0
05bd 46807 3938 fe 14 00 03 02 7d 5b .....}
= ID=4 7 bytes @67638 length=226.00 T=20 H=0 S=4 Z=512 CRC=e4cc OK TMV=0 BRD=0 BS=0
084b 67638 3938 fe 14 00 04 02 e4 cc .......

Even though sector 5 is actually 512 bytes large (sector size code should be 2), it is incorrectly denoted as being 256 bytes large (sector size code=1). Because of the incorrect sector ID (Int13 looks for 14 00 05 02 instead of 14 00 05 01), Int13 reports "sector not found" and returns to the calling program with the read/write head placed directly after the sector ID; the copy-protection code then issues "Read Track", which just reads whatever comes regardless of the sector ID, which is the data for sector 5.

Normally, Teledisk (and Dave Dunfield's ImageDisk) aren't fooled by this and automatically adjust themselves to different sector sizes. In this case, they don't, because the sector ID's CRC is incorrect as well, causing them to just ignore sector 5, falsely claiming there's a "gap" between sectors 4 and 6. Even if they didn't ignore it but instead adjusted themselves to a sector size of 256 bytes (because of sector size code 1), the image would still be broken, as the actual sector size is 512 bytes and the useful information is cleverly placed in the second half of the sector.

This was probably more detailed than any of you wanted to know. So the short answer is: no, Ultima II (and other games using the same protection method) can not be imaged with the TeleDisk or ImageDisk utilities. I can try and see if Anadisk is any better, although I doubt it.

Reply 31 of 70, by BigBodZod

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

This was probably more detailed than any of you wanted to know. So the short answer is: no, Ultima II (and other games using the same protection method) can not be imaged with the TeleDisk or ImageDisk utilities. I can try and see if Anadisk is any better, although I doubt it.

I quite enjoyed that read, reminds me of the old C64 and Amiga days of hacking copy protection schemes 😉

No matter where you go, there you are...

Reply 32 of 70, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
VileRancour wrote:

Even if IPF support was added to DOSBox tomorrow, you'd still need to go through the SPS to get your Kryoflux dumps converted. Besides the fact that they're limited in time and manpower, they quite openly state that they won't bother with anything that doesn't meet their project's goals. IIRC, the criteria are rather stringent - "pristine and unmodified" means that something as trivial as saved high scores renders the image unfit for preservation. Never mind that, in many cases, simple common sense can be enough to correct tiny imperfections like that.

That's probably the right approach for the SPS's own stated goals, but not necessarily for yours (just playing your game in DOSBox).

As it was explained to me when I first got my kryoflux up and running... Once disk images start coming in, a modified (ie save games, high scores saved, etc...) image comes in, they use it as "proof of ownership" and send the archived IPF of that disk to the person that sent it in. If there isn't an IPF of that disk in the archive, they convert it anyways and send the "bad" IPF to the user (marked as non-archived,) and save it in a temp status. Any future dumps from other users of that disk will be compared to the temp archive and the best one saved. When a pristine version comes in, it is placed in the permanent archive and then sent to all of the people that sent in non-pristine versions. At least that is how I read the e-mail they sent me. So far, I have gotten rather quick responses from dumps I've made. OK, I only made one dump before I had to pack it up for my move. All of my floppies were packed up and in climate controlled storage except one. But I got the IPF for that back in about 4 days. Could have been one that was already archived, which might have made it faster.

Feeding Dragon

Reply 34 of 70, by VileR

User metadata
Rank l33t
Rank
l33t
P4R4D0X wrote:

Clearly their license is just a really bad choice.

Having read through that entire(!) thread on the KryoFlux forums about licensing... what makes you say that about the MAME license?

P4R4D0X wrote:

You can't generate your own .IPF files even if you have a KryoFlux, you can write them to disks but not create them. That's just wrong! The only way to obtain these is by uploading them to their FTP server and the guys at SPS will create you the files.

So they are clearly doing this to sell more and more KryoFlux boards and to have more and more stream data and .IPF dumps.

I sort of doubt that. The problem with letting everyone generate their own .IPF files seems to be that this process cannot be automated - they don't have a single method that will work for every disk, and (at least for now) they need to manually process each KF stream dump, which requires knowledge that the overwhelming majority of users don't have.

The SPS calling the shots on .IPF creation may be bad for our purposes (availability), but for preservation of 100% pristine original data and avoiding user error, I can't really fault that. And in general agreement to the rest of your post, DOSBox doesn't really need IPF support... there's the downside of bad or incomplete dumps floating around, without most people even realizing that some esoteric functionality is missing, but the overwhelming majority of these cases can be fixed in other ways.

NewRisingSun wrote:

If I read correctly, given that PCE does support TeleDisk and the floppy controller and is licensed under GPL, its code could be reused for DosBox, could it not?

I don't see any problem with that (certainly wouldn't object to it happening). Appreciate the analysis of Ultima II's protection, by the way.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 35 of 70, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

It seems there are two completely different protection schemes called copylock. The scheme that NWS described revolves around fiddling with sector IDs, sizes and CRCs. The better known protection from Rob Northern is also known as Copylock and uses long sectors written to with a shortened bit cell clock. However, it may have been impractical to use on a PC as opposed to an Atari ST according to this document : http://info-coach.fr/atari/documents/mydoc/At … -Protection.pdf

NewRisingSun has identified a weakness in the teledisk/imagedisk implementation, and for those Sierra titles he listed, those formats will not properly replicate the protection used. Perhaps the transcopy img format may have to be implemented instead if ips is not to be supported. Of course, The Computist #63 has a softkey (crack) for the older .com version of Ultima II (which will probably also work with III and the other games with minor adjustments).

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 36 of 70, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Copylock for the Amiga and Atari ST by Rob Northen computing was first used in 1987. Copylock for DOS by "Cops" was first used in 1984. Given the very generic name, I agree that they were most certainly two entirely different products.

The Computist #63 has a softkey (crack) for the older .com version of Ultima II (which will probably also work with III and the other games with minor adjustments).

It won't work with III, as that one also uses anti-debugging traps and self-encryption, rendering the described approach of loading up the .COM file in DEBUG and setting a breakpoint right after the hidden sector has been read futile, at least for the novice hacker with DEBUG. The article also mentions that this process won't work with .EXE files because DEBUG can't write them or set breakpoints in them. Most Sierra games with Copylock protection use .EXE files for the main program.

Obviously, the Copylock version used in Ultima III is an updated one, as seen from the signature in the disk's very last sector:
"524-038C IBM-PC (NM,8/512) COPYLOCK 2.2 DUP 5"-48/40 2S DD 31323-03"
whereas Ultima II reads:
"552-022 IBM-PC (8,NO-MAG) COPYLOCK DUP 5"-48/40 1S DD SS 30468-02"

Jean Louis-Guérin is about to release "soon" (last updated in August 2012) a library that decodes raw Kryoflux streams, under the GPL license. That format has the advantages that it's current and still supported, can be created by the average user (willing to invest 100 dollars) with no editing, and can definitely support any disk. It's of course complicated due to its low-level nature, but if existing decoding code can be used, the effort should be managable. One further disadvantage though is that every track is stored as a separate file.

Reply 37 of 70, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
NewRisingSun wrote:
Copylock for the Amiga and Atari ST by Rob Northen computing was first used in 1987. Copylock for DOS by "Cops" was first used i […]
Show full quote

Copylock for the Amiga and Atari ST by Rob Northen computing was first used in 1987. Copylock for DOS by "Cops" was first used in 1984. Given the very generic name, I agree that they were most certainly two entirely different products.

The Computist #63 has a softkey (crack) for the older .com version of Ultima II (which will probably also work with III and the other games with minor adjustments).

It won't work with III, as that one also uses anti-debugging traps and self-encryption, rendering the described approach of loading up the .COM file in DEBUG and setting a breakpoint right after the hidden sector has been read futile, at least for the novice hacker with DEBUG. The article also mentions that this process won't work with .EXE files because DEBUG can't write them or set breakpoints in them. Most Sierra games with Copylock protection use .EXE files for the main program.

Obviously, the Copylock version used in Ultima III is an updated one, as seen from the signature in the disk's very last sector:
"524-038C IBM-PC (NM,8/512) COPYLOCK 2.2 DUP 5"-48/40 2S DD 31323-03"
whereas Ultima II reads:
"552-022 IBM-PC (8,NO-MAG) COPYLOCK DUP 5"-48/40 1S DD SS 30468-02"

Jean Louis-Guérin is about to release "soon" (last updated in August 2012) a library that decodes raw Kryoflux streams, under the GPL license. That format has the advantages that it's current and still supported, can be created by the average user (willing to invest 100 dollars) with no editing, and can definitely support any disk. It's of course complicated due to its low-level nature, but if existing decoding code can be used, the effort should be managable. One further disadvantage though is that every track is stored as a separate file.

Is Rob Northern's Copylock feasible on the IBM PC? This document suggests that it is not, due to the far lower tolerances the NEC 765 (+/-2%) allows in rotation speed vs. the WD1772 (+/-5%) FDCs : http://info-coach.fr/atari/documents/mydoc/At … -Protection.pdf

I have seen many Computist cracks where the instructions require you to rename an .exe file to another extension and then use DEBUG to insert edits to the file. Apparently this issue of DEBUG refusing to work with .exe files was never fixed.

Your version of Ultima II from Sierra On-line for the PC seems to be slightly later than its original release, which should be in 1983. Did it come in a big box, a black box, a gray box? Large or small map? I wonder if the first release (probably with the strength bug) used Copylock. I assume it did not use Spiradisk.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 38 of 70, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Your version of Ultima II from Sierra On-line for the PC seems to be slightly later than its original release, which should be in 1983.

The label says "© 1983", but I just assumed it is from 1984 because of the Copylock issue. The files themselves have 1980 dates (i.e. they did not bother to set their PC's clock.)

Did it come in a big box, a black box, a gray box? Large or small map?

gray, small.

I wonder if the first release (probably with the strength bug) used Copylock

How do I check quickly if mine has the strength bug? I have only seen two versions of the Sierra version, mine being the earlier one, with a later one having the same unprotected image, but a slightly updated copy-protection checking code that adds compatibility for the DMA-less PCjr.

I assume it did not use Spiradisk.

Yes, I don't think you can apply a GCR-system based method to a MFM-based system like the PC. Sierra's earliest PC titles merely used different sector sizes than 512. For example, "Adventure in Serenia" is available as a well-working Teledisk image.

Reply 39 of 70, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

There is no easy way to find out unless you hack your character with some gold and blue tassles, find a ship and go to New San Antonio in 1990 and bribe the hotel clerk enough times to come to a reasonable conclusion that your strength is never being raised. Hacking info is at the end of this document : http://www.gamefaqs.com/appleii/582346-ultima … ress/faqs/20699 and the bug fix for the Apple II version is found here : ftp://ftp.apple.asimov.net/pub/apple_II/image … ma_II_Fixed.txt

I would suggest that the version that adds pcjr. compatibility probably fixed the strength bug. The bug was not unique to the Apple II, as demonstrated here : http://www.atarimania.com/game-atari-400-800- … ma-ii_5593.html (The Book of Atari Software blurb). I can find no complaint regarding the C64, Atari ST or Macintosh versions Sierra did.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog