English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 29 July 2012, 17:58   #1
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
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?
MethodGit is offline  
Old 29 July 2012, 23:25   #2
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,164
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?
Codetapper is offline  
Old 29 July 2012, 23:48   #3
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
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!
MethodGit is offline  
Old 30 July 2012, 00:24   #4
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,164
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.
Codetapper is offline  
Old 30 July 2012, 00:45   #5
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 43
Posts: 8,467
Send a message via MSN to dlfrsilver
smells just corruption here
dlfrsilver is offline  
Old 30 July 2012, 00:48   #6
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
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.
MethodGit is offline  
Old 30 July 2012, 11:55   #7
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,508
Quote:
Originally Posted by MethodGit View Post
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 View Post
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.
StingRay is offline  
Old 30 July 2012, 12:42   #8
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,164
Quote:
Originally Posted by StingRay View Post
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
Codetapper is offline  
Old 30 July 2012, 13:23   #9
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
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.
MethodGit is offline  
Old 30 July 2012, 13:29   #10
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,508
Quote:
Originally Posted by Codetapper View Post
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 View Post
Like I said, there is a major routine at $70000
And like I said at $70000 is the trackloader...
StingRay is offline  
Old 30 July 2012, 13:31   #11
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
Posts: 2,731
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 View Post
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.

Last edited by prowler; 30 July 2012 at 16:29. Reason: Back-to-back posts merged.
MethodGit is offline  
Old 30 July 2012, 15:16   #12
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
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.
MethodGit is offline  
Old 30 July 2012, 15:38   #13
Mad-Matt
Longplayer

Mad-Matt's Avatar
 
Join Date: Jan 2005
Location: Lincoln / UK
Age: 41
Posts: 1,641
Send a message via ICQ to Mad-Matt Send a message via MSN to Mad-Matt
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 )
Mad-Matt is offline  
Old 30 July 2012, 16:14   #14
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,644
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!
Galahad/FLT is offline  
Old 30 July 2012, 17:28   #15
MethodGit
Junior Member
MethodGit's Avatar
 
Join Date: Dec 2002
Location: The Streets
Age: 36
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!
MethodGit is offline  
Old 30 July 2012, 17:37   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,967
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.
Toni Wilen is offline  
 


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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.09129 seconds with 13 queries