Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
40 user(s) are online (29 user(s) are browsing Forums)

Members: 0
Guests: 40

more...

Headlines




(1) 2 »


Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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.

Resized Image

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:

Resized Image


Menu:

Resized Image


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:

Resized Image


Menu:

Resized Image


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:

Resized Image



1024x768 pegasos2/winuae/euae:

Resized Image


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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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?

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@kas1e

different drivers, maybe.

_________________
(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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?)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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.lha

The 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.txt

So, 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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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)    ;0528048e740c2
    MOVEA
.L    #LAB_000C+2,A0        ;05284: 207c0000015a
    
MOVEA.L    16(A0),A6        ;0528a2c680010
    MOVEA
.L    LAB_0BC2,A0        ;0528e20790001f8d4
    LEA    LAB_01AB
(PC),A1        ;0529443fa0040
    JSR    
-168(A6)        ;052984eaeff58
    MOVE
.L    D0,LAB_01AD        ;0529c23c0000052ea
    BEQ
.W    LAB_01A8        ;052a267000008
    MOVE
.L    LAB_01AC,D0        ;052a62039000052e2
LAB_01A8
:
    
MOVEM.L    (A7)+,D1/A0-A1/A6    ;052ac4cdf4302
    RTS                
;052b04e75
LAB_01A9
:
    
MOVEM.L    D1/A0-A1/A6,-(A7)    ;052b248e740c2
    MOVE
.L    LAB_01AD,D0        ;052b62039000052ea
    BEQ
.W    LAB_01AA        ;052bc67000012
    MOVEA
.L    #LAB_000C+2,A0        ;052c0: 207c0000015a
    
MOVEA.L    16(A0),A6        ;052c62c680010
    MOVEA
.L    D0,A0            ;052ca2040
    JSR    
-174(A6)        ;052cc4eaeff52
LAB_01AA
:
    
MOVEM.L    (A7)+,D1/A0-A1/A6    ;052d04cdf4302
    RTS



2.
LAB_0DCE:
    
MOVEA.L    D0,A3            ;2692a2640
    LEA    6
(A3),A1        ;2692c43eb0006
    MOVE
.W    4(A3),D0        ;26930302b0004
    
AND.L    #$0000000f,D0        ;26934: c0bc0000000f
    
JSR    -168(A6)        ;2693a4eaeff58
    MOVE
.L    (A3),D0            ;2693e2013
    BNE
.W    LAB_0DCE        ;269406600ffe8
LAB_0DCF
:
    
DBF    D2,LAB_0DCD        ;2694451caffde
    RTS                
;269484e75
LAB_0DD0
:
    
MOVEA.L    ABSEXECBASE,A6        ;2694a2c7900000004
    MOVEQ    
#15,D2            ;26950: 740f
LAB_0DD1:
    
MOVE.L    (A2)+,D0        ;26952201a
    BEQ
.W    LAB_0DD3        ;269546700001c
LAB_0DD2
:
    
MOVEA.L    D0,A3            ;269582640
    LEA    6
(A3),A1        ;2695a43eb0006
    MOVE
.W    4(A3),D0        ;2695e302b0004
    
AND.L    #$0000000f,D0        ;26962: c0bc0000000f
    
JSR    -174(A6)        ;269684eaeff52
    MOVE
.L    (A3),D0            ;2696c2013
    BNE
.W    LAB_0DD2        ;2696e6600ffe8
LAB_0DD3
:
    
DBF    D2,LAB_0DD1        ;2697251caffde
    RTS                
;269764e75
    MOVEA
.L    LAB_0DBD+2(PC),A5    ;269782a7afe88
    RTS                
;2697c4e75
    RTS



3.

JSR    -168(A6)        ;26a024eaeff58
LAB_0DD6
:
    
MOVEM.L    (A7)+,D2/A0-A1/A6    ;26a064cdf4304
    RTS                
;26a0a4e75
LAB_0DD7
:
    
MOVE.L    #LAB_0DC0+2,LAB_0DC1+2    ;26a0c: 23fc0002684600026886
    
TST.W    LAB_0DC2+2        ;26a164a790002688a
    SEQ    LAB_0DBD        
;26a1c57f900026800
    BRA
.W    LAB_0DD8        ;26a2260000018
    DC
.W    $a001            ;26a26
    DC
.L    LAB_0DD7        ;26a2800026a0c
    MOVE
.L    #LAB_0DBF+2,LAB_0DC1+2    ;26a2c: 23fc0002680600026886
    
CLR.W    LAB_0DBD        ;26a36427900026800
LAB_0DD8
:
    
MOVEM.L    D1-D2/A0-A3/A6,-(A7)    ;26a3c48e760f2
    MOVE
.W    D0,D2            ;26a403400
    
AND.W    #$000f,D0        ;26a42: c07c000f
    
LSL.W    #2,D0            ;26a46: e548
    
MOVEA.L    LAB_0DC1+2(PC),A2    ;26a48247afe3c
    LEA    0
(A2,D0.W),A3        ;26a4c47f20000
LAB_0DD9
:
    
MOVE.L    (A3),D1            ;26a502213
    BEQ
.W    LAB_0DDC        ;26a5267000042
    MOVEA
.L    D1,A2            ;26a562441
    CMP
.W    4(A2),D2        ;26a58b46a0004
    BEQ
.W    LAB_0DDA        ;26a5c67000008
    MOVEA
.L    A2,A3            ;26a60264a
    BRA
.W    LAB_0DD9        ;26a626000ffec
LAB_0DDA
:
    
TST.W    LAB_0DBD        ;26a664a7900026800
    BNE
.W    LAB_0DDB        ;26a6c66000018
    LEA    6
(A2),A1        ;26a7043ea0006
    MOVE
.W    D2,D0            ;26a743002
    
AND.L    #$0000000f,D0        ;26a76: c0bc0000000f
    
MOVEA.L    ABSEXECBASE,A6        ;26a7c2c7900000004
    JSR    
-174(A6)        ;26a824eaeff52
LAB_0DDB
:


Is anyone see what one can be our copy routine related? Or just all of them?:)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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        ;051a44eb900018b22
    MOVEA
.L    LAB_0BC9,A0        ;051aa20790001f8f8
    MOVE
.W    LAB_0BBE+2,D5        ;051b03a390001f8c2
    BSR
.W    LAB_01A7        ;051b6610000c8
    TST
.L    D0            ;051ba4a80
    BEQ
.W    LAB_01A0        ;051bc67000028
    MOVEA
.L    D0,A1            ;051c02240
    MULU    LAB_0BBE
,D5        ;051c2caf90001f8c0
    LSR
.L    #4,D5            ;051c8: e88d
    
SUBQ.L    #1,D5            ;051ca: 5385
LAB_019F:
    
MOVE.L    (A0)+,(A1)+        ;051cc22d8
    MOVE
.L    (A0)+,(A1)+        ;051ce22d8
    MOVE
.L    (A0)+,(A1)+        ;051d022d8
    MOVE
.L    (A0)+,(A1)+        ;051d222d8
    DBF    D5
,LAB_019F        ;051d451cdfff6
    BSR
.W    LAB_01A9        ;051d8610000d8
    JSR    LAB_0A43        
;051dc4eb900018c56
    BRA
.W    LAB_01A0        ;051e260000002
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!


_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@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        ;051a44eb900018b22
    MOVEA
.L    LAB_0BC9,A0        ;051aa20790001f8f8
    MOVE
.W    LAB_0BBE+2,D5        D5 bitmap->Rows
    BSR
.W    LAB_01A7        ;051b6610000c8
    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        ;051d8610000d8
    JSR    LAB_0A43        
;051dc4eb900018c56
    BRA
.W    LAB_01A0        ;051e260000002
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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@kas1e

maybe some thing like this?

LAB_019E:
    
JSR    LAB_0A39        ;051a44eb900018b22
    MOVEA
.L    LAB_0BC9,A0        ;051aa20790001f8f8
    MOVE
.W    LAB_0BBE+2,D5        D5 bitmap->Rows
    BSR
.W    LAB_01A7        ;051b6610000c8
    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        ;051d8610000d8
    JSR    LAB_0A43        
;051dc4eb900018c56
    BRA
.W    LAB_01A0        ;051e260000002
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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284


Edited by kas1e on 2022/1/13 20:48:29
Edited by kas1e on 2022/1/13 21:08:17
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@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 registerdunno if d7 is freeI'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 :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@All

https://youtu.be/cc8Gl24u7-4

Now, 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.txt

As 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        ;1022820680010
   MOVE
.W     18(A0),D2        ;1022c34280012
   MOVE
.W     16(A0),D3        ;1023036280010
   RTS                         
;102344e75
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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 3025
@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.
   Report Go to top

Re: Exodus The Last War patching : work in progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7284
@LiveForIt
Yeah, now crashes differently. New crash log with disabled JIT:

http://kas1e.mikendezign.com/aos4/68k ... DSI_menu_disabled_jit.txt

Now while it still the same null-pointer crash, it point out on different disassembly:

68k disassembly:
 
61b99b6c246b000e             movea.l           0xe(a3),a2
 61b99b70
67000078             beq.w             0x61b99bea
*61b99b744a12                 tst.b             (a2)
 
61b99b7667000072             beq.w             0x61b99bea
 61b99b7a
4280                 clr.l             d0


Which is:

LAB_0755:
    
MOVEQ    #0,D6            ;10b54: 7c00
    
JSR    LAB_0759        ;10b564eb900010bea
    MOVEA
.L    14(A3),A2        ;10b5c246b000e
    BEQ
.W    LAB_0758        ;10b6067000078
    TST
.B    (A2)            ;10b644a12                    <= CRASH
    BEQ
.W    LAB_0758        ;10b6667000072
    CLR
.L    D0            ;10b6a4280
    TST
.B    27(A3)            ;10b6c4a2b001b
    BEQ
.W    LAB_0756        ;10b7067000008
    MOVE
.B    26(A3),D0        ;10b74102b001a
    LSL
.W    #2,D0            ;10b78: e548


_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: Exodus The Last War patching : work in progress
Just can't stay away
Joined:
2006/11/30 11:30
From Finland
Posts: 1809
@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

   Report Go to top

Re: Exodus The Last War patching : work in progress
Not too shy to talk
Joined:
2015/6/11 9:51
From Cologne
Posts: 438
@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        ;10b5c246b000e
BEQ
.W    LAB_0758        ;10b6067000078
    
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.

   Report Go to top


(1) 2 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project