How to get T2: Arcade Game loading screen to display correctly?

MethodGit · 29 July 2012, 17:58

T2: The Arcade Game isn't really a difficult game to crack at all, but one thing that's always bothered me is this...

I've seen this happen on ADFs of the first disk in general. The Fairlight crack (the only crack I know of) never attempted to fix it either. Curiously, this effect doesn't occur on eADFs, which leads me to worry that this is one of those games that decided to store some data on uncopyable parts of the original disk. Looking at the WHDLoad version doesn't help as it loads the game so quickly that the screen never pops up at all. I've tried consulting the code live while it's booting up but couldn't find anything to reverse the rainbowizing effect inside.

Hopefully this doesn't require replacing well over $500 bytes of code or anything silly like that?

Codetapper · 29 July 2012, 23:25

The original IPF works fine so it must be a cracking/training mistake. If you check the original, the copperlist is at $7087a and the colour palette is at $708c6. The values are all normal.

The cracked version has garbage at $708c6, with invalid colours like $aa67 and $2e29, so clearly something has overwritten the legitimate data.

@MethodGit: I find it extremely strange that you could also crack the original and also have the corrupt palette problem unless you're modifying the exact bytes that FLT did (unlikely!). Are you sure you're not copying their crack rather than doing it yourself from scratch?

MethodGit · 29 July 2012, 23:48

Perhaps I should've mentioned that the colour issue above happens on virgin/uncracked ADFs as well. So it has nothing to do with values being modified by cracks and the game picking those up.

And I'm certainly not just recycling FLT's code btw...... I like to make my own cracks for games!

Codetapper · 30 July 2012, 00:24

I loaded SPS 151 into an A500 config and it had perfect colours too. So I'm not sure what you mean by uncracked ADFs as if it's uncracked, it'll have the copylock in and if it's the original SPS, then it's not an ADF.

Some games have the odd bug where a copperlist initialisation is done in the wrong order and maybe some configs that causes a problem. ie. Writing to copjmp1 before setting the copperlist pointer, but I don't think this is the case.

dlfrsilver · 30 July 2012, 00:45

smells just corruption here

MethodGit · 30 July 2012, 00:48

Well I decided to check out the copperlist and palette at the addresses you mentioned to get a better picture.

Somehow, it appears what values are written in them are determined by the disk format type it detects. On an IPF and an extended ADF, the correct values are written, but on a plain 880KB ADF, things go skewiff. Again, totally uncracked ADF (as in, just converted/imaged from an IPF, original copylock intact) tested.

There is a particular routine executed at $70000 during loading that appears to decide the values that will go into the palette. Alas, it is a long piece that I can't make head nor tail of. All in all, it looks like it decides its numbers from the disk geometry.

StingRay · 30 July 2012, 11:55

Quote:

Originally Posted by MethodGit

T2: The Arcade Game isn't really a difficult game to crack at all,

Apparently it is, at least for you.

Quote:

Originally Posted by MethodGit

There is a particular routine executed at $70000 during loading that appears to decide the values that will go into the palette. Alas, it is a long piece that I can't make head nor tail of. All in all, it looks like it decides its numbers from the disk geometry.

This "particular routine" at $70000 is the trackloader... I didn't have a closer look yet but I'm quite sure the Copylock decrypts the palette. If the game isn't correctly cracked, the garbage will appear.

Codetapper · 30 July 2012, 12:42

Quote:

Originally Posted by StingRay

I didn't have a closer look yet but I'm quite sure the Copylock decrypts the palette. If the game isn't correctly cracked, the garbage will appear.

I don't think the copylock has even run at this stage so I don't believe that's the problem in this case. Maybe the crack has overwritten palette data or something.

@MethodGit: In any case, this is a perfect case for YOU to solve and not let us do the work for you. It seems a simple crack to me, there's nothing hidden in the copylock:

Code:

cl t2a.bin
Copylock Decrypter v0.01
(c) 2004 Codetapper of Action (codetapper@hotmail.com)

Copylock header found at $0
Copylock stack 1 found at $7a
Copylock stack 2 found at $512
Copylock key wiring position found at $530
Copylock key wiring skip to position found at $57a
Post copylock branch to address starts at $922
Copylock new magic number ($a573632c) compare at $59e

======[ Key calculation routine found at $600: ]======
_600    move.w  #$b,d1
_604    add.l   d6,d6
_606    sub.l   (a0)+,d6
_608    dbra    d1,_604
_60c    addq.l  #4,sp
_60e    rts

======[ Post copylock code starts at $922: ]======
_922    lea     $78(sp),a6      ;Set a6 to real copylock registers
_926    move.l  d0,$14(a6)      ;Store serial number in real d5 register
_92a    move.l  d0,($f4).w      ;Serial number stored at $f4
_92e    move.l  $3984ec01,d0
_934    move.l  d0,(a6)+
_936    move.l  d1,(a6)+
_938    rol.l   #1,d0
_93a    move.l  d0,(a6)+
_93c    rol.l   #1,d0
_93e    move.l  d0,(a6)+
_940    rol.l   #1,d0
_942    move.l  d0,(a6)+
_944    rol.l   #2,d0
_946    addq.w  #4,a6
_948    move.l  d0,(a6)+
_94a    rol.l   #1,d0
_94c    move.l  d0,(a6)+
_94e    moveq   #$0,d0
_950    moveq   #$1,d0
_952    lea     _964(pc),a6
_956    move.l  -$4(a6),d6
_95a    add.l   $8,d6
_960    or.w    #$a71f,sr
_964    addi.l  #$44,($24).l
Copylock stack 2 ends at $964

MethodGit · 30 July 2012, 13:23

Update: Well, I've been keeping an eye of $78874 and thereabouts since that's where the two bad colour values appear in the first place, and...

In the original, it loads the correct values and a small part of the copylock(!) into that address, before disappearing again (copylock is loaded from a different address).

Technical information coming up:

Comparing the memory dumps of both an IPF and an ADF, data from $78600 starts to differ dramatically. The correct behaviour is to load $400 bytes of data from the offset $B6600 of the ADF, but for whatever reason this data is not being loaded/decoded correctly from a copy. Like I said, there is a major routine at $70000 - and a subroutine at $70658 - that determines what data gets loaded in the end. I'm still trying to look at it and understand it better as I speak. Also, for whatever reason, WinUAE's debugger doesn't seem to notice when the disk data from $78600 onwards suddenly changes into either the good or bad data, so I can't pinpoint precisely which command is giving birth to AA67 and 2E29.

Oh, and CT? I cracked the copylock eons ago. Copylock has precisely jack all to do with the palette problem. As you already said, this happens before the copylock even comes into play.

StingRay · 30 July 2012, 13:29

Quote:

Originally Posted by Codetapper

I don't think the copylock has even run at this stage so I don't believe that's the problem in this case. Maybe the crack has overwritten palette data or something.

This "bug" is definitely copy protection related. I checked with an image of the original disk that I converted from the IPF and the palette was wrong.
My guess is that they Copylock is used to decrypt/change the palette data.
Didn't have a closer look at it yet though.

Quote:

Originally Posted by MethodGit

Like I said, there is a major routine at $70000

And like I said at $70000 is the trackloader...

MethodGit · 30 July 2012, 13:31

In fact, if it makes things easier, I've zoned up a clean ADF of Disk 1. Taken directly from the archive at WHDownload. Ergo, no cracks, no dodgy data, nada. Like I said, it all seems to be down to the geometry of the disk.

Quote:

Originally Posted by StingRay

This "bug" is definitely copy protection related. I checked with an image of the original disk that I converted from the IPF and the palette was wrong.
My guess is that they Copylock is used to decrypt/change the palette data.
Didn't have a closer look at it yet though.

I looked closely and it appears the first $14E bytes of the copylock appear twice on the disk next to each other, at $B68B2 and $B6A00 respectively. This may or may not have to do with this issue (as said, part of a copylock gets loaded along with the correct colour values into $78600 on an original), but it can't be a case of modifying values-that-shouldn't-be-modified. If a copylock has been left well alone and the palette screws up anyway (several seconds before the game even gets round to loading the copylock) , how can it be linked to the copylock???

BTW, StingRay, if you use Toni's uaeunp tool to convert an IPF into an extended ADF, and then run said extended ADF, the correct pallete will load perfectly on that. So more proof if any was needed that it's related more to the type of disk than any copylock or copy-protection.

MethodGit · 30 July 2012, 15:16

Well, some good news..... I managed to create a near-perfect workaround for it!

What I basically did was find the (empty) palette section on the disk itself and insert the correct values (from the IPF memory dump) into there, then further down the disk NOP out the command (at $71A1E) that overwrites those values with the crap ones. I've almost managed to perfect it - there's just the issue of the little bar of garbage at the very bottom (which was also in the rainbowy version of the screen above if you looked carefully). I filled all the values in the palette and couldn't find anything else in the memdumps that I could use, so I'm a bit stuck on that one. Apart from that little niggle though, I feel I did a grand job!

The resultant ADF is in the Zone. Copylock still untouched btw since I'm trying to stress how so unconnected to the palette it is.

Mad-Matt · 30 July 2012, 15:38

Sometimes my Original used to make T2 screen Glitched/Red when played on anything other then my A600. It didnt seem to like Expanded A1200 (Cant remember if I played on Standard A1200). (Im thinking back 15 or so years

)

Galahad/FLT · 30 July 2012, 16:14

Just had a quick look at it, and it appears to be a track buffer location error, with an undisclosed bug in the RNC Sector loader.

1). Game boot code is loaded, and then relocates sector loader and bootcode at $70000
2). program code at $7098a is executed.
3). Game reads disk root table at address $800
4). Game then loads T2 picture and other code at $71a00

Problem is caused by trackbuffer set too low at $78000. Sector start is $57D, Sectors to read is $38. $38*$200= $7000 length of data to read.

Take your base address of $71a00 and add $7000 and you get $78a00.

The game is attempting to read data OVER the start of the trackbuffer data.

Because of a bug in the RNC sector loader, sometimes it just happens to decode correctly, mostly it doesn't.

So, simply setting the trackbuffer base address to $7a000 instead means it will boot up correctly every time.

Not a protection error or Copylock related, simply programmer stupidity, and we've seen that lots of times!

MethodGit · 30 July 2012, 17:28

Woop woop! Thanks for the helpful information there, Galahad.

Can confirm that by changing "80" to "A0" at offset $5C54 on the ADF, the problem dissipates completely. And there was me thinking it had something to do with the format of the disk (hence IPF and eADF always loading it properly, compared to ADF always loading it improperly).

It's pretty obvious you weren't the FLT bod who did the crack back then, as I'm pretty sure you'd have spotted this off the bat!

Toni Wilen · 30 July 2012, 17:37

Didn't really check what it actually does but I noticed it reads tracks in smaller pieces (at least it does different size disk dma reads), perhaps it works (accidentally) if "geometry" of tracks are exactly "right".

Gap position or size for example.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Black screen but game is still loading?	pekr	support.FS-UAE	9	04 February 2013 17:31
Move on screen display	Leandro Jardim	request.UAE Wishlist	0	13 November 2011 02:49
Screen goes black during loading with CF + WHDLoad	Rakki	support.Hardware	11	12 March 2009 18:39
C64 game, US flag loading screen	StarEye	Looking for a game name ?	15	21 June 2006 21:43
Problem with screen display.	KidCanary	support.WinUAE	3	02 December 2002 01:53

29 July 2012, 17:58	#1
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 39 Posts: 2,731	How to get T2: Arcade Game loading screen to display correctly? T2: The Arcade Game isn't really a difficult game to crack at all, but one thing that's always bothered me is this... I've seen this happen on ADFs of the first disk in general. The Fairlight crack (the only crack I know of) never attempted to fix it either. Curiously, this effect doesn't occur on eADFs, which leads me to worry that this is one of those games that decided to store some data on uncopyable parts of the original disk. Looking at the WHDLoad version doesn't help as it loads the game so quickly that the screen never pops up at all. I've tried consulting the code live while it's booting up but couldn't find anything to reverse the rainbowizing effect inside. Hopefully this doesn't require replacing well over $500 bytes of code or anything silly like that?

29 July 2012, 23:25	#2
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	The original IPF works fine so it must be a cracking/training mistake. If you check the original, the copperlist is at $7087a and the colour palette is at $708c6. The values are all normal. The cracked version has garbage at $708c6, with invalid colours like $aa67 and $2e29, so clearly something has overwritten the legitimate data. @MethodGit: I find it extremely strange that you could also crack the original and also have the corrupt palette problem unless you're modifying the exact bytes that FLT did (unlikely!). Are you sure you're not copying their crack rather than doing it yourself from scratch?

29 July 2012, 23:48	#3
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 39 Posts: 2,731	Perhaps I should've mentioned that the colour issue above happens on virgin/uncracked ADFs as well. So it has nothing to do with values being modified by cracks and the game picking those up. And I'm certainly not just recycling FLT's code btw...... I like to make my own cracks for games!

30 July 2012, 00:24	#4
Codetapper 2 contact me: email only! Join Date: May 2001 Location: Auckland / New Zealand Posts: 3,182	I loaded SPS 151 into an A500 config and it had perfect colours too. So I'm not sure what you mean by uncracked ADFs as if it's uncracked, it'll have the copylock in and if it's the original SPS, then it's not an ADF. Some games have the odd bug where a copperlist initialisation is done in the wrong order and maybe some configs that causes a problem. ie. Writing to copjmp1 before setting the copperlist pointer, but I don't think this is the case.

30 July 2012, 00:45	#5
dlfrsilver CaptainM68K-SPS France Join Date: Dec 2004 Location: Melun nearby Paris/France Age: 46 Posts: 10,412	smells just corruption here

30 July 2012, 00:48	#6
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 39 Posts: 2,731	Well I decided to check out the copperlist and palette at the addresses you mentioned to get a better picture. Somehow, it appears what values are written in them are determined by the disk format type it detects. On an IPF and an extended ADF, the correct values are written, but on a plain 880KB ADF, things go skewiff. Again, totally uncracked ADF (as in, just converted/imaged from an IPF, original copylock intact) tested. There is a particular routine executed at $70000 during loading that appears to decide the values that will go into the palette. Alas, it is a long piece that I can't make head nor tail of. All in all, it looks like it decides its numbers from the disk geometry.

30 July 2012, 13:23	#9
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 39 Posts: 2,731	Update: Well, I've been keeping an eye of $78874 and thereabouts since that's where the two bad colour values appear in the first place, and... In the original, it loads the correct values and a small part of the copylock(!) into that address, before disappearing again (copylock is loaded from a different address). Technical information coming up: Comparing the memory dumps of both an IPF and an ADF, data from $78600 starts to differ dramatically. The correct behaviour is to load $400 bytes of data from the offset $B6600 of the ADF, but for whatever reason this data is not being loaded/decoded correctly from a copy. Like I said, there is a major routine at $70000 - and a subroutine at $70658 - that determines what data gets loaded in the end. I'm still trying to look at it and understand it better as I speak. Also, for whatever reason, WinUAE's debugger doesn't seem to notice when the disk data from $78600 onwards suddenly changes into either the good or bad data, so I can't pinpoint precisely which command is giving birth to AA67 and 2E29. Oh, and CT? I cracked the copylock eons ago. Copylock has precisely jack all to do with the palette problem. As you already said, this happens before the copylock even comes into play.

30 July 2012, 15:16	#12
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 39 Posts: 2,731	Well, some good news..... I managed to create a near-perfect workaround for it! What I basically did was find the (empty) palette section on the disk itself and insert the correct values (from the IPF memory dump) into there, then further down the disk NOP out the command (at $71A1E) that overwrites those values with the crap ones. I've almost managed to perfect it - there's just the issue of the little bar of garbage at the very bottom (which was also in the rainbowy version of the screen above if you looked carefully). I filled all the values in the palette and couldn't find anything else in the memdumps that I could use, so I'm a bit stuck on that one. Apart from that little niggle though, I feel I did a grand job! The resultant ADF is in the Zone. Copylock still untouched btw since I'm trying to stress how so unconnected to the palette it is.

30 July 2012, 15:38	#13
Mad-Matt Longplayer Join Date: Jan 2005 Location: Lincoln / UK Age: 44 Posts: 1,846	Sometimes my Original used to make T2 screen Glitched/Red when played on anything other then my A600. It didnt seem to like Expanded A1200 (Cant remember if I played on Standard A1200). (Im thinking back 15 or so years )

30 July 2012, 16:14	#14
Galahad/FLT Going nowhere Join Date: Oct 2001 Location: United Kingdom Age: 50 Posts: 8,986	Just had a quick look at it, and it appears to be a track buffer location error, with an undisclosed bug in the RNC Sector loader. 1). Game boot code is loaded, and then relocates sector loader and bootcode at $70000 2). program code at $7098a is executed. 3). Game reads disk root table at address $800 4). Game then loads T2 picture and other code at $71a00 Problem is caused by trackbuffer set too low at $78000. Sector start is $57D, Sectors to read is $38. $38*$200= $7000 length of data to read. Take your base address of $71a00 and add $7000 and you get $78a00. The game is attempting to read data OVER the start of the trackbuffer data. Because of a bug in the RNC sector loader, sometimes it just happens to decode correctly, mostly it doesn't. So, simply setting the trackbuffer base address to $7a000 instead means it will boot up correctly every time. Not a protection error or Copylock related, simply programmer stupidity, and we've seen that lots of times!

30 July 2012, 17:28	#15
MethodGit Junior Member Join Date: Dec 2002 Location: The Streets Age: 39 Posts: 2,731	Woop woop! Thanks for the helpful information there, Galahad. Can confirm that by changing "80" to "A0" at offset $5C54 on the ADF, the problem dissipates completely. And there was me thinking it had something to do with the format of the disk (hence IPF and eADF always loading it properly, compared to ADF always loading it improperly). It's pretty obvious you weren't the FLT bod who did the crack back then, as I'm pretty sure you'd have spotted this off the bat!

30 July 2012, 17:37	#16
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Didn't really check what it actually does but I noticed it reads tracks in smaller pieces (at least it does different size disk dma reads), perhaps it works (accidentally) if "geometry" of tracks are exactly "right". Gap position or size for example.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)