The Pirates Treasure Chest from Gardner Computers, Inc  Download the Disk Image (boot with BASIC) NEW! updated include BOTH sides of the disk! Table of Contents Chapter 1: Disk Copyguarding The Bad Sector Other Types Of Error Sectors Deleted Data Mark Sectors CRC Error Sector Software Recognition Of The Bad CRC Or Deleted Data Mark Double Sectors Odd Sector Timing General Pointers Chapter 2: Cartridges Hardware Cartridge Protection Software Cartridge Protection Software Defeat Of Software Cartridge Protection Hardware Defeat Of Software Cartridge Protection Chapter 3: Cassettes view typists' notes Chapter 1: Disk Copyguarding The very first form of software protection came in 1979. Before that people could just copy a disk with DOS using the 'J' option. They were free to copy and duplicate any disk they could get their hands on. Then the first copyguards appeared. People were shocked when they duplicated a disk and it did not work. They would sit and copy a disk a dozen times, almost endlessly, only to find out that when they went to run the program that they probably thought they had copied it would not run or something was missing. What they did not realize at first was that some of the programs that they had copied were actually not being copied. What they would end up with was a few missing sectors from the original program! What the software manufacturers would do is go to sector 360 (the Bit Map) and take some of the sectors that were marked in use with "F's" and simply mark them with "0" (zero). Now as we discussed earlier that when you 'J' a disk or duplicate it the first thing DOS will do is to check the Bit Map to determine how many sectors it must copy. So when the disk was duplicated sectors vital to the program would not be reproduced. In other words the first copyguards would fool DOS into thinking certain sectors were not in use when indeed they were needed. It did not take the (so-called) code crackers long to figure this out when they examined the disk. They would see that things were not quite right in the Bit Map. Usually they would fool around and keep marking sectors not in use as sectors in use until they were able to make a working copy of the disk. You may want to experiment with this. Take a file and mark a few sectors in that file with 0 as not in use, then do a 'J' option or dup the disk with DOS. When you run the program you will find it will not run because there are what you call missing sectors. You may want to use this form of protection for some of your own software. To defeat this form of protection the first software copy programs appeared on the market. We will not go into the moral aspects of these copy programs here. The most famous and controversial of these copy programs was called "SUPER-DUP." SUPER-DUP was DOS with the 'J' option: DUPLICATE DISK MODIFIED. Back then people were amazed with the magic of SUPER-DUP. They were able to copy virtually any disk yet they could not do it with regular DOS. SUPER-DUP DOS spread throughout the country. It is now the standard DOS which all people use just in case there is a sector on the disk that is marked not in use when it is needed by the program. People ask how does SUPER-DUP copy these disks when DOS will not? It is amazing how something as powerful as SUPER-DUP can be so simple in operation. This is how it works. SUPER-DUP will simply copy all of the sectors on a disk from 1 to 720. It will ignore the Bit Map and does not care which sectors are marked in use. SUPER-DUP would take a little more time to duplicate a disk but the disk that it would copy would run every time. After SUPER-DUP the market was flooded with copy programs. They would sell for up to $40.00 each. People could now backup their software and they were happy. Many tricks were used by the software manufacturers like moving the Bit Map (sector 360) to another sector. It would now be hidden but whatever they did SUPER-DUP would copy the disk. Around 1980 there was a new form of software protection to hit the marketplace. It shocked the country! All of a sudden SUPER-DUP and the other copy programs would not work. When they tried to copy a disk with this new form of protection their disk drives protested with a horrible grinding noise. Sometimes they would have to shut down their disk drives for fear of burning out their drive motors. SUPER-DUP was useless! They did not know what to do. Days and weeks were spent trying to copy the new disk. People were wondering what could be done about this and sure enough through this new form of protection there came a new form of people that had extensive knowledge of machine language and they would devote days searching through the code of one disk. What they found was what has become known as "The Bad Sector" or what is otherwise known as "The Missing Sector." This form of copyguard is still used today although not as popular as the more modern copyguarding techniques. From here on we will briefly cover and discuss the various copyguarding techniques used. We will go into greater detail on each one later in this book. With the bad sector came what is now widely know and used today as "the custom formatting of the disk." The software manufacturers soon realized that the Atari 810 disk drive had certain built-in limitations. So they made special modifications to their drives. Now they could write their software with their special modified drives and the stock 810 disk drive could not reproduce what they put on the disk. They could write bad sectors and double sectors or put extra sectors on a disk. For example, if you were to put 19 sectors on a track with a special modified hardware enhanced drive the normal 810 disk drive would not be able to reproduce the 19 sector per track format. If you then made the copyguarded software check for the 19 sector format and if it did not find it, have the program lock up then you would have a good copyguarded disk, knowing that the unmodified 810 disk drive could not write 19 sectors per track no matter what the copy program instructed it to do. To sum it up the copy guarded software checks to see that these bad sectors and custom format are on the disk. The bad sectoring becomes part of the program and the program checks for it to be there. The Bad Sector: What is it and how can it be used for software protection? As we know when the disk is formatted on a standard Atari drive there are 720 sectors each containing 128 bytes of data. Actually bad sectors are no sectors at all. They are created on special drives with hardware enhancements. If you had a disk and say sectors 40 through 50 were bad, in reality sectors 40 through 50 would not be on that disk. They would be missing. These bad or missing sectors are used to copyguard disks. They can be used in several ways. The placing of the bad sectors on a disk can cause the copying of that disk to be very hard an time consuming. If say you were to place hundreds of bad sectors before your program it would be a tremendous annoyance to someone trying to copy it. Regular DOS would not do it. There are sector copiers available which will copy through the bad sectors but each bad sector encountered will cause the disk drive to make a horrible grinding noise as it has to retry the bad sector from two to four times. Upon returning an error 144 it will then go on to the next sector. Few people have the patience or the nerve to let their disk drives grind for a half hour or so to get through 200 or so bad sectors. But there are always some people that will let the disk drive run forever, until they have copied the entire disk regardless of how many bad sectors are on the disk even though this will eventually ruin a disk drive. The placing of many bad sectors upon a disk is a good way to discourage people from copying that disk and making it an annoying job. It is much better to place many bad sectors on a disk and have the software check for one or more of the bad sectors. For copyguarding to be effective the custom formatting or bad sectors must be part of your program. We will give an example on how this can be used. Say we had a program we wanted to protect. We could make sector 40 bad assuming we had special hardware allowing us to accomplish this. There are other ways to make a bad sector but for the time being let's just say that we could make sector 40 a bad sector. We will want our software to read sector 40 to check and see that it is bad. The Atari disk drive checks all sectors to be read and returns a status on these sectors. The status returned is a 1 for a good sector and a 0 for a bad sector. We can use this to our advantage in protecting a program. We would now want our program to return the status on our bad sector (example is sector 40). If for example the status of 0 is returned we then know that sector 40 is bad and we can instruct our program to continue or run. If a status of 1 is returned which means a good sector, we could instruct our program to lock-up or not run. Knowing that a good sector being read by our program means that it has been transferred to another disk and it has been copied we would know it is a pirated copy because they would have copied all of our program except for the bad sector. They could reproduce our program byte for byte but they could not reproduce the bad sector with a stock Atari disk drive. The status check on sector 40 can be done in machine language or basic. More than likely this would be done in machine language. You should have knowledge of machine language and programming skills to accomplish this. We will give an idea here of how this is done. We would want to setup a device control block (ex. Into address 301 we would put the number of disk drives used. Into address 302 we put the command to read. Address 303 would return the status of the sector we wanted to read. We would then set the buffer address where the information is to be returned. We would then call the resident disk handler whose address will always be 53 E4. This will return the status of the bad sector.) Without making this too complicated our software must check for that bad sector. In other words the bad sector has become part of our program and it must be there in order for our program to run. The duplication of our program without the bad sector will not allow the program to run. There are many ways which people use to reproduce a bad sector thus allowing them to copy a copyguarded disk. One trick that people use is called slowing down the disk drive. The normal Atari disk drive must run at approximately 288 RPM's + or -3 RPM's. If the disk drive is slowed down to around 220 RPM's and sectors are written they will be bad sectors. Some people have found out about this and some copy programs sold instruct you on how to slow your drive down. This is done by removing the disk drive cover. To access the drive you must remove four small tabs with an exacto knife or other thin sharp object. You lift the four round tabs off allowing you access to the four screws which secure the cover of the disk drive. After removing these screws from the disk drive you may now lift off the cover. On the newer drives toward the rear of the drive on the P.C. board you will locate a small green potentiometer. It will usually be marked R106. On the older drives there will be a larger white nylon circular potentiometer which you may turn with your fingers. On the newer drives you will use a very small thin bladed screw driver for this purpose. To reproduce a bad sector you will want to set the drive speed to approximately 220 RPM's. We have provided you with an RPM program in which to do this with. You must provide the screwdriver yourself. After the RPM's are set to 220 allow a few seconds for it to stabilize. The sectors that you now write when read back at normal speed will be bad. You may use our sector writing program to experiment with this. There are other ways to write a bad sector. We do not recommend them for they are dangerous and could cause damage to your equipment. We will discuss them. One way is to use a piece of scotch tape by cutting a piece of tape about 5" long. Fold the tape in half and attach this piece of tape to the end of your disk. You could now stick that disk in your drive and when you close the door you will have a few inches of tape sticking out. By pulling on the tape while writing a sector, the pressure you exert on the disk will cause the drive to slow down thus writing a bad sector. This technique is known as "milking the cow" because you have to jerk the tape in a back and forth motion. As silly as this may sound many (so-called) code crackers have become very proficient at this. They will use this technique in trying to copy your software. Another method used by people with knowledge of disk drive hardware is to locate the 1771 controller chip. They will then wire-up a switch which will short out the pin that is responsible for writing. Once this device is installed in a disk drive they can write bad sectors simply by flipping a switch. There are kits available for the 810 disk drive that will automatically write bad sectors. These are sold as hardware enhancements. Their hardware will allow the user to copy just about any custom format including bad-sectored disks. Unfortunately for those that wish to protect their software there is no defense against these hardware enhanced disk drives but they are expensive and require disk drive disassembly to install so there are not that many in use. The bad sector while good is not the best copyguarding technique to use. When first introduced it was good but not many people know how to slow down their disk drives and reproduce a bad sector. The fact that anybody can simply slow down their disk drive and reproduce a disk copyguarded by bad sectors alone make this form of copyguarding not all that secure. With the proper hardware you can produce custom formats which the stock 810 disk drive cannot. The double-sector has become a popular form of copyguarding. A normal disk contains forty tracks. These tracks are circular like the grooves on a phonograph record. Each track contains 18 sectors, which is the standard Atari format. With special hardware you could produce a track or tracks with 19 sectors. You could now have one extra sector into which unique data could be placed. The standard 810 drive could not reproduce this custom format as whereby slowing down the disk drive they can duplicate the bad sector. They would not be able to duplicate your 19 sector format regardless of slowing down or speeding up RPM schemes. The standard unenhanced 810 disk drive can simply not reproduce 19 sectors or more per track. To protect your software you could take advantage of the 810 disk drives' limitations. As with the bad sector protecting technique, your copyguarded software must check the 19th sector to assure that it is on the disk. As in all cases your code must check for your custom formatting. If you hide the code that does these checks your software will be even more secure. The code crackers will go through your entire disk a sector at a time checking every byte if necessary until they find where you are checking status or confirming special formats. They will then remove your software checks (i.e. where you do a status check of a bad sector, say in previous example, we were checking sector 40 for a bad sector they will remove that or where they see you doing status on sector 40 they would change the command to do status on an out of range sector like sector 2000. By instructing the disk drive to return status on an out of range sector it will try and in trying to do the impossible it would return an error.) Thus they would fool the copied disk into thinking that it had a bad sector. With tricks like this code crackers can uncopyguard a copyguarded disk. Once this is done the copyguarded disk can now be reproduced with standard DOS duplication. Other Types Of Error Sectors: In addition to the "bad sector" described there are several other types of sectors which will cause the 810 to return an error to the application program. They are known as the deleted data mark sector, CRC error sector, and double sectors. There are three advantages to using these other types of non-standard sectors. They are: 1. They do not cause the familiar and much hated grinding noise from the 810. 2. They are identified faster than a bad sector. This allows copyguarded software to boot-up faster without the crunch, crunch of a bad sector. 3. Most importantly, they can't be reproduced by slowing the drive down. Without hardware modifications, there is no way to generate these sectors. There are also several associated software techniques used with these types of sectors. These include sector timing relationships, and double sector verification. Deleted Data Mark Sectors There are several pieces of information the 1771 disk controller (in the 810) attaches to each sector. They are internal to the operating system of the 810, and are invisible to the main computer. The "data mark" is one such data item. The normal value of this mark is $FB (1111 1011), which is assigned by the resident program of the 810 via the 1771 controller. What is done is that the data mark is changed to the so-called "deleted data mark" value, which is $F8 (1111 1000). The software manufacturer, again through modified hardware, will assign the deleted data mark to various sectors on a disk, much the same as a bad sector. CRC Error Sector The CRC, or cyclic redundancy checksum, is another data item affixed to each sector by the 1771. This is an error check code, so that bad data could be identified by the 810. What is done here is that the CRC is intentionally set to a bad value, such that good data would generate a CRC error. The application program expects the CRC error in certain sectors throughout the disk, and attempts to read these sectors. As with all non-standard sectors, the error must be present, or the program will not run. One of the neat things that is done is to combine CRC errors and deleted data marks in one sector. The unmodified 810 could never hope to duplicate these sectors, but will return to the program error status indicating the bad CRC or deleted data mark. How is this done? Software Recognition Of The Bad CRC Or Deleted Data Mark The usual method of checking the status byte of an SIO call does not apply here. An actual "get status" must be executed (command $53). After the "sector read" call has returned, the user must "get status," which leaves the status in memory location $2EB. The contents of location $2EB will tell us what if any error we have as follows: BIT 3 - 1 if OK, 0 if CRC error BIT 5 - 1 if OK, 0 if deleted data mark Software, using these two types of non-standard sectors, will somehow have to check the status in this way. Often, pirates or "code crackers" with a knowledge of 6502 assembly language will search the disk for a routine which examines the status byte for these values and "patch" or rewrite those routines to ignore the status. This effectively "short circuits" the copyguarding and allows an executable copy of the disk to be made using SUPER-DUP. We do not condone this practice, however. One good way to learn more about these copyguarding techniques is to examine and experiment with existing programs. Double Sectors Although Atari specified 18 sectors per track as the standard, there is actually room for 19. One trick which has become popular has been to place 2 sectors, bearing the same sector number, within each track. The software then calls out for that sector several times. What it then does is compare the consecutive sectors of data looking for two different sectors. This will happen within 4 or 5 retries due to the laws of probability. If after four or five retries only one sector of data has been found it is assumed the disk was copied, and the program will not run. If both sectors are found of course the program runs. The code cracker has more trouble with this type of protection due to non- specific nature of the code required to check for double sectors (as opposed to a simple status check), however. Some pirates have been known to foil this type of protection. Usually the more familiar with assembly language the programmer is the easier it will be to comprehend these protection schemes. Odd Sector Timing The layout of the sectors within a track has a critical effect on the speed at which the disk is read. The is most evident when a disk formatted with the older 810 is read and compared to a "fast formatted" (C ROM) disk. On a fast formatted disk the positions of the sectors are optimized for the most efficient reading. In any case, your drive can only format a disk with only one sector layout scheme, be it the fast or older, slower scheme. (All 810's shipped since December 1981 are fast format, anyway.) What is done is that the software manufacturers arrange the sectors on the disk so they read in at some strange, uneven rate. The software has routines to time the reading of sectors, and to verify that the non-standard format is present. One disadvantage to this technique is that the timing is critical. If the drive speed is a little off or a non-Atari drive is used the program won't boot. An advantage is that the SIO sounds may be disabled through the Atari OS. You won't hear the odd timing of the sector reads, and you won't even be aware that this type of copyguarding is being used. General Pointers * To know copyguarding techniques means to know 6502 machine/assembly language. It also helps to know the Atari OS so the Atari Technical Users Notes are very helpful. * Any of these techniques can be combined with any others. Multi-techniques can prove very difficult to "crack." * The protection scheme may occur in more than one spot in the program. Sector checks can be made several times during a boot or even between games! Chapter 2: Cartridges As with all Atari software the fist cartridges were released without any protection. So it was just a matter of time until programs appeared which would copy the contents of a cartridge onto disk in the form of an executable DOS file (the Binary Load). One such program, CARTCOPY, enjoyed great success in the early 1980's. It was a BASIC program which required the user to leave the door open on the computer, RUN the program, and when prompted to quickly insert the cartridge to be copied into the right slot. Most if not all of the early cartridges produced from 1979-1981 would transfer to disk with no problem. Cartridge manufacturers of course became knowledgeable of this practice and began to take steps to stop this practice. One method is a hardware method, another method is a software method. Both can be used in conjunction with one another, however, neither is infallible. Hardware Cartridge Protection This method exploits the electrical differences between the left and right cartridge slots. CARTCOPY, as you will recall, is a BASIC program, as such the BASIC cartridge must be in the left slot. This means the target cartridge must be in the right slot which is not the slot which the cartridge was designed for! What is being done now is that inside the cartridge certain electrical connections are made such that when inserted into the left slot all is well; but in the right slot memory is destroyed (not physically, of course, but all data there which includes the CARTCOPY program is erased or altered). Hence the system crashes. What is done is that on a non-protected cartridge the "A" finger (the rightmost one facing the keyboard) is unused to protect the cartridge, +5 volts is routed to finger "A" from finger 13 on the opposite side (open up any Atari cartridge to see the finger numbering scheme). Now whenever this cartridge is placed in the right slot, the system will crash. Being a simple hardware scheme, this approach is very simple to defeat. Simply open the cartridge and locate finger "A". This is on the solder side of the board (opposite from the component side, which has the ROM chips on it). The rightmost finger is # "A". Take a small file or exacto knife and carefully cut the trace (conductor) going to it. Be careful not to cut any other traces or you will run into trouble. Once the trace is cut, this hardware scheme will be defeated. If you don't want to cut any traces on the P.C. board, some judicious use of scotch tape on the finger "A" will suffice. If you're good with a soldering iron you may want to wire up a cable with a 30 pin socket at one end (to fit a cartridge) and a plug in the other end to fit the slot in your computer. If you wire up each pin in the connector to the corresponding finger on the plug you've got a cartridge extension cable. If you don't wire up finger "A" you've got a hardware-protect defeat cable! Viola! Software Cartridge Protection Software protection, in use since 1981, doesn't rely on any hardware tricks. Rather, the cartridge software has routines which test the area of memory where there should be ROM based, (i.e. in a cartridge). If the program cannot change data within the cartridge area (which it should not be able to; it is a ROM!), it knows it is residing in the cartridge. If, however, the program has been copied onto a disk, then loaded as a DOS file it will be running out of RAM, and hence, alterable. The program will be able to change data in the cartridge area, and will know it has been copied. In that case the program will not run. In a simplistic sense the cartridge tries to erase itself. If it succeeds, fine, since it is no longer in a cartridge, it was copied. If it doesn't (i.e., in the original ROM) it runs normally. Strangely, there are two ways to defeat software cartridge protection -- one hardware, one software. Software Defeat Of Software Cartridge Protection What must be done is similar to cracking a disk. Once the cartridge has been transferred to a disk file the programmer must go into the code and search for routines which attempt to write and read to the cartridge area. This is from $A000 to $BFFF for an 8K cartridge, and $8000 to $BFFF for a 16K cartridge. Again it helps to have a working knowledge of 6502 assembly language as well as a good disk-based disassembler and debugger. Be warned, this can be very tricky, especially if the routine uses indirect addressing into the cartridge area. The program may also check for ROM/RAM at several points within the cartridges. In any case you must patch the code to always decide that the ROM exists, and to branch accordingly. The file should now execute perfectly. Hardware Defeat Of Software Cartridge Protection Manufacturers have recently began producing specialty cartridges, which, when used properly, will disable the read/write line to the cartridge area. One such product, CART CLONE, consists of a machine language program and a cartridge. The program runs without BASIC, thus freeing up the left slot. The user is instructed to insert the desired cartridge into the left slot, and to supply a name. The program then creates a binary load file (loadable from DOS) of the cartridge. To run the game the user inserts the CART CLONE cartridge, with the enable switch "OFF". The game file is loaded, using the DOS "L" command or by using any of the Autorun menus. Then after the file is loaded the user is prompted to turn the CART CLONE cartridge "ON" and to hit any key. The CART CLONE fools the software into thinking it is executing out of ROM then the program runs perfectly. This system works well when transferring two cartridges (which work together) such as BASIC in the left and a utility cartridge in the right) to a disk file. The greatest advantage to this system is no special knowledge is required of the user and will copy any 8K or 16K cartridge. Chapter 3: Cassettes In the very beginning cassettes had no copyguarding at all. The machine language boot tapes could not be copied because once the tape was loaded in you had no control over your computer. It didn't take long for boot tape copiers to appear on the market. These programs would be loaded into the computer and took control over the computer. Once this took place you could load in your tape and transfer it to a disk file or to another cassette making an exact copy. There are many of these copy programs readily available and they do work well. The best way to protect your cassette software from these programs is to make the boot tape a multi-stage tape. In other words two or more stages of the tape must load in order to execute. You could make the first stage load and have it execute and then instruct the second stage to load. Some of the instructions in the 1st stage could be needed by the 2nd stage. You may even want to go so far as to have four stages on your tape or more. In doing this you will make your cassette software extremely difficult to copy. The reason being that the copy programs that they will be using will not be able to predict when the multi-stage loads start and end. This multi-stage form of protection is widely used today by most of the software manufacturers. Other cassette copyguarding considerations might include putting code on your cassette program that would detect the presence of a disk drive being on. By putting an instruction into your program to detect a disk drive on this would prevent people from transferring your boot tapes to disk files. Most cassette games would not want or need the presence of a disk drive so by adding this code if they were to transfer the cassette program to disk your drive detection code would then sense the presence of the disk drive. Because now that the program has been transferred to disk the disk drive would be on. Your code could the instruct the program to lock up. These instructions would be ignored as long as the program remained on cassette. This would be a pretty effective copyguard and could be used in conjunction with the multi-staging technique. We can make the transferring of cassette programs to disk very hard and almost impossible to do by using these copyguarding techniques. The duplicating of a tape to another tape is another story. The pirates have one method which there is no defense against. Any tape ever made can be copied by this technique. If you were to take two cassette decks and wire them together input to output and output to input by putting the master tape in one deck and putting destination tape in the other deck, then setting the source deck to play and the destination deck to record, this configuration will allow you to reproduce any tape. By using this audio duplication method you will be able to reproduce any tape single stage or multi-stage regardless of the number of stages. Unfortunately no form of copyguarding can prevent this. Typists' Notes I've spent the last 3 days typing in this article from my documentation for the Pirate's Treasure Chest, from Gardner Computers, Inc. It's all about the various copyguarding methods for the Atari and how to use (and defeat) them. I got a request from a user on comp.sys.atari.8bit to type this in, then send it to you to add to UMich. I've sent 2 versions, both done in Windows95 using the Programmer's File Editor. The .dos version is standard MS-DOS text, with word wrapping set at 80 columns (PFE does hard wraps, but I don't know if it's line feeds or carriage returns). The .unx version is the same file saved in PFE's unix format. I don't really know how this differs from the other version, but I thought I'd better send you both just in case. Rename the extensions however you need to, of course. I don't really want any recognition for doing this. The newsgroup guys will know who did it, but if you have to document where it came from, just say it was donated by an anonymous loyal Atari user. It's not explicitly copyrighted, but somebody wrote it, so I'm assuming they wouldn't like it if I took credit for any part of it. May 7, 1998 The following is transcribed from the documentation that accompanied The Pirate's Treasure Chest software from Gardner Computers, Inc. The disk contained 18 utility programs for disassembling and/or copying disks, tapes and cartridges for the Atari computers. This is apparently a rough-draft of their book "Computer Software Protection And Codebreaking," because no serious book editor would allow all of the redundancy and poor grammar and poor punctuation found in these three chapters. While no attempt has been made to correct the redundancy and grammar, some punctuation has been corrected to improve readability. No actual words or phrases were changed during this transcription. One program mentioned in chapter one, an RPM program, does not actually appear on the accompanying disk. There was no errata sheet explaining why. Enjoy reading this piece of history, and happy hacking! April 17, 2001 The above notes were left by a source that desired to remain anonymous at the time; however, by careful searching in comp.sys.atari.8bit you can discern who did the excellent job typing in this manual. I merely found this text on the umich atari ftp site, dug through my old 8-bit disks and found the original Pirate's Treasure Chest disk, made an ATR image, and posted it here, along with a slightly html-ized version of the text. enjoy. April 25, 2001 Many thanks go to Steven Posey (the original typist of this manual) for providing the missing back side of the original double-sided Pirate's Treasure Chest Disk! Now, I'm not sure if my copy is not original or if there were different releases of the Treasure Chest (the front side of the disks were exactly the same).