D Finnigan

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

D Finnigan

Michael J. Mahon wrote:
> Antoine Vignau <antoine.vignau@laposte.net> 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...f19/Gdf19.html
>>
>> antoine
>>
>> ps. I hope you read French ;-)
>
> Unfortunately, I don't. ;-(
>
> I presume that there are not 18 separately addressable sectors, but rather
> a few large (>256 bytes) sectors that add up to 18 "sectors worth" of
data.
> It sounds like only whole tracks are read.
>

Yep, they are called "macro-sectors." I translated the part of that "lesson"
that explains how they work. (see my most previous news article)

--
]DF$
Mac GUI Vault - A source for retro Apple II and
Macintosh computing.
http://macgui.com/vault/

Vladimir Ivanov

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.

D Finnigan

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!

Antoine Vignau

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

Vladimir Ivanov

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.

D Finnigan

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/

D Finnigan

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/