TURRICAN II

So let?s start with loading the first (and only dos-readable) track into memory to
have a look what?s going on …
Enter your AR and type in the following: rt 0 1 50000
… let?s begin with disassembling the bootcode at $5000c, type: d 5000c and
scroll down like in the picture below.

The first interesting thing we can see here is very typical… from adress $50032-$50050
the trackdisk-device is used to read $800 bytes from disk-position $400 into memory
location $60000. In the last 2 instructions at $50080 / $50088 an exception
is caused and our little program is continued in memory at adress $60000. So
this will probably be one of the gameloaders!
Let?s save those datas to a disk at first, we will use them l8r on. So put a blank
one into df0: and save the stuff like this:
SM bootblock, 50000 50400
SM loader, 50400 50400+800
Let?s continue our work with disassembling the loadercode… we could disassemble
from adress $50400 now but due to the fact that we know the loader is located at $60000
we will load it into that position before we continue…
Type in: LM loader, 60000 … and start disassembling with d 60000 …
You will see something (no, exactly) this code:

The code begins with some standard stuff like killing all interrupts, pointing the
stack register to some memory location, setting up a copperlist and so on… But after
that i found some lines which really looked interesting to me… take a look at the
instructions at $60030. The longword-value $52412D49 is moved into d0, the value $30000.l
is moved into d1 (perhaps an memory adress?) and another parameter is moved into d2
($1) before calling the routine located at $60164. After returning from that subroutine
the program jumps to $3010A. Hmmm… $3010A?! Sounds similar to the value moved into
d1 ($30000) before we branched to $60164 … Let`s take a look onto the next 4 instructions
… again a value is moved into d0 ($4D41494E.l), another one into d1 ($c0.l) and
even d2 is again set to value $1. Well… if you continue disassembling some lines
(no picture included) you can see that the program continues execution at adress $C0
!!! $C0 ? Wasn`t that the value in d1 before we branched to $60164 the second time?

After having another bottle of beer I came to the point that $60164 seems to be some
kind of a loaderroutine which is called with 3 parameters. D1 could be the adress
where the loader is tracking to.. but what does the value in d0 mean?
Lets view the loader memory at $60000 in ASCII… type: n 60000 and take
a deeper look!

Again i?ve marked the interesting stuff in red …. we can see the three longword
value?s “RA-I”, “MAIN” and “PP20” (Powerpacker-Header?) which really looked interesting
to me and some hundred of bytes in between the code which is completely zero?ed!.
After checking how the two values “RA-I” and “MAIN” are included in the code i?ve
recognized that this is the stuff which is moved into d0 before our loader is called.
So the loadercode looks like this:

move.l #”RA-I”,d0
move.l #$30000,d1
moveq #1,d2
bsr $60164
jsr $3010a
move.l #”MAIN”,d0
move.l #$c0,d1
moveq #1,d2
bsr $60164

The value in d0 seems to be some kind of a filename…. but if so, the gameloader
must probably have some kind of a lookup-table somewhere which tells the trackloader
where those files are stored on disk, but while stepping through memory between $60000-$60800
I cannot really find something like this. Anyway… let?s try to rip those two files
at first and find out what the third parameter in d2 is all about… perhaps he is
tracking the lookup-table into memory when the loader is called the first time (guess
what, it is so!).
Insert your Original Turrican Disk now and let us do some patching in the loadercode
like this:

We will insert two lines after the code returns from the possible trackloading-routine
at adress $60042 which will set the screencolor to red in an neverending loop! So
type in the following:
a 60042
^60042 move.w #$f00,$dff180
^6004a bra $60042
and then… jump into the loadercode like this: g 60000 !!!
Yes…after some tracking the screen turns red and nothing happens at all… so the
trackloader has finished with the file and the processor seems to hang in our loop!
So enter AR to look what has happend… if the parameter in d1 ($30000) is really
an memoryadress we will perhaps see some code or anything there… let?s check it
out!
Type in: n 30000

That?s it… after stepping through the memory you are able to see that the loader
has really loaded some undecrunched data into memory… Now lets have some “learning
by doing” with the parameter given in d2!!! Instead of moving $1 into d2, let?s see
what the loader is doing if we clear that one!
Let?s disassemble the code again to find out where the “moveq #1,d2” instruction is
executed and replace it with an “moveq #0,d2” like this:

a 6003c
^6003c moveq #0,d2
^6003e
… and then jump to the loader again typing: g 60000
After some tracking we will see our red screen again which tells us to enter the AR
and take another look into memory at adress $30000.
Type in: n 30000 and see what happened now:

Yeah… the data begins with “PP20” which means that the loader just tracked in the
file without decrunching it. So the parameter in d2 seems to tell the loader if the
file is crunched with PP or if it?s either undecrunched or packed with anything else!
Now that we (hopefully) know how the loader works, let?s see what has happened to
our loadercode at $60000. We talked about some kind of a lookup-table some lines ago…
let?s see if something changed there.
Type in: n 60000

Wow…the region that was zero?ed before calling the trackloader has now been filled
up with some data. Let?s take a nearer look at those bytes…
Type in: h 60204 and scroll down some lines…

Yessss… this looks like a Lookup-Table to me, eh? It begins with the file “RA-I”
and ends up with the files “L4-1” and “MUS4”! (Remember the size of this filetable…
it?s !400 Bytes!!)
Well okay… let?s have a little break and think of what we know by now… We seem
to be able to rip those files stated in the lookup-table by calling the loading routine
and passing the filename in d0. But how do we know about the filesize?! Doesn?t that
value have to be included in the lookup-table as well and if so, which value is it?
There are a lot of numbers in between the filenames. So let?s go and find it out with
a little trick. We will call the loader again to track that “RA-I” file into memory
at adress $30000. But this time, we will fill up that memory-area with some “A” bytes
before, so when loading has finished, we can see how many bytes have been changed!”
Type in: o “A”, 30000 50000 (this fills up the memory from $30000 to $50000
with the given byte-value) and then do another jump to our loader routine with: g
60000.
After that fancy red-screen we enter our AR again and scroll down the lines from $30000
until we see those hundreds of “A” bytes… after checking where the first “A” appears
we notice a length of $40f0 bytes!!! Remember that value and take a look into the
filetable stored at $60204 again. STRIKE! Look at the longword-value at offset $8
from the start of the table. This must be the filesize. Lets try to load the “MAIN”
file into memory now to make sure that we?re right! So fill up the memory at $30000
with “A”?s again like stated before and then do the following …

Change the value which is moved into d0 from “RA-I” to “MAIN” at adress $60030!
Type in: n 60032 (we take adress $60032 coz the first 2 bytes are the “move.l”
instruction!!)
and replace the 4 bytes “RA-I” into “MAIN” and hit return so the the AR recognizes
our little change! Remember to write “MAIN” and not “main” or “Main”, coz otherwise
the loader won?t find the file in the lookup-table! Continue with jumping to our loader
again with typing g 60000 !!! Now after some more tracking the screen turns
red again and we know that loading has finished. Now scroll down the memory at $30000
(“MAIN” also seems to be powerpacked!) until you reach our with “A”?s filled up area.
Remember the length of the filedata (which should be $e068 bytes) and compare it with
the value in the lookup-table!!! WE WERE RIGHT!!! It?s the same!

Well… we could start with ripping off all files from the Original Disk now but i
won?t !! 😉 Now that we know a lot about how the loader is working, we will first
boot the game up just to check what the “MAIN” file is doing after being loaded into
memory at $c0! Due to the fact that we have to put those files back onto a disk lateron
and we will have to write our own trackloader it might be interesting to see how many
of these loaders the game consists of coz we have to patch them all!

Okay reset your machine, put in the Original Disk and load it up… when the Rainbow
Arts Intro is finished and the game continues tracking some data from disk just enter
your AR and let?s disassemble the code at adress $c0 where the “MAIN” file should
be located. The first instruction is a branch to another memory adress ($123e, picture
not included) so let?s continue disassembling from adress $123e with d $123e…


Now in these few lines of code you will see something familar… from adress $1294
on another routine is called 2 times with a branch to $6f8 which seems to take
the same parameters as our first loader that we?ve been in before! That?s nice coz
we only need to code one new trackloader then for both the loader at $60000 and the
one located somewhere in the “MAIN” file. Before we go deeper into the trackloader
let?s have a short view into the memory at $c0 in ASCII just to see if there is another
lookup-table or if the old one on $60204 is used! Type n c0 and scoll down
some lines.

As we can see there is something interesting starting at adress $802. This
is our lookup-table that we?ve seen before. But if you scroll down some more lines
you will recognize that this table seems to be complete because it doesn?t end with
“L4-1” and “MUS4” but with “L5-2” and “EDAT” which probably means the END-DATA! So
let us continue with saving this complete lookup-table to disk for later use like
this:
SM filelist, 802 9e2.
Remember the size of this complete filelist also, it?s !480 Bytes!
After some testing i came to the point that this loader located at $6f8 is
the only one that the game is using up to the end. So let us come to something easy
now… As we know all the filenames we can continue our little crack with ripping
all the files from the disk… I will use the first loader for that so reset your
machine, insert your savedisk and load our file called “loader” which we saved at
the beginning of this tutorial to adress $60000 again with typing LM loader, 60000
! Now you are over some fun for the next hour with ripping all the files to disk …
if you are a coder you could program some lines that will rip all the files automatically
but i won?t explain that now coz i guess this tutorial is getting large enough!

1. Insert your Original disk again!!!
2. Jump into the loadercode using g 60000!
3. Insert your savedisk!!!
4. Save the file with SM filename, $30000 $30000+filesize
5. Change the filename which is moved into d0 with n 60032 and typing in the
new filename + return!
… Step to Point 1 !!!

Note: If your computer should crash for example at file “L1-1” or something
then you don?t need to begin from file “RA-I” after resetting your machine. Just load
in the patched loader again and start with the last file you?ve read in… then continue
with the next one in the table and so on!
Loop this until you?ve ripped the file called “MUS4” which is the last entry on our
filetable at $60204. To get in touch with the last files which are “L4-2”, “L5-1”,
“MUS5”, “L5-2” and “EDAT” we will copy the last 5 filedatas from the complete filetable
on disk into the one we are using at the moment at adress $60204. We can overwrite
the first 5 datas without getting troubles because we have already ripped them so
insert your savedisk and type in….
LM filelist, 5f000 and scroll down to the end using…
m 5f000. You will see something like this…

Then let?s copy the memoryblock with the last 5 filedatas into our current used lookup-table
at adress $60204 like this:
trans 5f190 5f1e0 60204
Now you can continue ripping the last files from “L4-2” to “EDAT” like you?ve done
before….
… so now… CONGRATULATIONS!!! We can put the Original-Disk back into it?s
case … we won?t need it anymore!

Note: To make things easier for you at the end of this tutorial it would be
a good idea to create an directory on your harddisk (you own one, do you?) and copy
all the files into it…!

Now for some coding stuff… due to the fact that we will have to put those files
back to disk in the near future and we?ll have to code an own trackloader it is neccessary
that we understand how the trackloader on Turrican II works …. As we?ve seen in
the beginning of the tutorial there are 3 parameters given from d0-d2 before the ?so
called? loader is being jumped to! As we know the third parameter in d2 has something
to do with uncrunching or something, so the routine at $60164 is not only the pure
trackloader … it even seems to consist of another routine which is able to unpack
the tracked datas. We ripped the files in crunched format so we will still need this
unpacking routine for our files… so let?s find out where the ?real? trackloader
starts and what kind of parameters it will need 2 work. Let?s disassemble our loader
from $60164 with d 60164 and scroll down some lines…

———————————————————————————————–
$60164 TST.L $60204 ; Is the lookup-table already loaded?
$6016A BNE $60186 ; Yep… continue.
$6016C …
$60170 …
$60176 Not neccessary for us… branching to a routine that seems to set up the lookup-table
$60178 to adress $60204!
$6017A …
$6017E …
$60182 ….
$60186 LEA $60204(PC), A1 ; Store adress of our filetable in A1.
$6018A MOVEQ #$18, D3 ; How many files are stored in the lookup-table.
$6018C CMP.L (A1), D0 ; Compare the filename given in D0 with the lookup-table entry.

$6018E BEQ $6019C ; Found the file… Continue code at $6019C (A1 now points to the
correct entry in the filetable)
$60190 LEA $10(A1), A1 ; Let the filetable point onto the next entry!
$60194 DBF D3, $6018C ; Continue searching until d3 gets -1 !!!
$60198 MOVEQ #$-1, D0 ; Errorcode in D0 -> File not found! 😉
$6019A RTS ; Get back to where we came from!
———————————————————————————————–
$6019C MOVE.L 8(A1), D0 ; Remember Offset $8 ? -> Move?s filelength into D0.
$601A0 MOVE.L D1, A0 ; Remember D1 ? -> Puts our ?where to load to? adress into A0.

$601A2 BTST #$0, D2 ; Remember our Crunchparameter D2 ? -> Testing Bit 0 ?
$601A6 BEQ.B $601B8 ; Zero… no need to unpack… continue at $601B8
$601A8 SUBQ.L #$8, A0 ; Well… our ?where to load adress? is getting sub?ed by 8!
😉
$601AA MOVE.L (A0), $601FC ; Save the 8 Bytes before ?real? loading adress… this
seems to set up 8 Bytes
$601B0 MOVE.L 4(a0), $60200 ; for the “PP20” header (4 Byte) including the depacked
filelength (4 Byte)
$601B8 MOVEM.L D1-D2/A0-A1, -(A7) ; Save neccessary regs on stack.
NOW OPEN YOUR EYES… THE INTERESTING 4 INSTRUCTIONS COMING UP!
(Remember A1 points to lookup-table!!!)
$601BC MOVE.W 4(A1), D1 ; The word-value located at filetableoffset+4 into d1.
$601C0 MOVE.W 6(A1), D2 ; The word-value located at filetableoffset+6 into d2.
$601C4 EXT.L D2 ; Enlarge d2 to longword.
$601C6 BSR.W $60394 ; Guess what !!! This is the trackloader!
$601CA …
———————————————————————————————–
Well… now there is nothing more we need to know about the trackloader.
It is located at Adress $60394 and is given the following parameters:
D0.L -> LENGTH OF THE FILE.
D1.W -> WORD VALUE STORED AT FILETABLE OFFSET +$4
D2.W -> WORD VALUE STORED AT FILETABLE OFFSET +$6 (enlarged to longword)
A0.l -> MEMORYADRESS
The registers in d1 and d2 are surely used to tell the loader where the file is located
on disk.
Something like “D1 = TRACK NUMBER” and “D2 = OFFSET FROM BEGINNING OF THE TRACK” !!!

The same code as stated above is used in “MAIN” as well… the trackloader begins
in memory at adress $9e2 and of course, takes the same parameters! I think there is
no need to show any pictures for that one!
But we won?t bother with that any longer … next Part will be saving the ripped files
onto a normal dos disk using the trackdisk-device and making some changes into the
file-lookuptable. As you may have guessed we cannot place the files into the locations
that were used on the original disk because we won?t get the same amount of data-bytes
written on a ?dos-track? as on the Turrican Gamedisk. Next part is coming up…

If you have added the filelength of each file you might have recognized that we won?t
come up with one disk… so on the first disk we will store the files “RA-I” up to
“L3-3” so that you have to swap the disks before the game begins with Level 4 ! To
tell the loader on which disk the current file belongs to, we will use the tracknumbers
from 0-159 for disk 1 and 160-xxx for disk 2 in the filetable (a disk consists of
160 tracks, numbered from 0 – 159).
So before we are going to make the disk-image we still have one thing forgotten…
we know that there is a seperate loader in the “MAIN” File which we also have to patch
l8r on…. as we saved the file “MAIN” in powerpacked format we will have to decrunch
it first and then write it to our disk uncrunched, so it will make the forthcoming
patching easier for us (and for the trainermakers hehe)… So let?s unpack the file
either using the Powerpacker or XFD or something and write the unpacked file (!132568
bytes) back to (one of) yor savedisk(s), overwriting the old “MAIN” file which is
not needed anymore in packed form! Now it?s time to start your Assembler, in this
case ASM-One, and let?s begin to write the diskimage!
Reserve some ram, change into the editor-mode using -ESC- and type in the following:
(of course you have to change the pathname to the point where you?ve saved the files
to…!)

If you don?t have enough ram in your machine you will have to write the diskimages
in 2 steps lateron (Part 6)…. also if you are not an owner of a harddisk (I can?t
believe it) and you still have the files stored on 2 disks you will have to do this
also (perhaps not with using a second drive)…. I guess I don?t have to explain that
to you!
First of all we include the bootblock (!1024 bytes) followed by the first loader (!2048
bytes). Then we fill up the remaining !2560 bytes of track 0 (a track has a size of
!5632 –$1600- bytes!) with zero?s! Then we insert three empty tracks for a nice cracktro,
followed by the gamefiles as they appear in the lookup-table. We will save all the
data to disk later on using ASM-One?s “wt” (Write Track) command…
If you have finished with the diskimage we can begin to overwrite the original values
in the filetable with our trackpositions on our crackdisk. Leave the Editor using
-ESC- again and save the diskimage-sourcecode to your disk using the -w-
command, naming it for example “image”.
We will kill the source now using -ZS- (Zap Source) to begin our small filetablepatcher-code…
we will program a few instructions that will fill up the lookup-table automatically
with the correct values…. so change into the editor again (i guess you know which
key to press now) and type:
(And again don?t forget to change the path of the filetable… explanation follows!)

The second instruction is really important, due to the fact that we unpacked the main
file we have to write the new filesize, which is !132568 ($205D8) bytes, into the
filetable (each entry is !16 bytes, so the offset to the filelength of “MAIN”, which
is the second file in the table, is offset !16 + !8)!!!
In the maincode a bytecounter in d1 is used which stores the position of the actual
gamefile on disk as bytevalue. We start with “RA-I” on track 4 which means at the
disk-position 4*$1600 (remember a track has the size of $1600 bytes). Then the bytecounter
is divided with $1600 to get the current track number of the file (in the first loop
-4- of course) and stores it in the filetable… then we swap that value to get the
rest of our division which in fact is the byteoffset to the file on the track (-0-
in the first loop) !! Now the filelength of the actual file ($40f0 in the first loop)
is added to the value of our bytecounter in d1, changing it to 4*$1600+$40f0 then.
Finally we point a0 to the next entry of our filetable and start the same act again
until we get to the end of the filetable. If the file “L4-1” is reached, the bytecounter
is set to “160*$1600″ because from now on the files belong to disk 2, starting at
track 0 again! Our own loader will check the trackposition lateron and if it?s larger
than 159 it will make the screen flash so that the user knows the disk has to be changed
(of course the other way round as well, if disk 2 is placed in drive and disk 1 is
needed!).

Okay, if you understood that stuff, leave the editor-mode with -ESC- and let?s
assemble the whole thing.
Type in: A and hit return…
If you typed everything in correct form and you don?t see any error-messages, start
the code with J and hit return!
Now our filetable should be patched… check it out with typing H filetable
and hit return. Now your values in the filetable should look like this:

If you see the same on your screen then save the patched filetable to disk, naming
it for example “filetablepatched”!

D0.l = Bytes to read
D1.w = Tracknumber (where the start of the actual filedata is located in!)
D2.l = Byteoffset (the byteoffset, where our file starts on the track)
A0.l = Memory Loadadress

Well… you won?t understand the next few lines of code if you have never programmed
a hardware trackloader… I?ll post it here anyway so you can copy and paste it into
your sourcecode…. I will not show any screenshots here because guess what, you cannot
copy and paste out of a picture hehe… By the way: This loader is a ?trackgrinding?
one coz it will always step back to track 0 and then walk up to the track where the
current file is on! Njoy the sound! 😉

; =================================
; Trackloader for Turrican 2.
; D0.l = Bytes to read
; D1.w = Tracknumber
; D2.l = Trackoffset
; A0.l = Buffer to read
; A6.l = $dff000
;==================================

bytecounter: dc.l 0
kopfstatus: dc.b 0
diskstatus: dc.b 0
trloadend:

Now if you are ready with typing in (or ?pasting?) the sourcecode do the following:
Assemble the stuff using -a- and return.
Save the trackloader to disk as binary using -wb-, naming it for example “trackloader”,
and save from label “trload” – “trloadend” which are exactly 484 ($1e4) bytes at all.
Now (don?t forget to save the sourcecode) it?s time to patch our two files “loader”
and “MAIN” with the new filetable and the new trackloading routine…

Let?s use the AR for our patching-action again so enter your cartridge NOW!
We?ll start with the loader, type in LM loader, $50000 and hit return.
We know that the lookuptable is stored at adress $60204 in memory, so the offset to
the beginning of our loaderroutine is $204. So let?s load up our patched filetable
to e.g. adress $45000 and then copy it into the loadercode!
Enter: LM filetablepatched, $45000
Now transfer the first 400 bytes of it into the correct position (we only take the
first 400 bytes because as we know the lookuptable in the loader was not complete
and copying all the 480 bytes would overwrite a bit of our trackloader that is located
at the end of the filetable!)
Enter: trans $45000 $45000+!400 $50204 !
Now we have to do the same with the trackloading routine. As seen in one of the previous
parts, the trackloader starts at $60394, which means that the offset to loaderstart
is $394.
So let?s load up the trackloader as well, we will take adress $46000 for it!
Enter: LM trackloader, $46000 and copy it into the loader using…
trans $46000 $46000+!484 $50394
(If cracking other games you will of course always have to check the length of
the original and of your new coded trackloader so if your new one is larger you will
get some problems with simply ?overwriting? the old one hehe!)
Before writing the patched loader back to disk now we may not forget to change the
parameter in d2 before the loader is trying to catch the “MAIN” file to #0
because we will write the “MAIN” file uncrunched to disk… so if we would
leave the “moveq #1,d2” back in the code, the loader would try to unpack an unpacked
file which would cause the game to crash! So let?s change that instruction now…

Enter: a 50054 and insert an “moveq #0,d2” followed by -enter-!
Now we are ready to write the patched loader to our disk again with typing:
SM loader, $50000 $50000+!2048

Okee, now for the same patching action with the “MAIN” file. Load it in with:
LM main, $50000
We know that the lookuptable is stored at adress $802 in memory, so the offset to
the beginning of main is $742 ($802-$c0).
Let?s copy in the complete lookuptable now with:
trans $45000 $45000+!480 $50742
Now the same again for the trackloader which is in memory at adress $9e2, so the offset
to the startadress of main is: $922 ($9e2-$c0).
Enter: trans $46000 $46000+!484 $50922

Now finally we got “MAIN” patched as well… but before saving it we?ll have to patch
2 other things that i didn?t explain before! 😉
The game is ?loading? and ?saving? the highscores which will make the game crash if
not finding the original trackformat on our crack… there are two simple ?branches?
which we have to remove so that this doesn?t happen anymore. There is no deeper explanation
of how I found those branches because there was no special way of finding it… sometimes
you can spend hours with searching for such jumps! 😉 You will find those 2 bastards
here:

So let?s ?nop-out? the first, and ?rts-out? the second one like this:

A $511D0
^511d0 nop
^511d2 nop
^511d4
… and finally …
A $5032e
^5032e rts
^50330

Let?s save the file back to disk now using:
SM main, $50000 $50000+!132568

So after the second disk has finished tracking… Insert Disk One again, reset & enjoy
(not) !

At last some greetings to the best trainermaker on da earth: SIRIaX! …
and to the last cool Demogroup on Amiga, *cREATiVE MiNDs* ! 🙂