VOGONS


Copy Protection & Image Formats

Topic actions

First post, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

First, there are other threads that deal with what I'm bringing up, but the ones I found are several years old. And while my Swiss Cheese memory is preventing me from finding the rules (the FAQ is the first place I looked, and I must be blind because I can't find them now,) I do remember that I'm not supposed to "bump" threads that are too old. Also, I thought it might be handy to put several of them in one place.

As stated in other threads, I am in the process of re-imaging my floppy collection. This includes imaging new purchases and those disks I hadn't yet imaged. Now, not being able to write some back, at this time, isn't that much of an issue for me. Most of the copy protected SW in my collection are ones that I would run in DOSBox anyways (as I don't plan to have 5-6 different systems just to play these on original HW.) I'm pretty much finished building a system for running those that don't require specific HW (such as a CGA card with composite monitor,) and aren't speed reliant. The rest are for DOSBox, and so far every disk I have that is copy protected will need to be run in DOSBox. Eventually, I will get my Kryoflux up and running, and these will be re-imaged once again so that they can be written back if necessary.

Also, while I only have a few games so far that are copy protected on the disk, a brief search on the internet shows that there are a fairly large number of games that are thus protected. So the answer I've received in the past (on non-related issues,) to look for game specific fixes is not really all that viable. This would require many such fixes. Just looking through a few searches of "cracks" that involve key disks, I would hazard to say that the number is probably in the 100's. Currently, I would have to "crack" my games just to play them. Since DOSBox doesn't support "cracking" and doesn't support the protection, these game versions "officially" aren't playable in DOSBox. (Thinking of Ultima 2 in this case, of which I actually own 3 versions - The floppies, Ultima I-VI CD, and Ultima Collection CD.)

The problem arises that I cannot find instructions on converting the image files I can create to a format that DOSBox can read that retains the copy protection in most cases. Well, in all cases that I, personally, have come across. I'm not downloading images, and I don't know how the images I've read about that do work in DOSBox, are made, and can't find instructions on how they were made. I now have a file that defines the TD0 format, so I should be able to write my own converter to make IMG files with them. The available converters I have fail with the copy protected disks. The problem is, this will only work with those that don't involve intentional disk errors, variable track/sector sizes or densities (such as Ultima 2's Track 6 that has sector 1 size of 8192 bytes,) and maybe others. Though, making "all" sectors 8192 bytes might make it "workable," (other than the intentional error on the same disk,) at the expense of making the file 16 times larger.

DOSBox does have a method for handling "some" of these. Those that can be converted to raw IMG format without losing the protection. Even those that aren't booters can be handled (I think, I don't have any to test, and I'm not ready to "download" them even for testing purposes.) That would be to create a basic bare boot disk, then boot to that image and the game disks to follow - "BOOT bootdisk.img windwalk.img" for example (WindWalker is a non-bootable key-disk protected game I think.) After all, that's how those games were meant to be played on real hardware anyways.

But that leaves the many others that can't be converted to a RAW format. For these, DOSBox would need to either support another image format or add in the ability to use the raw format with an "info" file. Much like the C64's D64 file can have an "error" block added on for the image. I've only read part of the TD0 format, and something similar to that might be feasible. Though even with "normal" compression, it would have to be expanded out a bit to allow writing to disk. A converter routine (I'm actually in the process of experimenting with writing the routine already,) could take the "headers" the format uses, and put them all into a separate file. Allowing the raw data to just be laid out as it is in an IMG file. The info file would then tell the reading software that sector x is actually 1024 bytes long, etc... In the case of the Ultima 2 floppy, this would lead to some duplication as Track 6, Side 0, Sector 1's 8192 bytes includes all of Sectors 2-8's 1024 bytes of data (along with the first 1024 bytes of Sector 1,) strung together into 1 long string (overlap.) Though that could be corrected if you add in an "offset" value into the header information.

The layout of the info file could look something like this (a work in progress, quickly slapped together on the fly:)

It exists at all, so DOSBox uses it as a "key" to the raw IMG file.

  • Track 0 Info
    • Number of Sides (2 bit)
      Number of Sectors (6 bits)
      Sector 0 Side 0 Info
      • Offset in IMG file (3 bytes)
        Track ID (1 byte)
        Side ID (1 byte)
        Sector ID (1 byte)
        Size of Sector (2 bytes)
        Flags (1 byte)

Everything except the Offset would be straight from the TD0 file. The offset would be calculated as the file was converted. Though I would sort of want to know how a normal raw IMG was laid out so I could match it. Is it track (0-x) Side (0-1) Sector (0-y), or is it track, sector, side? With this information, the info file would max out at 26K, at a guess. With a simple converter, you would have the duplication I mentioned above, and wouldn't really need the 3 Offset bytes. A more intelligent converter "might" be able to detect the overlap. I'd really need to read more of how the TD0 file stores this. Examining and working with multiple images might answer those questions for me as well.

As for what DOSBox would need to do. Look for the info file, then when the game reads the disk, use the info file to generate errors and give the game the data it reads. From what I'm reading, you can't just use a TD0 file, as it will sometimes "not" create the sector data information, because the original disk doesn't have any data there. But, that doesn't stop the game from "adding" data to that area later (save games, flags, hi scores, etc...) Problematical without having DOSBox pause to recreate the entire image (or the image from that point - which could be track 0, sector 0, side 0 AFAIK - onward.)

I don't have a complete list of all the games that have copy protection of this nature. I do know that cracking programs have lists that are rather sizable, and not all games have cracks. I'm willing to wager, that there are quite a large number of games that don't have cracks. There are also a fairly large number that don't have alternate versions. Though, admittedly, many that don't have either probably don't have very many copies out there in service. I do remember, though I don't have access to them right now, that back in the day there were games that I detested because I hate playing on originals, and nothing I could do would allow me to get away from that. That was pre-internet, but I was active on quite a few BBS servers, even to spending a few dollars every so often to call long distance to find what I needed. I also never hesitated to order parameter utilities from magazines (again to get away from using my originals.)

Feeding Dragon

Reply 1 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:

Are you creating a database of these problematic disks or are you too busy to assemble all the necessary information on these disks?

I can create a database if you want. I'm not really busy, I have several projects I'm working on at any given time (desperately need distractions,) but I've just finished one, so that isn't a problem. Would you prefer I post it in stages, or wait till I'm finished (the later could take months.) Hmm.. I'll use this post as the location, and add to it as I get information. Do you have a preferred format? Raw txt, Excel, Access, Word (office 2010?) I'll start with raw text, as it is easiest right now. I'll add to it as people donate information, I find confirmed information on the internet, or I find more of my floppies for testing. My old archive (on CD & DVD,) are images that only tell me if a given game "has" protection or not, not whether they will or will not work in DOSBox (through direct experience.)

Feel free all to post information, or PM me information if you prefer. I'm not yet ready to download files just for testing. Mainly because I'm on my sister's internet and she's paranoid about "big brother" arresting everyone in the house if I did.

Attachments

  • Filename
    CP Games.txt
    File size
    4.81 KiB
    Downloads
    320 downloads
    File comment
    Current copy protection Methods & Games
    File license
    Fair use/fair dealing exception
Last edited by FeedingDragon on 2015-02-20, 22:52. Edited 2 times in total.

Feeding Dragon

Reply 2 of 81, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Some physical protection checks can work with standard images, namely those that try to verify unusual sectors, because DOSBox reports success for any sector being verified; but it's a small subset of protected games that are so simplistic.

TeleDisk format does not support all protection methods, most notably weak bits. TransCopy format (originally from the Central Point Option Board) is reasonably complete, without resorting to the overkill of KryoFlux raw format.

But for DOSBox to cover all the bases, FDC and related BIOS emulation would be needed in addition to support for protection-capable image formats.

Reply 3 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote:

Some physical protection checks can work with standard images, namely those that try to verify unusual sectors, because DOSBox reports success for any sector being verified; but it's a small subset of protected games that are so simplistic.

TeleDisk format does not support all protection methods, most notably weak bits. TransCopy format (originally from the Central Point Option Board) is reasonably complete, without resorting to the overkill of KryoFlux raw format.

But for DOSBox to cover all the bases, FDC and related BIOS emulation would be needed in addition to support for protection-capable image formats.

I didn't know that TeleDisk couldn't detect weak bits. Unless it's totally different than other systems, it's ridiculously easy to detect. It's also very easy to emulate (random number generation.) Writing it onto a physical disk is where you have problems. It can be done if you have extremely low level access to the drive, though.

My original post is probably too simplistic. I wish I could find a listing of the different methods used on the PC, I would be able to work things out a bit more, in theory at least. I'm not a good enough programmer to figure out exactly how DOSBox is doing things now 🙁 or I might be able to be more precise. Giving more thought to it, and please remember that I just took an extra sleeping pill because my normal dose wasn't helping enough (I do have a doctor's permission for doubling up,) there may need to be at least a simple emulation level. Something that would take the re-programmed access code (taking over INT 13 for example,) and use what it gives to know "where" on the image/info file to look, and know how to feed the information back to the replacement code. I'm fairly certain, for instance, that Ultima 2 reprograms the disk access routines, as after it fails to run "pleas run from original disk only," all my floppy access commands stop working with "Drive not read" messages.

As for the KryoFlux, it's not all that expensive. At least compared the cost of some of the other options. Approximately half the price of a deluxe option board for example (based on "sold" listings on eBay.) Another board I don't remember the name of, but it had only a "read" option, was near 5 times the cost of the KryoFlux. So, it isn't that bad. Of course, in of these boxes around here, I already have one with a very compatible 3.5" drive and a modified 5.25" drive to go with it.

Feeding Dragon

Reply 4 of 81, by truth_deleted

User metadata

Perhaps start with a set of games which share a simple copy protection scheme and test with PCem (has BIOS and satisfactory FDC emulation) and vanilla dosbox. There is also a floppy drive emulator to explore those other formats: http://sourceforge.net/projects/hxcfloppyemu/.

Reply 5 of 81, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Although PCem can accept TransCopy format images, it does not emulate it well enough for the Cops Copylock I protection which is used by pre-1985 Sierra On-Line titles. (The games will work when manually converting them to PCem's .PSI format, and even then only when manually helping it by specifying a command-line option.)

Basically, the following protections' checking code only use Int13 and thus could easily be faked by DOSBox given proper information:
- anything merely using sector sizes other than 512
- H.L.S. Duplication (Accolade/Epyx games)
- generic "weak bits" (special Radio Shack releases of pre-1985 Sierra On-Line games)
- Softguard 2.0.3 with Sierra On-Line's custom loader (basically anything from Sierra with a CPC.COM file)
- EA Interlock (Electronic Arts booters)
- XELOK/XEMAG (Broderbund, 1987/Ultima 1-3 trilogy version Ultima III)
- "Minder03" (used by Prism Software and at least one European release of Pipe Mania). This one also checks that Int0E has been properly triggered after a read operation.
- Origin Systems' OSI-1 (used by all .EXE file-based Origin Systems games)

The following on the other hand access the floppy controller directly and thus would require DOSBox to add hardware-level emulation of the floppy controller:
- Cops Copylock I (1983-1985 Sierra On-Line releases, 1984/1985 versions of Ultima III)
- On-Line Systems Protection #1 (Ulysses and the Golden Fleece, Frogger)
- Softguard 2.x/3.x with original loader (file CMLxxxx.FCL present, 1985 version of Ultima II, Taito games)

Undetermined:
- MicroProse games
- Lemmings 1/2, Mindscape

FeedingDragon wrote:

I didn't know that TeleDisk couldn't detect weak bits. Unless it's totally different than other systems, it's ridiculously easy to detect.

But it's not easy to tell whether bits that change from read attempt to read attempt are supposed to change or whether the disk is just bad.

FeedingDragon wrote:

It's also very easy to emulate (random number generation.)

Prism Software has a keydisk code that reads the same sector several times but expects it to change in a deterministic fashion. So it's not always that simple.

Personally, I'm a great fan of TransCopy as well as Snatchit for Copy II PC, and I don't like TeleDisk and .PSI. Why? Because the former are track-based, while the latter are sector-based. Many protection schemes are based on overlapping sectors or sector IDs inside the data section of another sector. Sector-based formats therefore duplicate a lot of information (a great lot in the case of EA Interlock, which puts 90 sector IDs into one track), while track-based formats retain the original overlapping structure.

Reply 6 of 81, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

All the Sierra games non-booter protected AGI games, and Thexder and 3-D Helicopter Simulator, have their encryption keys made available. With the key, the loader can be cracked.

Its usually the odd game or the odd version that cannot be cracked with information from textfiles or the standard cracking programs.

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

Reply 7 of 81, by collector

User metadata
Rank l33t
Rank
l33t

NRS, any thought about the KryoFlux? I have been toying with the idea of getting one.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 8 of 81, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

I recommend it because 1) there are tools available to convert Kryoflux streams into TransCopy, TeleDisk and any other image format except .IPF, 2) it can now write back raw stream files.

GH: The key read by CPC.COM is the same across all games, just the starting offset varies. The starting offset can be deduced from knowing that the encrypted .EXE file, like all .EXE files, always starts with "MZ". And I think the point here is to run games in their original form.

Last edited by NewRisingSun on 2014-12-19, 19:05. Edited 1 time in total.

Reply 9 of 81, by collector

User metadata
Rank l33t
Rank
l33t

I also came across DiscFerret, which seems to take the same approach, but is not quite done and is a bit more expensive. Their site is WikiMedia based, which seems to be currently broken. http://www.discferret.com/wiki/DiscFerret

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 10 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:
FeedingDragon wrote:

I didn't know that TeleDisk couldn't detect weak bits. Unless it's totally different than other systems, it's ridiculously easy to detect.

But it's not easy to tell whether bits that change from read attempt to read attempt are supposed to change or whether the disk is just bad.

Ok, I'll rephrase a little: Ridiculously easy to detect on a known good disk 😀

NewRisingSun wrote:
FeedingDragon wrote:

It's also very easy to emulate (random number generation.)

Prism Software has a keydisk code that reads the same sector several times but expects it to change in a deterministic fashion. So it's not always that simple.

First, I did specify that I'm working off information based on another system and the PC might be a little different. Second, if it works the same, then the specific changes depend on what level the emulation is working on for the random generation. The way I understand weak bits, it refers to individual "bits" of data read (0 or 1.) Even the individual bits of data to be read are "padded" a bit because the reader has to have a change in the level every so often. So to read a single bit you would have to have something like 0101'x'0101 where 'x' would be the actual bit to read. A weak bit would actually be written as xxxx'x'xxxx (all values the same.) In this case the value of 'x' would be random every time it was read. So, if only bits 7, 3, & 2 are "weak" in a given byte, then only those bits would change from read to read. A simple generator would just generate the full byte every time, a better one would correctly only generate the 3 bits randomly. The original "info" file I specified wouldn't be able to handle that without also providing a "map" of each byte that contains weak bits. And example of the map might be:

if "Flags" indicates weak bits:

  • Number of bytes that have weak bits (2 bytes)
    • byte number (2 bytes)
      byte map (1 byte) <0 = normal, 1 = weak>

As for everything else... Cool, thanks for the information 😀 I don't know which versions of Ultima 2 & Ultima 3 I have as I don't have the box or manuals (just the floppies.) I know the version of Ultima 1 (v1.28) only because it's marked on the label. On these disks Ultima 1 & 2 use the same copy protection method (I can give very specific details on those because I found them with a search.) Both have an altered track 6 side 0, with the overlap I mentioned above. First, each sector is 1024 bytes. Sector 1 is 8192 bytes (but overlaps sectors 2-8,) and reports a CRC error. That's what the web says.

Ultima 3, however, is different. In this case the protection is on track 9 side 0. Based on the read, it has 16 sectors instead of 8 (320k disk.) From reading the small amounts of data I have access to (on converting non-standard disks,) it might be possible to create an IMG by just making all tracks 16 sectors, and just padding the extra sectors with 00's for all except track 9 side 0.

I don't "currently" have access to my other "known to be protected" floppies. They are either in storage, or in one of the boxes here that I haven't gotten to yet.

collector wrote:

NRS, any thought about the KryoFlux? I have been toying with the idea of getting one.

I have one, and I even managed to get a modified 5.25" drive for it (so it can read flippy disks.) I don't currently have it hooked up, though, it's in a box somewhere. Either in storage or in one of the ones I haven't gone through yet. From what people have been reporting, it works very well. I read in one post or another that it cannot handle weak bits, but according to quite a few other places, it actually can. It might depend on the model of drive you are using.

Feeding Dragon

Reply 11 of 81, by truth_deleted

User metadata

It may be useful to choose a couple of int13 based copy protection schemes (see above post by NRS) and modify dosbox code so that these schemes are detected, along with logging of information which is relevant to detection. Detection may not be 100% reliable, but at least it would provide documentation and future path to implementing non-FDC schemes. It would also allow testers some additional information to store in a database of these copy protected games (and in some cases the code could be easily modified to expand detection). I wouldn't think that every copy protection scheme is necessary to implement, but perhaps a few of them are more relevant to the goal of preservation.

Reply 12 of 81, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
FeedingDragon wrote:

I know the version of Ultima 1 (v1.28) only because it's marked on the label.

Oh? Care to show a picture of the disk label? I don't think I've ever seen that. What is the date of ULTIMA.EXE?

FeedingDragon wrote:

On these disks Ultima 1 & 2 use the same copy protection method (I can give very specific details on those because I found them with a search.) Both have an altered track 6 side 0, with the overlap I mentioned above. First, each sector is 1024 bytes. Sector 1 is 8192 bytes (but overlaps sectors 2-8,) and reports a CRC error. That's what the web says.

That's OSI-1.

FeedingDragon wrote:

Ultima 3, however, is different. In this case the protection is on track 9 side 0. Based on the read, it has 16 sectors instead of 8 (320k disk.) From reading the small amounts of data I have access to (on converting non-standard disks,) it might be possible to create an IMG by just making all tracks 16 sectors, and just padding the extra sectors with 00's for all except track 9 side 0.

That's XELOK. It's already fooled by copying the game to a 1.44M disk, which always has 18 sectors per track.

Logging which sectors are accessed will not work without a complete emulation, as a keydisk check will check several sectors in succession, and if the first read does not return what is expected, you are not going to get to the later checks. By the way, I got PCem and PCE mixed up in the previous post. I was talking about PCE supporting TransCopy image, not PCem.

Implementing hardware-level FDC emulation and TransCopy/TeleDisk image support into DOSBox will probably easier, and legally less problematic, than writing protection-specific workarounds into the Int13 emulation, because both FDC and TransCopy image support have been coded for the PCE emulator licensed under GPL. They merely would need to be adapted for DOSBox. I don't think I could do that myself though as that would require more familiarity with the way DOSBox interfaces things like DMA, IRQ, mounted image files, real-time events such as a disk motor starting to spin etc. than I have.

Reply 13 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:
FeedingDragon wrote:

I know the version of Ultima 1 (v1.28) only because it's marked on the label.

Oh? Care to show a picture of the disk label? I don't think I've ever seen that. What is the date of ULTIMA.EXE?

The date of the EXE is 12/29/87

u1-disk.jpg
Filename
u1-disk.jpg
File size
79.95 KiB
Views
7336 views
File license
Fair use/fair dealing exception

Feeding Dragon

Reply 14 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:
FeedingDragon wrote:

Implementing hardware-level FDC emulation and TransCopy/TeleDisk image support into DOSBox will probably easier, and legally less problematic, than writing protection-specific workarounds into the Int13 emulation, because both FDC and TransCopy image support have been coded for the PCE emulator licensed under GPL. They merely would need to be adapted for DOSBox. I don't think I could do that myself though as that would require more familiarity with the way DOSBox interfaces things like DMA, IRQ, mounted image files, real-time events such as a disk motor starting to spin etc. than I have.

I was more thinking on the lines of adding to the code instead of re-writing the code. If the second file exists, use the detailed information instead of just the raw data. The information would be more along the lines of "how" to read the data (errors, variable density, alignment, etc...) and not a case of specific protection coverage. My personal knowledge of how on disk protection works is all centered around the C64 & Apple II computers, so I know things like spiral streams, fat tracks, half tracks etc... Most of it is based on the fact that end-user controllers can read information that they are incapable of writing. This is why, with some protections, you have to have specialized HW (replacement controllers,) to write the information back to disk.

Since we are dealing with images (and not physical disks,) things actually become simpler (in a way.) First you have to get the actual data that would be read - that's what goes into the raw IMG file. Don't need to change anything there, and many booters will work just fine with DOSBox as the code stands (don't want to break anything here.) Add in a single trigger to the code that looks for the info file, and if its there, bring in a separate emulation that loads it and uses the information. There are only so many ways to read a disk, the most basic of which, from what I understand, uses port reading & writing. If you understand how the controller works, you can use the information to know what to put where for when the ports are read. I haven't done much (ok, I haven't done any,) low level programming work with the floppy controller, so I don't know the details there. I have done such work with other devices though (PC Speaker, Sound Cards, some Video work.) I know that Ultima 1 & 2 re-write the normal disk access routines, but the re-written routines would still need to go through the hardware ports to get anything done. So it's at the port level that the information would need to be used.

That's the way I see it, and I haven't done a lot of research there yet. However, I'm more than willing to admit that I could be mistaken about some of the details. It all boils down to how DOSBox handles hardware ports. The work I have done with port programming, I have done in DOSBox (for writing & testing the code.) So I know that DOSBox already has at least some port handling. But does it handle any of the floppy controller ports? How does it handle those ports? That is the sort of information that I don't know, yet 🙁

Feeding Dragon

Reply 15 of 81, by truth_deleted

User metadata

Codeholio has partially completed his FDC emulation for dosbox-x. I thought it may be possible to implement an int13 copy protection scheme in the meanwhile, but perhaps creating a database is a better use of time. However, at some point a request could be made to Codeholio for the extensive logging of FDC commands.

Is the PCem/FDC emulation complete enough for the copy protection schemes used in PC formatted diskette images? At least this could be tested for compatibility, and if it is compatible, then logging could be added to PCem. Also, the MESS forum has a post about TeleDisk support. It's not complete, but it is recent in origin, and should be portable enough to test in PCem (even if just to test in a private build).

As an aside, that Ultima I diskette must have come from a trilogy pack or the like, given the recent date on the file.

Reply 16 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:

As an aside, that Ultima I diskette must have come from a trilogy pack or the like, given the recent date on the file.

That wouldn't surprise me. I never had the first releases of Ultima for anything other than the C64. It was only later that I started getting the games for the PC and I might have bought the trilogy pack as a shortcut to getting more at a time. I know I have the floppy versions of just about all of them. I think I might be missing a couple of them, but not sure which, if any. So far, I've only found 1, 2, 3, & 7a. None of which are actually on the archive CD I've actually found.

Feeding Dragon

Reply 17 of 81, by truth_deleted

User metadata

I would bet that the original Ultima I is a rarity, and it must have targeted few systems on its so-called release date.

Edit: wikipedia sort of confirms this. It notes that Ultima I was eventually re-coded for a wide release, and that must be the copy that is typically owned. The original version must have arrived in a ziploc plastic bag instead. 😀 Wikipedia does confirm that it was Apple II only on release, although the author of the article has sales numbers which seem too generous.

Reply 18 of 81, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:

I would bet that the original Ultima I is a rarity, and it must have targeted few systems on its so-called release date.

Edit: wikipedia sort of confirms this. It notes that Ultima I was eventually re-coded for a wide release, and that must be the copy that is typically owned. The original version must have arrived in a ziploc plastic bag instead. 😀 Wikipedia does confirm that it was Apple II only on release, although the author of the article has sales numbers which seem too generous.

Ultima (the original title for the Apple II only original Ultima 1 version,) was professionally produced by ... Ok, can't remember the name now 🙁 But it was before Richard Garriot (Lord British,) started writing for Sierra On-Line (they put out Ultima 2 & Mount Drash.) Later, after LB founded ORIGIN Systems and wrestled the rights to the Ultima title back from Sierra On-Line, he re-wrote Ultima as Ultima 1 and ported it to several systems (PC, C64, etc...) The original sales of Ultima, from what I understand, did extremely well. Which is why Sierra contacted LB in the first place. All that being said, the original version of Ultima commands high prices on the rare occasions it shows up on eBay. Also, the graphics and play style of Ultima is much closer to Ultima II's graphics and such than the re-write was.

The game in the plastic baggies was the original Akalabeth, that LB wrote (again for the Apple II only,) and distributed on his own. His method of distribution? He put the program on floppies (may even tapes too - don't know for sure,) photo copied the instructions, and otherwise hand crafted everything. Put it all in a zip-lock baggie, and set them up at the register at a computer store he was working at. The company that eventually produced and distributed Ultima, from what I've read, saw Akalabeth and contracted LB to make a game that had more content. This was at the very beginning of computer games, and what that company did was considered a risky experiment.

FYI - yes, I am a huge Ultima fan 😀

Feeding Dragon

Reply 19 of 81, by truth_deleted

User metadata

Thanks for the correct information. The game I referred to as Ultima I must have actually been Akalabeth. Probably thought they were one in the same. However, I wouldn't consider that the very beginning of computer games. 😀 For example: http://en.wikipedia.org/wiki/Category:Commodore_PET_games and http://www.commodore.ca/gallery/Commodore_PET … creen_shots.htm.