Who's Online |
44 user(s) are online ( 27 user(s) are browsing Forums)
Members: 0
Guests: 44
more...
|
|
|
|
Exodus The Last War patching : v0.1 patch on os4depot
|
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@All Another game that I want to deal with, called Exodus The Last War. That is about the same kind of RTS as Napalm, and almost on the same level. RTG, AHI, 68k, music/sounds/cd-audio and co.  It has some issues (like always freezing preference program on exit), DSI in a game itself a few places, DSI on exit from the game, non-stop-able CD-Audio on exit, and all that sort of minor things which nice to deal with. So, I start, of course, with the latest CD release (i took it for 5 EUR now in downloadable form from amiga future, it comes with .cue and all cd-audio tracks working via our diskimage.device/cdplayer.library/cddpatch), and study/apply all necessary/latest patches. At the moment I already have worked and reassembled two binaries of a game: the main binary, and setup program binary. I reassembled them from disassembled code, and they work now just like originals, so patching/fixing/making_new_bugs is possible. But before, we need to sort one thing out: On Radeon RX and Radeon HD drivers (be it x5000 or sam460 used) that game does not have correct rendering in 640x480xCLUT but has correct rendering on Pegaos2 with old Radeon9250, and on WinUAE with os3.9 and E-UAE with OS3.2. Hope some of you will help me to understand wtf and where and how we can deal with it in a fast manner. So. If we run a game in 640x480x8 bit (CLUT) (the mode for which that game was designed to work on GFX cards) on X5000 or on SAM460 (i.e. anywhere where we use RadeonHD or Radeon RX), instead of a clean picture we have that: All images are clickable for full-size!Intro:  Menu:  Now if we run on Pegasos2 with Radeon9250(!), or on WinUAE with OS3, or on E-UAE with OS3.2, then we have that: Intro:  Menu:  I point out that Pegasos2 with OS4 and the same up2date OS4 with all the latest stuff as on X5000 and Sam460 is all fine too. The only exception that this is RadeonRX+RadeonHD cards/drivers versus old Radeon9250 card/drivers. For sake of fun I run 800x600 and 1024x768 modes on all the machines, and it has everywhere the same kind of trash as we have in 640x480 but on RadeonRx/RadeonHD, see: 800x600 pegasos2/winuae/euae:  1024x768 pegasos2/winuae/euae:  So far, that is what it means: 1). working resolution of game only 640x480x8. Ok. 2). by some reason it didn't work well on Radeon RX/RadeonHD, but works on older Radeon, and WinUae, and our e-UAE. It also works not only on Pegasos , but also on A1/Sams where older Radeons can be/still used 3). I checked via Ranger params of Screen and Window after creation, and on Radeon RX/RadeonHD and on Radeon9250, everything the same: Screen: Quote: Type: Custom Box: Left: 0 Top: 0 Width: 640 Height: 480 Depth: 8 Pixel Format: CLUT Flags: ShowTitle Behind HIRes Compositing: Disabled Drop Shadow: Disabled User Data: 0x00000000
Window on top of that screen: Quote: Box: Left: 0 Top: 0 Width: 640 Height: 480 Shape: Regison : 0x00000000 Hook: 0x00000000 Alpha: ClipRect: 0x000000 Hook: 0x000000 Opaqueness: 255 Override: False Fade Time: 0 (ms) No Hit Threshold: 16 Drop Shadows: -1 User Data 0x00000000
4). I do compare all the images, and we do "miss" on RadeonHD/Radeon RX exactly 80 lines at the bottom (anyone can recheck it from the screenshots above). 5). created screen/window is indeed 640x480 everywhere. On RadeonRX/RadeonHD I can move via mouse cursor in all areas of the screen (also over that "black" area too). It's just rendering on Radeon RX/HD happens to be smaller on 80 lines and not in full 480 lines, but just 400 instead. Now the main question: WTF. If it works on pegasos2 then it is not the game's code probably, right? Seeing the same kind of "garbage" when we use bigger modes on "working" hardware, point out that something is wrong exactly with our 640x480 mode. But what? Is it the game's bug, or driver's bug? From where we can start to deal with it? Thanks a bunch to anyone who digs in !:)
Edited by kas1e on 2022/1/11 21:58:58 Edited by kas1e on 2022/1/19 8:01:08
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e
I guess the game expects a width to be what it had allocated, not what it got. While in AmigaOS4.1 it was introduced actual width, that includes padded width sizes.
Edited by LiveForIt on 2022/1/11 22:33:27
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@LiveForIt On pegasos/sam/a1 with Radeon9250 and latest os4 rendering fine. If it's the game's issue why it didn't happen on Radeon9250 then?
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e
different drivers, maybe.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@All I got a mail from Hans, he says that it looks like the game isn't using the right bytes-per-row.
Radeon 9xxx cards have images padded to a multiple of 128 while RadeonHD/RX-ATI/AMD cards padded that out to a multiple of 256.
Assuming that Exodus uses 8-bit bitmaps:
640/128 = 5, so Radeon 9000 cards can handle 640 wide bitmaps with no padding
640/256 = 2.5, so Radeon HD and newer cards pad 640 out to 768
So, 640*480 = 307.200 And 768*400 = 307.200
But as we have with no padding 768, then game fill 768x400 => mess on screen and 80 lines missed.
So it looks like the game fails to read the actual bitmap width and adapt to it (or mean don't do it at all, and only read heigh and hope for a no-padding-all-works-fine)
Now, the question: how we can deal with that.
I already got binary reassembled, so I can in any place put calling to my own functions written on C, bypass any code in original assembler parts, and return back when need it with taking all necessary pointers/data/etc from C to ASM and from ASM to C.
So what do we need to do next? Is there maybe some easy way so we can deal with less blood (like, changing some TAGS somewhere, or find out where data is allocated and replace some FLAG in which will force making padding to necessary limits?)
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e
As this game works width out hardware blitter, there has to be copy loop somewhere. 16bit alignment for bitmaps is common, so I'm guessing.
Move.w (a0)+,(a1)+
or it can be 32bit copy routine, less likely.
Move.l (a0)+,(a1)+
or something like that.
it can be just loaded in and trys to display it
Maybe add lots of print’s and see what part is executed, and narrow it down.
Graphic library WritePixelArray function is maybe not available for Assembler or 68k programs, (as that included later), maybe game is using cybergraphics or picasso96 then there is a WritePixelArray function that the game should have used.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@LiveForIt Yes, a game uses both graphics.library and cybergraphics.library. If you can help with anything, that will be cool! I upload disassembled stuff for both: main binary and preference binary there: http://kas1e.mikendezign.com/aos4/68k ... xodus/exodus_disas_01.lhaThe one which we need to look at for now is ExodusTLW_V21.asm. The game is from 2000-2001, so cyber graphics were used for sure as well (and in the readme for game and patches they say that CyberGraphics need it) Anyway ... I do patch graphics and cybergraphics libraries, so when a call to any of their function happens, it will warn me. And as result, there is _NO_ any WritePixelArray, or any kind of "Write" call is used. At first, i think that something goes wrong with my patching of libs, but no, i can see clearly when for example "fadein/fadeout" effects happen, there are loads of LoadRGB32/WaitTOF calls (fade in / out effects of "palette" images back in times done exactly via LoadRGB32). I also do check some of my stuff written for old days which use WPA (more precise WritePixelArray8) - and when i trace this one, calls are found. So it is safe to say that patching of libs works, just game for real doesn't use any kind of WPA. I also can see that from CGX, only 2 functions are used: LockBitMapTagList() and UnLockBitMap(). There is full trace once first image loaded and i click on it, so it start "fade out" to show me menu screen, then i wait a bit and hit close (so also fade out and exit): http://kas1e.mikendezign.com/aos4/68k ... ics_and_cybergraphics.txtSo, before image are "fade in" on screen, that what we have by graphics/cybergraphics functions calls (see for "gfx:" and "cgx:" marks at the begining): Quote: gfx : WaitTOF cgx : LockBitMapTagList cgx : UnLockBitMap gfx : WaitBOVP gfx : GetVPModeID gfx : FindDisplayInfo gfx : GetDisplayInfoData gfx : FindDisplayInfo gfx : GetDisplayInfoData gfx : CalcIVG gfx : GetVPModeID gfx : FindDisplayInfo gfx : GetDisplayInfoData gfx : FindDisplayInfo gfx : GetDisplayInfoData gfx : CalcIVG gfx : GfxLookUp gfx : FreeCprList gfx : FreeCprList gfx : GfxLookUp gfx : GetBitMapAttr gfx : GetBitMapAttr gfx : GetBitMapAttr gfx : GetBitMapAttr gfx : MrgCop gfx : GfxLookUp gfx : GfxLookUp gfx : LoadView gfx : VideoControl gfx : VideoControl gfx : MoveSprite gfx : ChangeExtSpriteA gfx : MoveSprite gfx : WaitTOF gfx : FreeCprList gfx : FreeCprList gfx : LoadRGB32 cgx : LockBitMapTagList cgx : UnLockBitMap gfx : WaitBOVP cgx : LockBitMapTagList cgx : UnLockBitMap .....
I think that game may work this way: As there are no AllocBitMap or so calls, they just do load data to the memory and allocate just by exec's AllocVec() or even malloc(). They lock it as bitmap by Cgx's LockBitMapTagList and then work further with it. And whole copy routines seems not WPA based of any form, but instead, they use their own (probably because back in the times WPA was considered as very slow, and people often made replacements for it) Now... We need to find out where the copy routine in the disassembled code happens. I may try to find out where LoadRGB32() call happens, maybe somewhere near of that function copy ones will be .. dunno. Quote: As this game works width out hardware blitter, there has to be copy loop somewhere. 16bit alignment for bitmaps is common, so I'm guessing.
Move.w (a0)+,(a1)+
or it can be 32bit copy routine, less likely.
Move.l (a0)+,(a1)+
In the whole source there are 7 places where "MOVE.L (A0)+,(A1)+" are used and in 3 functions they are used in a row 4 times one after another. There is also 10 times "MOVE.B (A0)+,(A1)+" per one time in a function As for "Move.w (a0)+,(a1)+" there none.
Edited by kas1e on 2022/1/12 22:51:22 Edited by kas1e on 2022/1/13 5:53:06 Edited by kas1e on 2022/1/13 8:40:56 Edited by kas1e on 2022/1/13 8:42:04 Edited by kas1e on 2022/1/13 8:42:46
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@All As i understand from autodocs, all the drawings should happen between LockBitMapTagList (-168) and UnLockBitMap (-174). So finding blocks between jsr -168(a6) and jsr(-174) probably can point out something? I find out 3 places in binary, there they are: 1.
LAB_01A7:
MOVEM.L D1/A0-A1/A6,-(A7) ;05280: 48e740c2
MOVEA.L #LAB_000C+2,A0 ;05284: 207c0000015a
MOVEA.L 16(A0),A6 ;0528a: 2c680010
MOVEA.L LAB_0BC2,A0 ;0528e: 20790001f8d4
LEA LAB_01AB(PC),A1 ;05294: 43fa0040
JSR -168(A6) ;05298: 4eaeff58
MOVE.L D0,LAB_01AD ;0529c: 23c0000052ea
BEQ.W LAB_01A8 ;052a2: 67000008
MOVE.L LAB_01AC,D0 ;052a6: 2039000052e2
LAB_01A8:
MOVEM.L (A7)+,D1/A0-A1/A6 ;052ac: 4cdf4302
RTS ;052b0: 4e75
LAB_01A9:
MOVEM.L D1/A0-A1/A6,-(A7) ;052b2: 48e740c2
MOVE.L LAB_01AD,D0 ;052b6: 2039000052ea
BEQ.W LAB_01AA ;052bc: 67000012
MOVEA.L #LAB_000C+2,A0 ;052c0: 207c0000015a
MOVEA.L 16(A0),A6 ;052c6: 2c680010
MOVEA.L D0,A0 ;052ca: 2040
JSR -174(A6) ;052cc: 4eaeff52
LAB_01AA:
MOVEM.L (A7)+,D1/A0-A1/A6 ;052d0: 4cdf4302
RTS
2.
LAB_0DCE:
MOVEA.L D0,A3 ;2692a: 2640
LEA 6(A3),A1 ;2692c: 43eb0006
MOVE.W 4(A3),D0 ;26930: 302b0004
AND.L #$0000000f,D0 ;26934: c0bc0000000f
JSR -168(A6) ;2693a: 4eaeff58
MOVE.L (A3),D0 ;2693e: 2013
BNE.W LAB_0DCE ;26940: 6600ffe8
LAB_0DCF:
DBF D2,LAB_0DCD ;26944: 51caffde
RTS ;26948: 4e75
LAB_0DD0:
MOVEA.L ABSEXECBASE,A6 ;2694a: 2c7900000004
MOVEQ #15,D2 ;26950: 740f
LAB_0DD1:
MOVE.L (A2)+,D0 ;26952: 201a
BEQ.W LAB_0DD3 ;26954: 6700001c
LAB_0DD2:
MOVEA.L D0,A3 ;26958: 2640
LEA 6(A3),A1 ;2695a: 43eb0006
MOVE.W 4(A3),D0 ;2695e: 302b0004
AND.L #$0000000f,D0 ;26962: c0bc0000000f
JSR -174(A6) ;26968: 4eaeff52
MOVE.L (A3),D0 ;2696c: 2013
BNE.W LAB_0DD2 ;2696e: 6600ffe8
LAB_0DD3:
DBF D2,LAB_0DD1 ;26972: 51caffde
RTS ;26976: 4e75
MOVEA.L LAB_0DBD+2(PC),A5 ;26978: 2a7afe88
RTS ;2697c: 4e75
RTS
3.
JSR -168(A6) ;26a02: 4eaeff58
LAB_0DD6:
MOVEM.L (A7)+,D2/A0-A1/A6 ;26a06: 4cdf4304
RTS ;26a0a: 4e75
LAB_0DD7:
MOVE.L #LAB_0DC0+2,LAB_0DC1+2 ;26a0c: 23fc0002684600026886
TST.W LAB_0DC2+2 ;26a16: 4a790002688a
SEQ LAB_0DBD ;26a1c: 57f900026800
BRA.W LAB_0DD8 ;26a22: 60000018
DC.W $a001 ;26a26
DC.L LAB_0DD7 ;26a28: 00026a0c
MOVE.L #LAB_0DBF+2,LAB_0DC1+2 ;26a2c: 23fc0002680600026886
CLR.W LAB_0DBD ;26a36: 427900026800
LAB_0DD8:
MOVEM.L D1-D2/A0-A3/A6,-(A7) ;26a3c: 48e760f2
MOVE.W D0,D2 ;26a40: 3400
AND.W #$000f,D0 ;26a42: c07c000f
LSL.W #2,D0 ;26a46: e548
MOVEA.L LAB_0DC1+2(PC),A2 ;26a48: 247afe3c
LEA 0(A2,D0.W),A3 ;26a4c: 47f20000
LAB_0DD9:
MOVE.L (A3),D1 ;26a50: 2213
BEQ.W LAB_0DDC ;26a52: 67000042
MOVEA.L D1,A2 ;26a56: 2441
CMP.W 4(A2),D2 ;26a58: b46a0004
BEQ.W LAB_0DDA ;26a5c: 67000008
MOVEA.L A2,A3 ;26a60: 264a
BRA.W LAB_0DD9 ;26a62: 6000ffec
LAB_0DDA:
TST.W LAB_0DBD ;26a66: 4a7900026800
BNE.W LAB_0DDB ;26a6c: 66000018
LEA 6(A2),A1 ;26a70: 43ea0006
MOVE.W D2,D0 ;26a74: 3002
AND.L #$0000000f,D0 ;26a76: c0bc0000000f
MOVEA.L ABSEXECBASE,A6 ;26a7c: 2c7900000004
JSR -174(A6) ;26a82: 4eaeff52
LAB_0DDB:
Is anyone see what one can be our copy routine related? Or just all of them?:)
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@All Ok so, progress! Daniel a little bit help me with understanding, and the snipped we need are the first one: LockBitMapTagList() there just with a null-pointer check and then UnLockBitMap(). There we can see that after LockBitMapTagList() we do "move.l d0,lab_01ad", which mean we store our pointer to bitmap (lab_01ad are just 0x00000000, so probably place for storing pointer). Then, before calling UnLockBitMap() we again move that pointer to D0/A0 meaning that this seems indeed a pointer to bitmap. Now, i do check from where we call LockBitMapTagList(), and they're are just in 2 places, and the first one :
LAB_019E:
JSR LAB_0A39 ;051a4: 4eb900018b22
MOVEA.L LAB_0BC9,A0 ;051aa: 20790001f8f8
MOVE.W LAB_0BBE+2,D5 ;051b0: 3a390001f8c2
BSR.W LAB_01A7 ;051b6: 610000c8
TST.L D0 ;051ba: 4a80
BEQ.W LAB_01A0 ;051bc: 67000028
MOVEA.L D0,A1 ;051c0: 2240
MULU LAB_0BBE,D5 ;051c2: caf90001f8c0
LSR.L #4,D5 ;051c8: e88d
SUBQ.L #1,D5 ;051ca: 5385
LAB_019F:
MOVE.L (A0)+,(A1)+ ;051cc: 22d8
MOVE.L (A0)+,(A1)+ ;051ce: 22d8
MOVE.L (A0)+,(A1)+ ;051d0: 22d8
MOVE.L (A0)+,(A1)+ ;051d2: 22d8
DBF D5,LAB_019F ;051d4: 51cdfff6
BSR.W LAB_01A9 ;051d8: 610000d8
JSR LAB_0A43 ;051dc: 4eb900018c56
BRA.W LAB_01A0 ;051e2: 60000002
LAB_01A0:
RTS
See "BSR.W LAB_01A7" its our call to LockBitMapTagsLIst. But then after you can see 4 "MOVE.L (A0)+,(A1)+". And i just tried to comment them out one by one, and, seems that it! Each call is handle 25% of the data which draws on the screen. That means, we now know probably where the actual copy to screen happens. Now, how we can fix the no-padding issues, so it will work on Radeon RX/HD? As the game uses hardcore 640x480, we don't need any "good" code which will cover anything else, just we need to shift data in some hardcore way so it will work as expected. Any ideas and what to check next are welcome!
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 16:19
#10
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e This is pretty crappy unrolled 1d copy loop. they chouse speed, instead of doing it the correct why. look like it takes one argument D0, and its the destination address. // void LAB_019E(reg D0);
LAB_019E:
JSR LAB_0A39 ;051a4: 4eb900018b22
MOVEA.L LAB_0BC9,A0 ;051aa: 20790001f8f8
MOVE.W LAB_0BBE+2,D5 ; D5 = bitmap->Rows
BSR.W LAB_01A7 ;051b6: 610000c8
TST.L D0 ;
BEQ.W LAB_01A0 ; if (D0==0) return;
MOVEA.L D0,A1 ; A1=D0;
MULU LAB_0BBE,D5 ; D5 *= bitmap-> BytesPerRow // Number of bytes in a image.
LSR.L #4,D5 ; D5 /= 16; // etch loop takes 16 bytes, its unrolled loop.
SUBQ.L #1,D5 ; you need this for DBF
LAB_019F: ; do {
MOVE.L (A0)+,(A1)+ ; copy 4 bytes of 16 bytes
MOVE.L (A0)+,(A1)+ ; copy 4 bytes of 16 bytes
MOVE.L (A0)+,(A1)+ ; copy 4 bytes of 16 bytes
MOVE.L (A0)+,(A1)+ ; copy 4 bytes of 16 bytes
DBF D5,LAB_019F ; } while(D5--);
BSR.W LAB_01A9 ;051d8: 610000d8
JSR LAB_0A43 ;051dc: 4eb900018c56
BRA.W LAB_01A0 ;051e2: 60000002
LAB_01A0:
RTS
is LAB_0BBE the source bitmap size or the dest bitmap size? we need the dest bitmap size to do this correct.
Edited by LiveForIt on 2022/1/13 21:04:31
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 17:43
#11
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e maybe some thing like this?
LAB_019E:
JSR LAB_0A39 ;051a4: 4eb900018b22
MOVEA.L LAB_0BC9,A0 ;051aa: 20790001f8f8
MOVE.W LAB_0BBE+2,D5 ; D5 = bitmap->Rows
BSR.W LAB_01A7 ;051b6: 610000c8
TST.L D0 ;
BEQ.W LAB_01A0 ; if (D0==0) return;
SUBQ.L #1,D5 ; you need this for DBF
.row_loop
MOVEA.L D0,A1 ; A1=D0;
MOVE.W LAB_0BBE,D4
LSR.L #2,D4 ; D5 /= 4; // 32bit...
SUBQ.L #1,D4 ; you need this for DBF
.col_loop
MOVE.L (A0)+,(A1)+ ; copy 4 bytes (32bit)
DBF D4,.col_loop
ADD.L destBytesPerRow,D0
DBF D5,.row_loop
BSR.W LAB_01A9 ;051d8: 610000d8
JSR LAB_0A43 ;051dc: 4eb900018c56
BRA.W LAB_01A0 ;051e2: 60000002
LAB_01A0:
RTS
need to find destBytesPerRow some how, just test, type some value there. #82 maybe D4 needs to be put on stack... (to restore it, or maybe we can use different register)
Edited by LiveForIt on 2022/1/13 18:00:14 Edited by LiveForIt on 2022/1/13 18:33:34 Edited by LiveForIt on 2022/1/13 18:50:24 Edited by LiveForIt on 2022/1/13 18:52:24 Edited by LiveForIt on 2022/1/13 19:41:07 Edited by LiveForIt on 2022/1/13 19:41:50
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 20:31
#12
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
Edited by kas1e on 2022/1/13 20:48:29 Edited by kas1e on 2022/1/13 21:08:17
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 21:21
#13
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e
I was thinking planar, but its chunkt so try 642 or maybe 768.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 21:37
#14
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@LiveForIT Thanks for the help, we deal with already (Daniel helped as well), check the working one:
LAB_019E:
JSR LAB_0A39
MOVEA.L LAB_0BC9,A0
MOVE.W LAB_0BBE+2,D5
BSR.W LAB_01A7
TST.L D0
BEQ.W LAB_01A0
MOVEA.L D0,A1
move.w d7,-(sp) ; I need another register, dunno if d7 is free, I'll store it on the stack
move.w #(480-1),D7 ; 480 rows
LAB_OUTER:
moveq #((640/4/4)-1),d5 ; we need 40*4 LONG-writes for one line, unrolled to 40 loops of 4 writes
LAB_019F:
MOVE.L (A0)+,(A1)+
MOVE.L (A0)+,(A1)+
MOVE.L (A0)+,(A1)+
MOVE.L (A0)+,(A1)+
DBF D5,LAB_019F
; here one line is done, now add our row padding
adda.w #128,A1
; next line
DBF D7, LAB_OUTER
; restore D7 from stack
move.w (sp)+,d7
BSR.W LAB_01A9 ;051d8: 610000d8
JSR LAB_0A43 ;051dc: 4eb900018c56
BRA.W LAB_01A0 ;051e2: 60000002
LAB_01A0:
RTS
But thanks for your time and help anyway too, without you i didn't think about those cybergraphics functions which lead us to find where actual copy blocks are :)
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 21:48
#15
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e
np.
If I remember correct there some issue with cdda or issue with installing it, as well.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 22:01
#16
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@All https://youtu.be/cc8Gl24u7-4Now, we need to deal with skippable DSI in the menu. As it is skippable, I hope it will be not _that_ hard as this padding crap. That is what it gives to crash log: http://kas1e.mikendezign.com/aos4/68k ... s_2022-01-13_21-58-53.txtAs I see "DAR" is 0x00000000 are null, so that is a null-pointer crash. (If course, having 0x00000000 in the DAR from Petunia mean the same as we have when crashing on native PPC binaries.) Now as we have disassembled in the crash log, i find out the place of the code where it crashes. There are:
LAB_06F7:
MOVEA.L #LAB_0BBE,A0 ;10222: 207c0001f8c0
MOVEA.L 16(A0),A0 ;10228: 20680010
MOVE.W 18(A0),D2 ;1022c: 34280012
MOVE.W 16(A0),D3 ;10230: 36280010
RTS ;10234: 4e75
LAB_06F8:
MOVEQ #1,D2 ;10236: 7401
The crash happens on RTS. I am not an expert so do not know why it may crash on RTS exactly (when it is just about to return to another function). Trashed stack ?
Edited by kas1e on 2022/1/13 22:20:59
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 22:52
#17
|
Home away from home 
Joined: 2006/11/20 16:26 Last Login
: Yesterday 21:37
From Norway
Group:
Registered Users
|
@kas1e
I don’t believe it crashes on RTS. Patina JIT compiler lies about where it crashed, add the exe file to compatibility prefs, and disable JIT.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/13 23:08
#18
|
Home away from home 
Joined: 2007/9/11 12:31 Last Login
: 6/22 18:37
From Russia
Group:
Registered Users
|
@LiveForIt Yeah, now crashes differently. New crash log with disabled JIT: http://kas1e.mikendezign.com/aos4/68k ... DSI_menu_disabled_jit.txtNow while it still the same null-pointer crash, it point out on different disassembly:
68k disassembly:
61b99b6c: 246b000e movea.l 0xe(a3),a2
61b99b70: 67000078 beq.w 0x61b99bea
*61b99b74: 4a12 tst.b (a2)
61b99b76: 67000072 beq.w 0x61b99bea
61b99b7a: 4280 clr.l d0
Which is:
LAB_0755:
MOVEQ #0,D6 ;10b54: 7c00
JSR LAB_0759 ;10b56: 4eb900010bea
MOVEA.L 14(A3),A2 ;10b5c: 246b000e
BEQ.W LAB_0758 ;10b60: 67000078
TST.B (A2) ;10b64: 4a12 <= CRASH
BEQ.W LAB_0758 ;10b66: 67000072
CLR.L D0 ;10b6a: 4280
TST.B 27(A3) ;10b6c: 4a2b001b
BEQ.W LAB_0756 ;10b70: 67000008
MOVE.B 26(A3),D0 ;10b74: 102b001a
LSL.W #2,D0 ;10b78: e548
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
|
Just can't stay away 
Joined: 2006/11/30 11:30 Last Login
: Yesterday 18:12
From Finland
Group:
Registered Users
|
@kas1e Quote: MOVEA.L 14(A3),A2 BEQ.W LAB_0758 TST.B (A2) BEQ.W LAB_0758
It looks like maybe the first two instructions were meant to be a NULL pointer check but the programmer did not take into account that moves with an address register as destination do not set condition flags. On 68020+ I think you can do: MOVEA.L 14(A3),A2 TST.L A2 BEQ.W LAB_0758 But on 68000 CPU you will have to find a free data register and do something like: MOVE.L 14(A3),D0 MOVEA.L D0,A2 BEQ.W LAB_0758
|
|
|
|
Re: Exodus The Last War patching : work in progress
|
Posted on: 1/14 11:28
#20
|
Not too shy to talk 
Joined: 2015/6/11 9:51 Last Login
: 5/3 9:30
From Cologne
Group:
Registered Users
|
@salass00 Quote: you will have to find a free data register No, Motorola gave us EXG ;) Quote: but the programmer did not take into account that moves with an address register as destination do not set condition flags We can't be sure about that without digging deeper. Maybe he did it on purpose and the BEQ tests the condition before the movea and he wanted to happen the move in any case. Maybe he just forgot the nullptr check. @kas1e That's why this here would be an unintrusive way to add a nullptr check:
MOVEA.L 14(A3),A2 ;10b5c: 246b000e
BEQ.W LAB_0758 ;10b60: 67000078
; just insert this
EXG D0,A2
TST.L D0
EXG D0,A2
BEQ.W LAB_0758
You can comment in / out the first BEQ.W. If the behaviour doesn't change for sure then salass00's asumption that the coder falsely asumed that movea changes cc is likely to be correct.
|
|
|
Currently Active Users Viewing This Thread:
1
(
0 members
and 1 Anonymous Users
)
|
|
|