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/

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

Necro'ing ...

What was the first game to use RWTS18 ?

> 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.