Available here: http://204.16.8.40/other/toyshop/ Uploading to Asimov shortly... Date: 01/10/12 Software: Toy Shop by Br0derbund - 1986 Originals provided by: Tempest Converted to working NIB images by: datawiz Description: Toy Shop was a fun application that allowed you to print out paper models, which allowed you to cut them out, fold, and glue them together. 20 working paper models are available. 6 Disk Images total: Master Disk Side A (boot this) Master Disk Side B Data Disk 1 Side A Data Disk 1 Side B Data Disk 2 Side A Data Disk 2 Side B Additionally, I have included all 20 model files printed into PDF files so they can be used on modern computers. Technical Notes: Strangely, this is one of the few applications released by Broderbund and not a game, which is what they are normally known for. This game has some pretty heavy format-based copy protection. Specifically, it uses 18-sector protection which stores the equivalent of 18 sectors of data within a track. While I haven't looked, I expect that this protection is very similar to other big Broderbund game titles released around that time that also had 18- sector protection (Airheart, Wings of Fury, and a bit later Prince of Persia). Why protect an application like this? Well, I have 2 ideas on this. First, they had already developed the protection scheme, so why not use it? Secondly, and I think more plausible, is because this app has so many graphics, it actually takes advantage of the additional space. So perhaps the 18- sector protection wasn't for protection, per se, but for more storage and to reduce the need for ANOTHER data disk (or removing some of the models to fit). Initially, I intended on deprotecting the software, and I got to the point where I could use their own 18-sector DOS read routines to load in arbitrary tracks into memory locations I specified. I had assumed that only the Boot disk had 18-sector protected tracks, and on the master disk I found that tracks 1-4, 1c-22 had 18-sector protection and the remaining were 16 sector standard DOS 3.3 format tracks. The program's code has a second DOS to read and write standard dos 3.3 as well. When I dumped the 18-sector tracks, I realized that they were all full of data and code, and when I looked at the 16-sector tracks I did not have enough free sectors to store the extra sectors for the 16-sector crack. This is a problem, as you can guess. Well, out of curiosity, I decided to look at the other 5 disk sides. Imagine my surprise when I found that almost all the tracks on the remaining disk sides had 18-sector formatting! This poses a HUGE problem, and makes it unfeasible to do a full 16-sector rewrite without a lot of work. And, as you can guess, these 18-sectors were full of graphics and there was little room to store extra sectors for a crack. So, I decided to build .NIB images, expecting them to NOT work, as almost every format based copy protection scheme also includes a secondary protection. Normally, this would mean nibble count routines that would fail on a copy and reboot or lock up the program. Well, after a few attempts with bit copiers, I converted the images to NIBs, and ran them under emulation (Virtual II on a Mac). Imagine my surprise to find that everything worked 100% with no additional nibble patching needed to defeat nibble counting. So there was no secondary protection outside of the 18-sectoring, which also makes me think that the decision to use 18-sectoring was for the additional disk storage space. If you are not interested in Apple II pirate history, then stop reading now... -------------------------- Apparently, this application was never cracked and released in the golden days of the Apple II when piracy hovered around BBS' and local copy meets. Having been in part of this scene in the later 80's, I was intrigued by this, and I think having been involved then and now seeing the application and protection, I can shed some light on it. I'm not sure there's any interest, but I'm a bit of an Apple II Pirate Archaeologist, so I find it fascinating. First of all, in the Apple II pirate underground, it was unfashionable to pirate anything but games. There were probably just as many educational titles available for the Apple II during the mid-80s, but if a legitimate cracking group released an educational title, other competing groups would ridicule them. This sounds utterly ridiculous, but in those days the competition was high and this was a rule. So even a very challenging app like Toy Shop would have fallen under the category of "edu-ware" and the top tier crackers would not have touched it. For an example of the ridicule a group would go through, you can find crack screens from groups like First Class, Coast to Coast, USAlliance and others who "rag" on groups like The Bunnymen and Circle of Deneb who did release edu-warez. Once this top tier of groups turned on you, you were treated as pariahs on all of the top tier BBS' of the day. Assuming that the top-tier crackers associated with these groups were not interested in working on a crack for this, there were not many other people with the knowledge to undertake a full crack of this, which may be another reason it was never done. Research the index of Computist magazines. There are no full cracks ever reported, just some tips for nibble copy parameters. Also, while the app itself is neat, it's not something all that interesting or fun (like a game), which means there probably wasn't a high demand to have it cracked. Because the disks are packed full of data, a 16 sector crack is really unreasonable. If you look at games based on 18-sector protection, in most cases there is enough space on the disk to store the additional 2 sectors per track. You can then rewrite the game's dos to load in the additional sectors as needed. Refer to Airheart, Wings of Fury, and even Prince of Persia. Origin later came out with 18- sector protection on Tangled Tales, and the Brain Trust crack of this game appears to use an additional boot disk for the initial load up of the 18-sector tracks, which is another approach if there's not enough free space on the disk. Finally, while this game would have been difficult to crack back in those days, there is an approach that could have been used to distribute a working copy. A program could be written to read a track on a protected disk, and save it's nibbles out. A separate program would be written to re-assemble the nibble images back into a disk that has a non-standard format that would work (assuming the crackist removed secondary protection in the nibblized images). The downside to this is that, obviously, you still have an uncracked version, but the bigger issue is that for each disk side, it takes 2 disks of data to store the nibblized disk data. That will essentially DOUBLE the application. So, Toy Shop is a 3 Disk program, that's 6 sides. It would take 12 disks total for the nibblized images, plus another disk for the re- assembly program for a total of 13 disks! This is essentially with SST (Saltine's Super Transcopy) does, but this application would be custom written for the game/app you are pirating. I have seen something like this in the BBS scene before, but I can't remember which game it was for (perhaps Battle Chess for the Apple IIe, release by the Byte Bastards). In our days of modern technology and virtual disk images, it's really no big deal, but recall technology in the mid-80s: Disks were NOT cheap, data was transferred over TELEPHONE lines. Analog! At earth-shattering speeds of 2400 Baud IF YOU WERE LUCKY. Most people still puttered along at 1200 or maybe 300 BPS still... Assuming 20 minutes a disk side, you are still looking at over 4 hours to upload/download this program as a pirate. Back then, most reputable pirate boards ran on a credit system. You had credits to use for downloads, or a ratio that gave you so many download credits per upload. So spending hard earned credits to download this would seem silly, especially if your opportunity cost is something like Airheart or Wings of Fury. Also, disk space on BBS' were at a premium, so I can also see BBS System Operators getting angry at a person uploading this "junk" (recall, this would have been considered an edu-ware), and they would probably nuke (delete) it on the spot to save space for an highly anticipated game or utility. This is long and rambling. Sorry if you were forced into reading it. You will never, ever get those precious minutes back. It just amuses me that I keep encountering rich background stories as I tear into this old software, and my mind looks back at the events and environments of those days. I'm sure I'll run into more, and I can't wait. Rich/datawiz
On Tue, 10 Jan 2012, datawiz wrote: > Specifically, it uses 18-sector protection > which stores the equivalent of 18 sectors of data within a track. Interesting, I haven't looked so far into 18 sector schemes. Just by a quick glance, track #0 of "master_a" disk has visibly 17 sectors. There are also two instances of hard sector #1, with different data. Sync fields are also generous. They must have slowed down the writing RPMs quite much to fit this many bits. Now that I look at it, NIB's track length of 6656 (0x1A00) nibbles is not enough to carry 18 sectors with such sync fields. I suspect they're either not 18, or something went wrong in the conversion.
Hey Vlad, Track 0 is in a normal 16-sector format. Here's some more from my notes: Protected tracks will be T1-4, T1C-22. All the rest are normalized. If you want to see the second stage boot code that reads in the 18- sector track, boot the master a disk and enter the debugger at the first hgr title screen and at look at $6803. This is called after the address marker is read (D5 9D XX XX XX AA). A5 marks the start of data The loop runs for 256 iterations (via y) and reads 4 bytes from the drive per iteration. The disk bytes are 6+2 encoded, and the first byte holds the "2" bits, and the next 3 bytes are the 3 "6" bytes. These 4 disk bytes are translated to 3 data bytes (translate table is at $6e00) and stored in memory. D4 marks the end of data This will yield 3 pages of data in memory per call, and is called 6 times in a track read for a total of 18-sectors of data per track. There's a table set up at $6e43 that holds the memory pages in which to store the data as it reads it from the disk and is translated. This is always set up with 18 pages. In the read routine, $26, $28, $2A are used to indirectly store the translated and decrypted byte ($26),Y for instance. The 18-sector dos is used with a JSR to $69E7 followed immediately with a command. Commands are: 00 = turn on drive motor 01 = turn off drive motor 02 = seek to track followed by 00 XX (XX is track number( 03|43 = read track and store contiguous (18 pages) followed by XX (start page in memory to store data) 04|44 = read track and store non-contiguous (18 pages) followed by 18 values of memory pages to store data to At $6b41 the program makes it's first call to the dos, which is: JSR $69E7 followed by 02 00 01 (seek to track 1) JSR $69E7 followed by 43 20 (read, store starting at page $20 -- HGR1 screen) After this point, track 1 is read, translated, and stored at $2000- $31FF Later in the application, the dos is relocated and called in a different place. I think it's in the $4300 range. This dos is sufficient to read in protected tracks on all disks, so that's where I stopped. I hope that helps!
I'm just glad it's finally cracked and uploaded. I've had these disks since forever (I bought the program new back in the day and spent far too many hours putting those little contraptions together), so I never knew it wasn't available online until I checked the Asimov missing list last year. Of course cracking something like this was out of my league (if Locksmith doesn't crack it then it's beyond me) so even though I had the missing disks, I couldn't do anything with them. But after a chance conversation with datawiz about an unrelated topic, we got to talking about cracks and the 'old days' and everything fell into place. :) Tempest
Hello datawiz, On Wed, 11 Jan 2012, datawiz wrote: > Track 0 is in a normal 16-sector format. Now I see. I got the following sector numbers: $00, $01, $10, $11, $02, $03, $12, $13, $20, $21, $30, $31, $22, $23, $32, $33 Sector $01 is present two times, but I guess it's because of the imaging buffer, leftovers and read repetitions. After the second $01 data end marker ($DE $AA) there is some leftover chunk from sector $00. Did you use SST or your own program? The reason I ask is because I am more concerned with the leftovers in the track image and whether they can be avoided, such as pre-filling the $1A00 buffer with $FF or anything smarter, depending on the reading algorithm. > Protected tracks will be T1-4, T1C-22. All the rest are normalized. > If you want to see the second stage boot code that reads in the 18- > sector track, boot the master a disk and enter the debugger at the > first hgr title screen and at look at $6803. This is called after the > address marker is read (D5 9D XX XX XX AA). > > A5 marks the start of data > The loop runs for 256 iterations (via y) and reads 4 bytes from the > drive per iteration. > The disk bytes are 6+2 encoded, and the first byte holds the "2" bits, > and the next 3 bytes are the 3 "6" bytes. > These 4 disk bytes are translated to 3 data bytes (translate table is > at $6e00) and stored in memory. > D4 marks the end of data > This will yield 3 pages of data in memory per call, and is called 6 > times in a track read for a total of 18-sectors of data per track. Got it this time. The 6 big "sectors" and the short headers and sync make the total length well within the limits. > I hope that helps! Thank you very much for the detailed explanation! Cheers, -- Vlad
A long time ago, in France... It was a dark and stormy night ((c) Schulz), It was about 18-sec protections, It was in 1988... @ http://boutillon.free.fr/Underground/Cours/Cours_GDF/Gdf19/Gdf19.html antoine ps. I hope you read French ;-)
On Thu, 12 Jan 2012, Antoine Vignau wrote: > A long time ago, in France... > It was a dark and stormy night ((c) Schulz), > It was about 18-sec protections, > It was in 1988... > > @ http://boutillon.free.fr/Underground/Cours/Cours_GDF/Gdf19/Gdf19.html Interesting. RWTS18 has command for writing individual sectors with parameter bitmap similar to "read" command - which I don't see working for the 18 sector case, except if the whole track is written at once. Even writing of a single (1 out of 6) macro sector is little questionable with such small sync gaps as seen on the Toy Shop image. Aren't all 18 sector tracks read-only in all installations? Is that RWTS18 write command actually for 16 sectors? Did I miss something? Oh, and I should check Trinity some day .. > ps. I hope you read French ;-) Unfortunately, no. Salut, Deckard!
Vladimir Ivanov wrote: > On Thu, 12 Jan 2012, Antoine Vignau wrote: > >> A long time ago, in France... >> It was a dark and stormy night ((c) Schulz), >> It was about 18-sec protections, >> It was in 1988... >> >> @ http://boutillon.free.fr/Underground/Cours/Cours_GDF/Gdf19/Gdf19.html > > > Oh, and I should check Trinity some day .. > >> ps. I hope you read French ;-) > > Unfortunately, no. > > Salut, Deckard! > I did translate some of this document, but work is slow since (took me about 2 hours to do just this part). Machine translations are unsatisfactory due to slang (including one rather vulgar word!) and computer jargon used in the document. However, if there is indeed interest in a complete English translation, I could see about completing it. Here is what I have so far: Cracking Lesson 19 [ Traduction Anglais par DF ] Update for 19 August 2011. At the beginning of their writings, the Godfather lessons changed numbering. Apart from the author himself, it is somewhat probable for someone having the last version of each of these lessons. After a recent message from LoGo (& Christo), I find myself again with 2 lessons numbered "20" with differing content. I therefore decided to rename the one that I had (lesson 20: 18 sectors) to be lesson 19 in order to align it with the latest list of lessons in my possesion. Lesson 20 will therefore be about the protection of Datasoft 1988, a lesson which will be online on 20 August 2011. In addition to the text references here, I had to change the contents of the .dsk where a "19" appeared in stead of "20", including the screens. Otherwise, the old lesson 20 will not boot. I changed the boot 1 to allow it. Note that even though the menu suggests so, there is no file "INFORMATIONS COURS" on this disk. Probably to save disk space. The option will not work if you choose it from the menu. [ some screenshots of the program ] Disk : Gdf19.dsk "-" files are DELETED files | "*" files are LOCKED files ---------------------------------------------------------------------- B A$1F00 (007936) L$12FF (004863) 022 COPIEUR N6 B A$3000 (012288) L$0537 (001335) 007 EPYX_FURY B A$0901 (002305) L$19E7 (006631) 027 EPYX_FURY.S B A$3000 (012288) L$06F3 (001779) 008 GOGSMITH *A A$0000 (000000) L$0208 (000520) 004 GOGSMITH.PRG B A$0901 (002305) L$2BD3 (011219) 045 GOGSMITH.S A A$0000 (000000) L$0CCD (003277) 014 LECTEUR.PRG B A$0300 (000768) L$0051 (000081) 002 LECTURE PISTE AIRHEART *A A$0000 (000000) L$00C5 (000197) 002 LECTURE WING.BAS.PRG B A$40E8 (016616) L$0018 (000024) 002 MODULE_IOB B A$4000 (016384) L$0400 (001024) 006 PAGE_TXT B A$4E00 (019968) L$04B0 (001200) 006 RWTS AIRHEART B A$4000 (016384) L$0800 (002048) 010 RWTS16 B A$4000 (016384) L$04F0 (001264) 006 RWTS18 A A$0000 (000000) L$029E (000670) 004 HELLO T A$0000 (000000) L$8900 (035072) 137 T.COURS 19 REVISION 1.00 B A$0901 (002305) L$3730 (014128) 057 GOGSMITH 1.20.S B A$3000 (012288) L$0762 (001890) 009 GOGSMITH 1.20 A A$0000 (000000) L$020D (000525) 004 GOGSMITH 1.20.PRG T A$0000 (000000) L$0800 (002048) 008 T.LES PROGRAMMES DE CE DISK T A$0000 (000000) L$0400 (001024) 004 T.INTRODUCTION A A$0000 (000000) L$001D (000029) 000 COPYN6.PRG B A$0901 (002305) L$059D (001437) 007 CHRCH_NIB.S B A$1000 (004096) L$0053 (000083) 002 CHRCH_NIB B A$1000 (004096) L$0051 (000081) 002 CHRCH_NIB2 A A$0000 (000000) L$01DB (000475) 003 CHRCH_NIB.PRG B A$0901 (002305) L$03DD (000989) 005 CHRCH_NIB2.S This catalog contains 27 files. 0 were DELETED. ---------------------------------------------------------------------- Introduction Lesson 19 : Br0derbund Protections / 18 sectors per track 18 sectors per track? But you say it doesn't matter, my dear sir! Everyone knows that there are always 16 sectors per track, and not more! Why not 43 teeth per mouth or 15 years for the presidential term? My goodness! Perhaps it is possible, no? With information about the Apple, one can do everything .. modify everything ... hack everything.. The only thing is to know how! Well then, let's see how! ======================= Amicably, G. Lesson 19, revision 1.00. ======================================================================== Lesson 19 : Br0derbund Protections / 18 sectors per track Godfather ======================================================================== Revision 1.00 Update : 07 May 1988 This lesson wouldn't have been as brilliant without the invaluable help of people like Mister DD, The Gog's, Numéro 6, and surely, the author of all this mess: Roland Gustafsson!, from the Br0derbund companty. Thank you! ======================================================================== 1. Introduction 2. The magnetic data marks on the disk 3. Data storage on the diskette (nibbles) 4. The rwts18 routine, reading, writing, formatting, recalibrating, etc... 5. Copy Program 6. Supplementary Problems: track numbers on the bad tracks, verify 7. Adapt the copier to the new, diverse Br0derbund programs 8. History and diagnostics of all the latest Br0derbund programs 9. 18 sectors per track. Who says better? ======================================================================== 1. INTRODUCTION TO 18 SECTORS PER TRACK and the problem it gives us ======================================================================== On today's menu, the current protection of the finest Apple software, you will recognize them if I talk about Karateka, Captain Goodnight, Wings of Fury, to name just a few.. Br0derbund. In starting this lesson, you will perhaps be asked who is the dedicated guy: Roland Gustafsson. He's the dick Gustaffson, also a lead editor of the American magazine, NIBBLE. He is the "official" protector for Br0derbund. And therefore, the author of the protection that we are studying here: 18 sectors per track. >>>>>>>>>>>>>>>>>>>> Deckard's notes from 07 May 2007: first of all, in the entire GDF text, the name mentioned is Steven Gustavson instead of Roland Gustafsson. I have corrected it. One must know that Steven has a connection with Roland! It's about one of the easter eggs utilized in the program PRINTSHOP COMPANION. If you boot side 1 of the program and type STEVEN following with a press of ESC, the screen will display in reverse!! Useless, but funny. Furthermore, Roland never wrote for Nibble magazine. Actually, I found many articles written by him in A+ magazine. He was interested in programming sound on the Apple IIGS. <<<<<<<<<<<<<<<<<<<< Picture a disk containing 18 sectors per track with a total of $23 tracks, normally numbered from $00 to $22.. That means as many tracks as on a disk formatted for DOS 3.3, but each containing 2 more data sectors, making two more $FF bytes. ($1FF bytes more per track!). The cracking of a protection "format", as you well know, always happens with a format conversion step. The original disk has a non-standard format, we want to convert the first one to a standard format, meaning 16 sectors per track!.. Only here, a big problem is presented! Look, to try to explain it to you, here are the "capacities" of these two formats: 16 sectors per track with 35 tracks having $FF bytes per sector.....143360 bytes 18 sectors per track with 35 tracks having $FF bytes per sector.....161280 octets Do you understand the problem? Not yet? Well then, I shall continue... 16 sectors per track with 35 tracks : 560 data sectors per side! 18 sectors per track with 35 tracks : 630 data sectors per side! That means, considering that you find the 18 sector reading routine in any original Br0derbund program, and you are also able to prepare the format conversion, the question remains: You have 70 sectors "too many" which are not indispensable.. Where are you going to put them, because they must go somewhere on a "deptrotected" disk - that's the goal of this game - a disk with 16 sectors per track.. And remembering that these 16 sectors per track are - in theory - already occupied with the program's data. Am I clear enough? Pierrette has a jug of milk that can hold only a liter, and she must bring back to the village - under pain of galactic cataclysm - 1.5 liters of milk. Do you have a solution to this problem? I am going to try, with this lesson and potentially a future lesson number 19.2, to explain to you and to clarify the two solutions which appear to us, after - believe the best - intense thoughts of the entire planet! =============================================================================== 2. The magnetic data marks on the disk =============================================================================== First thing sirs, you are going to open your mind.. be open to anything that could be said here.. to any novelty.. Expand your field of possibilities, concentrate, breathe in., breathe out.. and understand! For the following explanation, and I say that for the perfectionsts, I will say ahead of time, I must alter the facts for a better comprehension. For example, I am going to imply that the disk read head moves around the tracks, but really it is the diskette that turns under the disk read head. You may accept that the effect is identical depending on the point of reference, and you may also equally grant that I have the right to allow a few "lies" which will follow, for your benefit.. Well, if you discover some anamolies - because you already know too much - you don't have to accuse me here, I excuse myself here in advance. Off we go.. I ask you to imagine the track of a disk. A track we will compare, to simplify things, to a bicycle track, such as the track at Bercy. A circular track, on which one dispatches a little man (the runner) having a certain speed. This bicyclist who will complete a loop of the track in a certain time is compared with the read head of your drive which will make the loop of a data track in a certain time. The problem presented to use is that of formatting. If the reading of a track can be done sector by sector in any time (one can read a track a few sectors at a time, and if one's drive is too quick or the reading routine is too slow, one must come back a second time, see a third time to get the rest). The formatting is a "cut" of a track in sectors according to a given format. For the formatting, the problem is different. One cuts the disk, and the third sector, for example, no matter which format, 19, 18, 16, 13 sectors or otherwise, must be placed immediately after the second (physical sectors), and immediately after the first.. Everything must be cut after sector 0, which marks the "start of the cut", and just up to the last sector, in a single pass! In a single loop of the disk surface. One will assume that our bicyclist leaves from the starting line (which is also quite close to the finish line - the end of the track), with a set of 18 flags, because there are 18 sectors per track. He is going to leave a flag every 22.22 meters around a track of 400 meters in circumference. For example. It takes a certain time to cease a flag and its pole, and again a certain time to place it to mark the start of one of the cuts of the track, of one of the divisions which he must make there. From one of the sectors of the track it will go. The problem, I restate, is that he must place all of the flags in a single loop.. and if, on these 18 flags, he only ends up placing 17, for example, the formatting of this track must start again. The desired number must be placed from the start, according to the format. You understand well further that the bicyclist moves slowly around the track, so he will have time to place these flags, and therefore be able to plant a large number of them. In 1979, DOS 3.2 contained only 13 sectors per track for speed. The drive proposed by Apple at the start wasn't reliable enough, also the formatting was done more slowly, and our bicyclist could not have the time to put barely just 13 flags. Understand that "flag" means field address, the separation point between two sectors on the track, and understand that between two flags, data are written (the tread of a tire rests on the track.. if you wish (!?)). We are going to see much later the head of these flags and the mark of the tire tread on each 18 sector track, when I talk about the 18 sector format. Now, we went only to 16, and BR0DERBUND, with some slow drives, has formatted a disk with 18 sectors. If our drives are of a good speed not too fast (you can test their speed with a program called Copy II+ 5.x, or EDD v4.2), you can then copy the Br0derbund programs without too many problems. Although sometimes there are a few boot modifications (generally on track $0) to get a working copy. Whatever the speed of your disk drive head, 18 sector programs boot just as well no matter which drive, but don't copy at all from the nibble copier. (in theory, the copier must work everywhere, functioning at a "normal" maximum speed.) Apple hasn't yet made - and won't make - DOS 3.4 with 18 sectors per track for this reason: all the drives, they can read 18 sectors, but they can't all format 18 sectors. =============================================================================== 3. Data storage on an 18 sector diskette =============================================================================== In general, several tracks (track $00, or even tracks $00 and $01) are in the DOS 3.3 format, 16 sectors per track. All of this is normal, and these are the tracks which contain the famous rwts18. But leave me rather to tell you about the 18 sector format in quesetion. In fact, we talk of 18 sectors per track because each track has the equivalent data of 18 DOS 3.3 sectors of $FF bytes, making $17FF bytes, but on the disk, the data are regrouped into macro sectors. It doesn't add up, therefore, 18 sectors of $FF bytes, mais 6 sectors of (3 * $FF) bytes, these amount to the same incredible count of $17FF bytes per track, versus $15FF per track which we are offered in in the 3.3 format. The first macro-sector corresponds to sectors 00,06,12. The second macro-sector corresponds to sectors 01,07,13. The third macro-sector corresponds to sectors 02,08,14. The fourth macro-sector corresponds to sectors 03,09,15. The fifth macro-sector corresponds to sectors 04,10,16. The sixth macro-sector corresponds to sectors 05,11,17...making 18 secteors!! Each macro-sector is constituted in the following manner: (to make a comparison with the 3.3 format, refer to lesson 6) _____________________________________________________________________________ ! ! ! ( 18 SECTOR FORMAT ) ! ! ! ! - A field address : Prologue D5 9D ! ! ! ! Track NN ! CONVERT WITH THE HELP OF A ! ! Sector NN ! CONVERSION TABLE ! ! Checksum NN ! ! Epilogue AA ! ! ! ! - Two self-sync nibbles FF FF ! ! ! ! - A data field : Prologue A4 ! variable, according to program, WATCH!! ! (I will refer to the prologue as "the header which can vary"!) ! ! ! ! Data $400 NIBBLES (4 Nibbles --> 3 Bytes) ! ! Checksum NN ! ! Epilogue D4 ! !_____________________________________________________________________________! The nibbles are converted into bytes on the fly while being read, with the help of a conversion table. This is contrary to DOS 3.3, where the conversion (post-nibblization) happens in a buffer after the nibbles are read. On the other hand, some Br0derbund software, such as was the case for Airheart, the track $1C doesn't exist. The track was identical to track $1B and was numbered as track $1B in the field address. But it's a "plus" which isn't really important in regard to the "18 sectors" protection, and it hasn't been employed in any of the recent Br0derbund programs. Therefore, no panic! We will talk about it in the 'Cracking' lesson, but here is a bit below.. [ Traduction Anglais par DF ] -- ]DF$ Mac GUI Vault - A source for retro Apple II and Macintosh computing. http://macgui.com/vault/
On Tue, 17 Jan 2012, D Finnigan wrote: > I did translate some of this document, but work is slow since (took me about > 2 hours to do just this part). Machine translations are unsatisfactory due > to slang (including one rather vulgar word!) and computer jargon used in the > document. Thanks for the translation! Deckard gave me few giggles with this one.
Vladimir Ivanov wrote: > On Tue, 17 Jan 2012, D Finnigan wrote: > >> I did translate some of this document, but work is slow since (took me >> about >> 2 hours to do just this part). Machine translations are unsatisfactory >> due >> to slang (including one rather vulgar word!) and computer jargon used in >> the >> document. > > Thanks for the translation! > > Deckard gave me few giggles with this one. > Well, I will work on translating the rest of it. I have time to do it, but it takes a lot of time!
On 18 jan, 10:21, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote: > On Tue, 17 Jan 2012, D Finnigan wrote: > > I did translate some of this document, but work is slow since (took me about > > 2 hours to do just this part). Machine translations are unsatisfactory due > > to slang (including one rather vulgar word!) and computer jargon used in the > > document. > > Thanks for the translation! > > Deckard gave me few giggles with this one. The author of the series is Godfather, a well-known French pirate, not Deckard. av
On Wed, 18 Jan 2012, Antoine Vignau wrote: > On 18 jan, 10:21, Vladimir Ivanov <vlad...@XXXyahooXXX.com> wrote: >> Deckard gave me few giggles with this one. > > The author of the series is Godfather, a well-known French pirate, not > Deckard. Right.
Here are sections 4 and 5. I will probably finish the rest of the document later, and I will put it on Mac GUI Vault as well as Asimov as a plain text file. =============================================================================== 4. Booting (EXAMPLE : AIRHEART) and the 18-sector reading/writing routines =============================================================================== Let's follow the booting of Airheart, booting as I will show in an example here, but anything could change, anything will change, and - one more time - this is only one more thing to this lesson, and will not be very important, because at the end of this lesson, you will get a copier for the 18 data sector protection of the original disk. Here we are, then, the example of how Airheart boots. The program successively loaded 3 reading/writing routines: - The first at $D000, is a read routine that is used by boot 2 (load only) - The second is part of Gustafsson's Disk Operating System ($0400-09FF), and is addressed by a vector at $040F. - The third, which is this time a suitable reading/writing routine, is loaded into $4E00 (Airheart) at the moment of reading the records. On Wings of Fury, this rwts was included at another address, but it was the same as we shall see, at least close enough, the same routine. It is saved in the disk catalog under the name "RWTS18". Also included on the disk is the routine taken from Airheart, named "RWTS AIRHEART". After this little discussion about booting, here is the main subject: _____________________________________________________________________________ ! ! ! THE LIST OF RWTS18 COMMANDS ! ! ----------------------------------- ! ! ! ! The disk access routine is found in $4E00. I named it RdDisk, because this ! ! address can change according to the program. This I will see later. ! ! ! ! The programming syntax follows : JSR RdDisk, followed by a command byte ! ! and 0 to 18 bytes having parameters for that command, these paremeters ! ! will be listed. ! ! ! ! 3 zero-page addresses are modified on each disk access, also, if they ! ! are important in your program, you should copy them into three other ! ! locations before accessing the disk. They are : ! ! ! ! $FD Drive slot number * $10. (usually $60 for slot 6) ! ! $FE Track number where the drive head must go. ! ! $FF Physical track number times 2, where the drive head is located ! ! ! ! Here now is the list of disk commands, followed by the number of ! ! necessary parameters, and all relevant details concerning the command and ! ! its parameters. ! ! ! ! Command 00 (2 parameters) ! ! ----------- ! ! Start the motor. ! ! Parameter P1 : Drive (always 01) ! ! Parameter P2 : Delay (often 0A) ! ! ! ! Command 01 (No parameter needed) ! ! ----------- ! ! Stop the motor ! ! ! ! Command 02 (2 parameters) ! ! ----------- ! ! Read head movement (seekabs). ! ! Parameter P1 : 00 _ No control of the actual track. The movement assumes ! ! you are on the track whose number ! ! is stored in $FF. (multiplied by 2) ! ! FF _ Read a field address on the actualy track to find where ! ! the disk head is, and to confirm that the head is ! ! actually on the desired track. ! ! Parameter P2 : Track number to reach. ! ! ! ! Command 03 (1 parameter) ! ! ----------- ! ! Sequential read of a track. ! ! Parameter P1 : Memory page number at which to begin loading ! ! ($20 will commence loading at $2000). ! ! ! ! Command 04 (18 parameters) ! ! ----------- ! ! Read only selected sectors from a track. ! ! Parameters P1 to P18 : Numbers of memory pages to store. ! ! The 00 values are changed to $CF, that is to say that the loading happens ! ! in ROM : nothing happens!. (It is not possible to load directly in to ! ! page 0, because it contains all the parameters for actual/destination ! ! track..). If you would like to load data into page 0, you must load ! ! and then move the data (cf lesson 12) in $00,X. ! ! ! ! Command 05 (1 parameter) ! ! ----------- ! ! Read (analogous to command 03) ! ! ! ! Command 06 (18 parameters) ! ! ----------- ! ! Read (analogous to command 04) ! ! ! ! The options ! ! ----------- ! ! For commands 03 to 06, bits 6 and 7 of the command byte are ! ! significant. If bit 6 is set, $FE will be incremented to the end of the ! ! read. The next read will automatically be on the following track. ! ! If bit 7 is set, the read will be repeated until an error is ! ! detected during the disk access. (with a lovely loud beep to say "I shall ! ! try again"). ! ! ! ! Exemple : JSR RdDisk ! ! HEX C3 ! ! HEX 20 ! ! ! ! This routine reads the track whose number is in $FE, by moving the read ! ! head to this track if it is not already on the track, ! ! and load the data from this track to $2000. The operation is repeated until ! ! there is a disk access error, and $FE, the track number, is ! ! incremented at the end of reading. At this time, the rest of the program ! ! below the JSR continues execution, just after the parameters. ! !_____________________________________________________________________________! PROGRAM TO READ A TRACK HERE IS A PROGRAM WHICH ALLOWS ONE TO READ ANY TRACK FROM THE AIRHEART DISKETTE (EXCEPT FOR TRACKS 00 AND 1C) TO ADDRESSES 2000.31FF. ONE CAN THEN (AND I HAVE DONE SO) COPY THE ENTIRE DISKETTE IN THE FORM OF BINARY FILES. THE REST IS NOT MUCH MORE THAN A QUESTION OF PATIENCE! 0300- A2 00 LDX #$00 0302- B5 00 LOOP1 LDA $00,X ;SAVE PAGE 0 0304- 9D 00 1F STA $1F00,X ;IN PAGE $1F 0307- E8 INX 0308- D0 F8 BNE LOOP1 030A- A9 60 LDA #$60 030C- 85 FD STA $FD 030E- 20 00 4E JSR RdDisk ;START MOTOR 0311- 00 BYT $00 0312- 01 BYT $01 ;DRIVE 1 0313- 00 BYT $00 0314- A9 A0 LDA #$A0 ;RECALIBRATE THE HEAD 0316- 85 FF STA $FF ;TO TRACK 0 0318- A9 00 LDA #$00 031A- 20 E3 50 JSR $50E3 031D- A9 00 LDA #$00 031F- 85 FF STA $FF 0321- 20 00 4E JSR RdDisk ;MOVE THE HEAD 0324- 02 BYT $02 ;TO PISTE 1 0325- 00 BYT $00 0326- 01 BYT $01 0327- AD 80 03 LDA $0380 ;NUM. OF TRACK IN $0380 032A- 8D 3C 03 STA TRACK 032D- C9 15 CMP #$15 032F- 90 06 BCC INF15 0331- 20 00 4E JSR RdDisk ;IF TRACK TO READ >= $15 0334- 02 BYT $02 ;THEN MOVE THE HEAD 0335- FF BYT $FF ;TO TRACK $19 0336- 19 BYT $19 0337- 20 00 4E INF15 JSR RdDisk ;POSITION THE HEAD 033A- 02 BYT $02 033B- FF BYT $FF 033C- 01 TRACK BYT $01 033D- 20 00 4E JSR RdDisk ;READING 0340- C3 BYT $C3 ;OF A TRACK 0341- 20 BYT $20 ;FROM ADDRESSES $2000.31FF 0342- 20 00 4E JSR RdDisk ;STOP MOTOR 0345- 01 BYT $01 0346- A2 00 LDX #$00 ;RESTORE PAGE 0 0348- BD 00 1F LOOP2 LDA $1F00,X 034B- 95 00 STA $00,X 034D- E8 INX 034E- DO F8 BNE LOOP2 0350- 60 RTS To start this program, it is sufficient to do : ]BLOAD RWTS AIRHEART,A$4E00 ; load rwts ]BLOAD LECTURE PISTE AIRHEART,A$300 ; and bload track ]POKE 896,<NUMERO DE PISTE> ; and place Airheart in drive 1 ]CALL 768 ; the track loads.. =============================================================================== 5. PROGRAMS TO COPY 18 SECTORS PER TRACK By numero6, Mr.DD, Gog's, Gdf =============================================================================== Many disk copy programs are developed from the rwts routine from Gustaffson. For now, there are only two programs included in this lesson. But really, they are nearly redundant. The first one I know of is made by Numéro 6 for Toy Shop, which was adapted a bit later after Where in the world is Carmen SanDiego?. The second came about in mid-April by the acs and myself, for Wings of Fury. I am not going to tell too much in this section of the text, because these programs are already made - and the source code is on the same disk! - and the rwts18 commands used by these two copiers was just recently reviewed. It will be sufficient for your know-how merely to boot Merlin, then load the file "GOGSMITH". We will later look at the problems that can give us some more information about this protection scheme, and also the "how to adapt this gogsmith to other Br0derbund programs". -- ]DF$ Mac GUI Vault - A source for retro Apple II and Macintosh computing. http://macgui.com/vault/
Here are sections 6, 7, and 8. =============================================================================== 6. Supplementary Problems : A fake track number and boot verification =============================================================================== a) A FAKE TRACK NUMBER -------------------------- It is possible, because Gustaffson did it, to place a track numbered 16 in place of track 17, isn't it? A number is just a number. Necessary to read it is, 1/ to know where the drive head is 2/ move it to the desired track 3/ read the track with the number that it has (which is different from the track number where the drive head is) But don't let me add more to this topic, since R. Gustaf' has stopped manipulating the number of tracks. It will not be useful for you in the future. At least until he decides to do it again, in which case I would return to this lesson as soon as possible! To know more about this topic, refer to lesson 17.2 on the protection of - among others - Ultima 5. The same thing was used with the sector numbers of a standard ProDOS disk. Impressive! b) ORIGINAL DISK VERIFICATION UPON BOOT --------------------------------- I have never worked with a true, original Br0derbund disk in my drive, in fact, I have always made copies of taiwan, among others, which boot just like the original, but which I suspect have already been a bit tampered with. Someone told me about a boot verification of the original-original Br0derbund programs where it was necessary to take off from an echo+ copy in order for them to boot. But I cannot tell you, my goodness! (but likely nothing too bad!) Pray that you will always receive, as I did, original copies, if not, we will talk about it. (I would like to inform you, but not right now!) =============================================================================== 7. The End of the End : Adapting GOGSMITH to the many new Br0derbund programs =============================================================================== To let gogsmith defeat any original disk from Br0derbund, allowing for now the copier to be independent of the original (to boot the copier, that is another story), one must modify many parameters in the copier relating to this original. 1) The map of the sides ------------------------ The copier can copy sides "A" or "B" (one can easily modify the source to make the "C" key show "D" if the parameters are not the same on all of the sides), and make a table of "1618" corresponding to side A. On side A of Wings of Fury, for example, the first two tracks are in 16 sectors, tracks $02-22 are in 18 sectors, and finally, because the copier had some space, there is a track $23 in 16 sectors. The "map" of side A is therefore parameterized as follows in the copier: MAP_A HEX 161618181818181818181818181818181818 HEX 181818181818181818181818181818181816 HEX 00 The 00 delimits the end of the disk. It also indicates the number of tracks for it, or the corresponding sides for a given map. For side B which has only $22 tracks of 18 sectors, if I understand, one has the following map: MAP_B HEX 181818181818181818181818181818181818 181818181818181818181818181818181800 We must modify this map of tracks for each of the sides, depending on the format of each track of the original. For this, in order to define for an original which tracks are in 16 or 18 sectors, it is enough to try a locksmith copy of the original. (Hit "1" then return at the locksmith 6.0 menu, then place your original in drive 1, to read only and not try to write). Next, note all of the copiable tracks, and those which are not. So you noted that the fast, copiable tracks for locksmith are in 16 sectors, and the uncopyable tracks are in 18 sectors. Afterward it is up to you, as we have seen, to put these results in the gogsmith source. (pray for a new version) The ideal would be to add a possible copier configuration before the copy, as with locksmith 6.0 and its possibility to modify any address. (refer to lesson 6 or to "doc on the rocks #16" for more details). But one is always too lazy... 2) The "header" which can vary.. yay! yay! ------------------------------------------ The header which can vary, you remember? I spoke about it before when I was dissecting the 18 sector format with a nibble editor. The format, I will remind you, is the following: D5 9D tt ss cc AA FF FF hh (tt = track, ss = sector, cc = checksum, hh = header). Depending on the original, the hh headers can vary. And prevent reading! It is as if under DOS 3.3 (refer to lesson 6) I placed a D4 AA EB in place of DE AA EB, or again another valid nibble value then AA EB. Incompatibility when reading is assured, therefore no copy. We must also parameterize this factor, not in the copier, but in the rwts18 itself that loads in $4E00. This header is located in $4E8E for the write18 routine. This header is located in $5001 for the read.18 routine. Two solutions, then: modify rwts18 before resaving it on the disk, but this is not advisable because it would be necessary to have 15 rwts for 15 originals, or again add to the source code a couple of LDA STA to modify these address for a given original, before the reading and writing of 18 sectors. Here again, a copier for configurable addresses would make a disaster. To place the copier when booting a copy of a protected disk, you must refer to accolade boot 1.00. It is too complicated to be explained here, because I have enough to make an entire lesson : the godfather's products 12. =============================================================================== 8. History of a few of the latest programs protected by Br0derbund =============================================================================== (This chart remains to be completed..) Airheart 18 sectors - variable Header D4 Toy Shop 18 sectors - variable Header .. Carmen USA 18 sectors - variable Header .. Wings of Fury 18 sectors - variable Header 96 -- ]DF$ Mac GUI Vault - A source for retro Apple II and Macintosh computing. http://macgui.com/vault/
On Tuesday, January 10, 2012 10:47:57 PM UTC-6, datawiz wrote: > Finally, while this game would have been difficult to crack back in > those days, there > is an approach that could have been used to distribute a working copy. > A program > could be written to read a track on a protected disk, and save it's > nibbles out. > A separate program would be written to re-assemble the nibble images > back into a > disk that has a non-standard format that would work (assuming the > crackist removed > secondary protection in the nibblized images).=20 Just to add a bit to your archeology, IIRC, this approach was taken initial= ly on Wings of Fury by "Mr. Slick" (back in the day). See here: http://www.textfiles.com/apple/DOCUMENTATION/conversion except rather than nibble images, compression was used to "pack" and "unpac= k" the data (as compression was called within the Apple II circles then). = But the result was a working 18-sector version. He also provided a copy ut= ility that could be further generalized for other programs. [The fixation = to get everything back to 16-sector format likely missed the opportunity to= pursue preserving use of the 18-sector format and just working around it.] ]HR
On Thursday, June 21, 2012 7:58:15 PM UTC-4, Hot Rod wrote: > On Tuesday, January 10, 2012 10:47:57 PM UTC-6, datawiz wrote: > > Finally, while this game would have been difficult to crack back in > > those days, there > > is an approach that could have been used to distribute a working copy. > > A program > > could be written to read a track on a protected disk, and save it's > > nibbles out. > > A separate program would be written to re-assemble the nibble images > > back into a > > disk that has a non-standard format that would work (assuming the > > crackist removed > > secondary protection in the nibblized images).=20 >=20 > Just to add a bit to your archeology, IIRC, this approach was taken initi= ally on Wings of Fury by "Mr. Slick" (back in the day). See here: >=20 > http://www.textfiles.com/apple/DOCUMENTATION/conversion >=20 > except rather than nibble images, compression was used to "pack" and "unp= ack" the data (as compression was called within the Apple II circles then).= But the result was a working 18-sector version. He also provided a copy = utility that could be further generalized for other programs. [The fixatio= n to get everything back to 16-sector format likely missed the opportunity = to pursue preserving use of the 18-sector format and just working around it= ..] >=20 > ]HR THE Hot Rod? The ORIGINAL Hot Rod? Amazing! Mind reaching out to me directly via email? I'd like to ask you a = couple questions regarding ye olde days of the Apple II underground. Regards, Rich
We did not slow down the drives to "fit" 18 sectors per track, rather, it w= as perfectly-efficient use of space and only one splice point, the beginnin= g of the track. We calibrated the drives used for duplication daily to spec= .. Any more questions? :-) -Roland G. On Tuesday, January 17, 2012 12:35:19 PM UTC-8, D Finnigan wrote: > Vladimir Ivanov wrote: >=20 > > On Thu, 12 Jan 2012, Antoine Vignau wrote: >=20 > >=20 >=20 > >> A long time ago, in France... >=20 > >> It was a dark and stormy night ((c) Schulz), >=20 > >> It was about 18-sec protections, >=20 > >> It was in 1988... >=20 > >> >=20 > >> @ http://boutillon.free.fr/Underground/Cours/Cours_GDF/Gdf19/Gdf19.htm= l >=20 > >=20 >=20 > >=20 >=20 > > Oh, and I should check Trinity some day .. >=20 > >=20 >=20 > >> ps. I hope you read French ;-) >=20 > >=20 >=20 > > Unfortunately, no. >=20 > >=20 >=20 > > Salut, Deckard! >=20 > > >=20 >=20 >=20 > I did translate some of this document, but work is slow since (took me ab= out >=20 > 2 hours to do just this part). Machine translations are unsatisfactory du= e >=20 > to slang (including one rather vulgar word!) and computer jargon used in = the >=20 > document. >=20 >=20 >=20 > However, if there is indeed interest in a complete English translation, I >=20 > could see about completing it. Here is what I have so far: >=20 >=20 >=20 >=20 >=20 > Cracking Lesson 19 >=20 >=20 >=20 > [ Traduction Anglais par DF ] >=20 >=20 >=20 > Update for 19 August 2011. >=20 >=20 >=20 > At the beginning of their writings, the Godfather lessons changed numberi= ng. >=20 > Apart from the author himself, it is somewhat probable for someone having >=20 > the last version of each of these lessons. After a recent message from Lo= Go >=20 > (& Christo), I find myself again with 2 lessons numbered "20" with differ= ing >=20 > content. >=20 >=20 >=20 > I therefore decided to rename the one that I had (lesson 20: 18 sectors) = to >=20 > be lesson 19 in order to align it with the latest list of lessons in my >=20 > possesion. Lesson 20 will therefore be about the protection of Datasoft >=20 > 1988, a lesson which will be online on 20 August 2011. In addition to the >=20 > text references here, I had to change the contents of the .dsk where a "1= 9" >=20 > appeared in stead of "20", including the screens. Otherwise, the old less= on >=20 > 20 will not boot. I changed the boot 1 to allow it. Note that even though >=20 > the menu suggests so, there is no file "INFORMATIONS COURS" on this disk. >=20 > Probably to save disk space. The option will not work if you choose it fr= om >=20 > the menu. >=20 >=20 >=20 > [ some screenshots of the program ] >=20 >=20 >=20 >=20 >=20 > Disk : Gdf19.dsk >=20 > "-" files are DELETED files | "*" files are LOCKED files >=20 > ---------------------------------------------------------------------- >=20 > B A$1F00 (007936) L$12FF (004863) 022 COPIEUR N6 >=20 > B A$3000 (012288) L$0537 (001335) 007 EPYX_FURY >=20 > B A$0901 (002305) L$19E7 (006631) 027 EPYX_FURY.S >=20 > B A$3000 (012288) L$06F3 (001779) 008 GOGSMITH =20 >=20 > *A A$0000 (000000) L$0208 (000520) 004 GOGSMITH.PRG >=20 > B A$0901 (002305) L$2BD3 (011219) 045 GOGSMITH.S >=20 > A A$0000 (000000) L$0CCD (003277) 014 LECTEUR.PRG >=20 > B A$0300 (000768) L$0051 (000081) 002 LECTURE PISTE AIRHEART >=20 > *A A$0000 (000000) L$00C5 (000197) 002 LECTURE WING.BAS.PRG >=20 > B A$40E8 (016616) L$0018 (000024) 002 MODULE_IOB >=20 > B A$4000 (016384) L$0400 (001024) 006 PAGE_TXT >=20 > B A$4E00 (019968) L$04B0 (001200) 006 RWTS AIRHEART >=20 > B A$4000 (016384) L$0800 (002048) 010 RWTS16 >=20 > B A$4000 (016384) L$04F0 (001264) 006 RWTS18 =20 >=20 > A A$0000 (000000) L$029E (000670) 004 HELLO >=20 > T A$0000 (000000) L$8900 (035072) 137 T.COURS 19 REVISION 1.00 =20 >=20 > B A$0901 (002305) L$3730 (014128) 057 GOGSMITH 1.20.S >=20 > B A$3000 (012288) L$0762 (001890) 009 GOGSMITH 1.20 >=20 > A A$0000 (000000) L$020D (000525) 004 GOGSMITH 1.20.PRG =20 >=20 > T A$0000 (000000) L$0800 (002048) 008 T.LES PROGRAMMES DE CE DISK >=20 > T A$0000 (000000) L$0400 (001024) 004 T.INTRODUCTION >=20 > A A$0000 (000000) L$001D (000029) 000 COPYN6.PRG =20 >=20 > B A$0901 (002305) L$059D (001437) 007 CHRCH_NIB.S >=20 > B A$1000 (004096) L$0053 (000083) 002 CHRCH_NIB >=20 > B A$1000 (004096) L$0051 (000081) 002 CHRCH_NIB2 >=20 > A A$0000 (000000) L$01DB (000475) 003 CHRCH_NIB.PRG >=20 > B A$0901 (002305) L$03DD (000989) 005 CHRCH_NIB2.S >=20 >=20 >=20 > This catalog contains 27 files. 0 were DELETED. >=20 > ---------------------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 > Introduction >=20 >=20 >=20 > Lesson 19 : Br0derbund Protections / 18 sectors per track >=20 >=20 >=20 > 18 sectors per track? But you say it doesn't matter, my dear sir! >=20 > Everyone knows that there are always 16 sectors per track, and not more! >=20 > Why not 43 teeth per mouth or 15 years for the presidential term? >=20 > My goodness! Perhaps it is possible, no? >=20 >=20 >=20 > With information about the Apple, one can do everything .. modify everyth= ing >=20 > .. >=20 > hack everything.. The only thing is to know how! >=20 > Well then, let's see how! >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ami= cably, G. >=20 >=20 >=20 > Lesson 19, revision 1.00. >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Lesson 19 : Br0derbund Protections / 18 sectors per track Godfather >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > Revision 1.00 Update : 07 May 1988 >=20 >=20 >=20 > This lesson wouldn't have been as brilliant without the invaluable help o= f >=20 > people like Mister DD, The Gog's, Num=C3=A9ro 6, and surely, the author o= f all >=20 > this mess: Roland Gustafsson!, from the Br0derbund companty. Thank you! >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > 1. Introduction >=20 > 2. The magnetic data marks on the disk >=20 > 3. Data storage on the diskette (nibbles) >=20 > 4. The rwts18 routine, reading, writing, formatting, recalibrating, etc.= ... >=20 > 5. Copy Program >=20 > 6. Supplementary Problems: track numbers on the bad tracks, verify >=20 > 7. Adapt the copier to the new, diverse Br0derbund programs >=20 > 8. History and diagnostics of all the latest Br0derbund programs >=20 > 9. 18 sectors per track. Who says better? >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. INTRODUCTION TO 18 SECTORS PER TRACK and the problem it gives us >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > On today's menu, the current protection of the finest Apple software, you >=20 > will recognize them if I talk about Karateka, Captain Goodnight, Wings of >=20 > Fury, to name just a few.. Br0derbund. In starting this lesson, you will >=20 > perhaps be asked who is the dedicated guy: Roland Gustafsson. He's the di= ck >=20 > Gustaffson, also a lead editor of the American magazine, NIBBLE. He is th= e >=20 > "official" protector for Br0derbund. And therefore, the author of the >=20 > protection that we are studying here: 18 sectors per track. >=20 >=20 >=20 > >>>>>>>>>>>>>>>>>>>> >=20 > Deckard's notes from 07 May 2007: first of all, in the entire GDF text, t= he >=20 > name mentioned is Steven Gustavson instead of Roland Gustafsson. I have >=20 > corrected it. One must know that Steven has a connection with Roland! It'= s >=20 > about one of the easter eggs utilized in the program PRINTSHOP COMPANION.= If >=20 > you boot side 1 of the program and type STEVEN following with a press of >=20 > ESC, the screen will display in reverse!! Useless, but funny. Furthermore= , >=20 > Roland never wrote for Nibble magazine. Actually, I found many articles >=20 > written by him in A+ magazine. He was interested in programming sound on = the >=20 > Apple IIGS. >=20 > <<<<<<<<<<<<<<<<<<<< >=20 >=20 >=20 > Picture a disk containing 18 sectors per track with a total of $23 tracks= , >=20 > normally numbered from $00 to $22.. That means as many tracks as on a dis= k >=20 > formatted for DOS 3.3, but each containing 2 more data sectors, making tw= o >=20 > more $FF bytes. ($1FF bytes more per track!). >=20 > The cracking of a protection "format", as you well know, always happens w= ith >=20 > a format conversion step. The original disk has a non-standard format, we >=20 > want to convert the first one to a standard format, meaning 16 sectors pe= r >=20 > track!.. Only here, a big problem is presented! Look, to try to explain i= t >=20 > to you, here are the "capacities" of these two formats: >=20 >=20 >=20 > 16 sectors per track with 35 tracks having $FF bytes per sector.....14336= 0 >=20 > bytes >=20 > 18 sectors per track with 35 tracks having $FF bytes per sector.....16128= 0 >=20 > octets >=20 >=20 >=20 > Do you understand the problem? Not yet? Well then, I shall continue... >=20 >=20 >=20 > 16 sectors per track with 35 tracks : 560 data sectors per side! >=20 > 18 sectors per track with 35 tracks : 630 data sectors per side! >=20 >=20 >=20 > That means, considering that you find the 18 sector reading routine in an= y >=20 > original Br0derbund program, and you are also able to prepare the format >=20 > conversion, the question remains: >=20 >=20 >=20 > You have 70 sectors "too many" which are not indispensable.. Where are yo= u >=20 > going to put them, because they must go somewhere on a "deptrotected" dis= k - >=20 > that's the goal of this game - a disk with 16 sectors per track.. And >=20 > remembering that these 16 sectors per track are - in theory - already >=20 > occupied with the program's data. Am I clear enough? >=20 >=20 >=20 > Pierrette has a jug of milk that can hold only a liter, and she must brin= g >=20 > back to the village - under pain of galactic cataclysm - 1.5 liters of mi= lk. >=20 > Do you have a solution to this problem? >=20 >=20 >=20 > I am going to try, with this lesson and potentially a future lesson numbe= r >=20 > 19.2, to explain to you and to clarify the two solutions which appear to = us, >=20 > after - believe the best - intense thoughts of the entire planet! >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > 2. The magnetic data marks on the disk >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 >=20 >=20 > First thing sirs, you are going to open your mind.. be open to anything t= hat >=20 > could be said here.. to any novelty.. Expand your field of possibilities, >=20 > concentrate, breathe in., breathe out.. and understand! >=20 >=20 >=20 > For the following explanation, and I say that for the perfectionsts, I wi= ll >=20 > say ahead of time, I must alter the facts for a better comprehension. For >=20 > example, I am going to imply that the disk read head moves around the >=20 > tracks, but really it is the diskette that turns under the disk read head= .. >=20 > You may accept that the effect is identical depending on the point of >=20 > reference, and you may also equally grant that I have the right to allow = a >=20 > few "lies" which will follow, for your benefit.. Well, if you discover so= me >=20 > anamolies - because you already know too much - you don't have to accuse = me >=20 > here, I excuse myself here in advance. Off we go.. >=20 >=20 >=20 > I ask you to imagine the track of a disk. A track we will compare, to >=20 > simplify things, to a bicycle track, such as the track at Bercy. A circul= ar >=20 > track, on which one dispatches a little man (the runner) having a certain >=20 > speed. This bicyclist who will complete a loop of the track in a certain >=20 > time is compared with the read head of your drive which will make the loo= p >=20 > of a data track in a certain time. The problem presented to use is that o= f >=20 > formatting. If the reading of a track can be done sector by sector in any >=20 > time (one can read a track a few sectors at a time, and if one's drive is >=20 > too quick or the reading routine is too slow, one must come back a second >=20 > time, see a third time to get the rest). >=20 >=20 >=20 > The formatting is a "cut" of a track in sectors according to a given form= at. >=20 > For the formatting, the problem is different. One cuts the disk, and the >=20 > third sector, for example, no matter which format, 19, 18, 16, 13 sectors= or >=20 > otherwise, must be placed immediately after the second (physical sectors)= , >=20 > and immediately after the first.. Everything must be cut after sector 0, >=20 > which marks the "start of the cut", and just up to the last sector, in a >=20 > single pass! In a single loop of the disk surface. >=20 >=20 >=20 > One will assume that our bicyclist leaves from the starting line (which i= s >=20 > also quite close to the finish line - the end of the track), with a set o= f >=20 > 18 flags, because there are 18 sectors per track. He is going to leave a >=20 > flag every 22.22 meters around a track of 400 meters in circumference. Fo= r >=20 > example. It takes a certain time to cease a flag and its pole, and again = a >=20 > certain time to place it to mark the start of one of the cuts of the trac= k, >=20 > of one of the divisions which he must make there. From one of the sectors= of >=20 > the track it will go. The problem, I restate, is that he must place all o= f >=20 > the flags in a single loop.. and if, on these 18 flags, he only ends up >=20 > placing 17, for example, the formatting of this track must start again. T= he >=20 > desired number must be placed from the start, according to the format. >=20 >=20 >=20 > You understand well further that the bicyclist moves slowly around the >=20 > track, so he will have time to place these flags, and therefore be able t= o >=20 > plant a large number of them. In 1979, DOS 3.2 contained only 13 sectors = per >=20 > track for speed. The drive proposed by Apple at the start wasn't reliable >=20 > enough, also the formatting was done more slowly, and our bicyclist could >=20 > not have the time to put barely just 13 flags. Understand that "flag" mea= ns >=20 > field address, the separation point between two sectors on the track, and >=20 > understand that between two flags, data are written (the tread of a tire >=20 > rests on the track.. if you wish (!?)). We are going to see much later th= e >=20 > head of these flags and the mark of the tire tread on each 18 sector trac= k, >=20 > when I talk about the 18 sector format. >=20 >=20 >=20 > Now, we went only to 16, and BR0DERBUND, with some slow drives, has >=20 > formatted a disk with 18 sectors. If our drives are of a good speed not t= oo >=20 > fast (you can test their speed with a program called Copy II+ 5.x, or EDD >=20 > v4.2), you can then copy the Br0derbund programs without too many problem= s. >=20 > Although sometimes there are a few boot modifications (generally on track >=20 > $0) to get a working copy. Whatever the speed of your disk drive head, 18 >=20 > sector programs boot just as well no matter which drive, but don't copy a= t >=20 > all from the nibble copier. (in theory, the copier must work everywhere, >=20 > functioning at a "normal" maximum speed.) >=20 >=20 >=20 > Apple hasn't yet made - and won't make - DOS 3.4 with 18 sectors per trac= k >=20 > for this reason: all the drives, they can read 18 sectors, but they can't >=20 > all format 18 sectors. >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > 3. Data storage on an 18 sector diskette >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 >=20 >=20 > In general, several tracks (track $00, or even tracks $00 and $01) are in >=20 > the DOS 3.3 format, 16 sectors per track. All of this is normal, and thes= e >=20 > are the tracks which contain the famous rwts18. But leave me rather to te= ll >=20 > you about the 18 sector format in quesetion. >=20 >=20 >=20 > In fact, we talk of 18 sectors per track because each track has the >=20 > equivalent data of 18 DOS 3.3 sectors of $FF bytes, making $17FF bytes, b= ut >=20 > on the disk, the data are regrouped into macro sectors. It doesn't add up= , >=20 > therefore, 18 sectors of $FF bytes, mais 6 sectors of (3 * $FF) bytes, th= ese >=20 > amount to the same incredible count of $17FF bytes per track, versus $15F= F >=20 > per track which we are offered in in the 3.3 format. >=20 >=20 >=20 > The first macro-sector corresponds to sectors 00,06,12. >=20 > The second macro-sector corresponds to sectors 01,07,13. >=20 > The third macro-sector corresponds to sectors 02,08,14. >=20 > The fourth macro-sector corresponds to sectors 03,09,15. >=20 > The fifth macro-sector corresponds to sectors 04,10,16. >=20 > The sixth macro-sector corresponds to sectors 05,11,17...making 18 >=20 > secteors!! >=20 >=20 >=20 > Each macro-sector is constituted in the following manner: (to make a >=20 > comparison with the 3.3 format, refer to lesson 6) >=20 >=20 >=20 > _________________________________________________________________________= ____ >=20 > ! = =20 >=20 > ! >=20 > ! ( 18 SECTOR FORMAT ) = =20 >=20 > ! >=20 > ! = =20 >=20 > ! >=20 > ! - A field address : Prologue D5 9D = =20 >=20 > ! >=20 > ! = =20 >=20 > ! >=20 > ! Track NN ! CONVERT WITH THE HELP OF A = =20 >=20 > ! >=20 > ! Sector NN ! CONVERSION TABLE = =20 >=20 > ! >=20 > ! Checksum NN = =20 >=20 > ! >=20 > ! Epilogue AA = =20 >=20 > ! >=20 > ! = =20 >=20 > ! >=20 > ! - Two self-sync nibbles FF FF = =20 >=20 > ! >=20 > ! = =20 >=20 > ! >=20 > ! - A data field : Prologue A4 ! variable, according to program, >=20 > WATCH!! >=20 > ! (I will refer to the prologue as "the header which can vary"!)= =20 >=20 > ! >=20 > ! = =20 >=20 > ! >=20 > ! Data $400 NIBBLES (4 Nibbles --> 3 Bytes) = =20 >=20 > ! >=20 > ! Checksum NN = =20 >=20 > ! >=20 > ! Epilogue D4 = =20 >=20 > ! >=20 > !________________________________________________________________________= _____! >=20 >=20 >=20 > The nibbles are converted into bytes on the fly while being read, with th= e >=20 > help of a conversion table. This is contrary to DOS 3.3, where the >=20 > conversion (post-nibblization) happens in a buffer after the nibbles are >=20 > read. >=20 >=20 >=20 > On the other hand, some Br0derbund software, such as was the case for >=20 > Airheart, the track $1C doesn't exist. The track was identical to track $= 1B >=20 > and was numbered as track $1B in the field address. But it's a "plus" whi= ch >=20 > isn't really important in regard to the "18 sectors" protection, and it >=20 > hasn't been employed in any of the recent Br0derbund programs. Therefore,= no >=20 > panic! We will talk about it in the 'Cracking' lesson, but here is a bit >=20 > below.. >=20 >=20 >=20 > [ Traduction Anglais par DF ] >=20 >=20 >=20 > --=20 >=20 > ]DF$ >=20 > Mac GUI Vault - A source for retro Apple II and >=20 > Macintosh computing. >=20 > http://macgui.com/vault/
![]() |
0 |
![]() |
Oh THE Roland! What a great honor to have you here. I have thousands of questions to you. Antoine, a still active programmer and "pirate" Brutal Deluxe Software hackzapple.com forum
![]() |
0 |
![]() |
Necro'ing ... What was the first game to use RWTS18 ?
![]() |
0 |
![]() |
> Necro'ing ... >=20 > What was the first game to use RWTS18 ? Airheart? Next thing - Trinity and the other multi-side titles from Infocom used _the= ir own_ 18-sector format. Not related at all. It's one giant sector, and = they do a blind search for the right region. Every single time. Fortunate= ly for them, you're busy reading the text at the time, so the impact is les= s obvious. Then, writing to RW18 does touch the entire track because it must, but it c= an perform "surgical" replacement of the sectors within that track. Finally, a true 16-sector .dsk conversion of Toy Shop is available from Asi= mov. It seems that I never announced it here.
![]() |
0 |
![]() |