About -M, you mean you need IDA which support it, or you need a 68k binary of napalm which was compiled with -M ? If firts one : i can help (have many versions of ida, include latest ones). If second one, maybe it will help to reassemble with IRA, and then compile back with -M ?

No, what I meant to say is, that I need a version of the gnu assembler ("as") that supports the -M option. Output from IDAneeds to be reassembled with

> as -M mycode.asm

I have tried whatever version I could find in the geek gadgets repository, but apparently it doesn't support this option. The binutils version in gg is something like 2.10 and the -M option was apparently introduced around 2.14 (to judge from the documentation). At the moment, I'm trying to build binutils 2.14 with --target=m68k-coff, but I don't think this is going to help me a lot...

No need, I found an option in IDA to switch to "standard GNU assembler". Also I was able to build as and ld from binutils v.2.9 from the geek gadgets repository. Sadly, the resulting bin just crashes, which means I am back to the IRA output, which actually works when reassembled (with phxass).

@FairdinkemWe are still on "phase 1", with someone trying to disassemble the game & then re-assemble it back into something that works identically. Only with that done is it possible to try to find & fix what is causing the problem, which is a big job itself.

_________________
Author of the PortablE programming language.I love using Amiga OS4.1 It is pitch black. You are likely to be eaten by a grue...

Status now is (as stated before), that I am able to disassemble and reassemble the thing, and it seems to work identically (I tested it on my A1200).

At the moment I am trying to track down interpretable pieces of code (eg. system function calls) and structures. It is still at the very early stage, but I think I will have a firm grip on the situation soon.

Well, it looks like the "muffled" graphics problem is due to a bug in the blitter routines of RTGMaster.library, probably an endian issue (it looks like the graphics are "inverted" every 8 bits or so). I don't know how to solve this currently. Does anyone have access to the rtgmaster sources??

I have only gotten so far as to remove a few DSI's at the beginning when the game starts up. Some of the problem seems to be the dignet.library, which means that I have turned off network support for the time being. I do have the entire network driver "interpreted", so writing a new driver should be "trivial".

Now, Reth seems to have been able to get as far as to get the game actually starting on his peg2. I'm not so lucky here on my SAM, the game gets stuck right after the big "NAPALM" banner in the beginning. But I'm getting there... I'm thinking another week, and I'll have the game starting up and removed all DSI's.

Now, if that is true, the only problem remaining would be the "reversed order of pixels" (or "muffled" graphics), which I am not able to solve at the moment. The problem lies with the two functions

WriteRtgPixelArray

and

CopyRtgBlit

both in the rtgmaster.library. I can substitute the one for the other with same result, but they both seem to have the problem. If this problem is not fixed in at the root, I can only solve the problem by rewriting everything to use, say, picasso96, and I really don't want to do that...

@kas1e

About the endian thing: It is true, that both m68k and ppc are big endian, but what about the graphics hardware? Does it maybe have different features?? Also it might be signifficant, that the game is using CHUCKY graphics mode, the rtg demos that comes with the library all seem to use hi or truecolor modes.

Sounds like you fix all the problems already :) Btw, what the problem was with "stuck right after the big "NAPALM" banner" ? Just in some technical interest to know what the differneces in that terms beetwen sam and peg2 :)

So, except the corrupted graphics game already works with sound and so on ?:)

About those WriteRtgPixelArray and CopyRtgBlit functions, all what i have in mind right now : its just read the description of them in autodocs, and just rewrite them on WritePixelArray and CopyBlit (and so, we even can avoid rtgmaster.library, which are 68k as i understand? )

Quote:

About the endian thing: It is true, that both m68k and ppc are big endian, but what about the graphics hardware? Does it maybe have different features?? Also it might be signifficant, that the game is using CHUCKY graphics mode, the rtg demos that comes with the library all seem to use hi or truecolor modes.

From other side napalm works on voodoo3 cards as far as i remember on a1200/mediator ? They should be "almost the same" as radeons on our sams/pegs/a1s in terms of working with bytes.

But that "CHUNKY" stuff can be problem imho .. Maybe you can try to write some small example , which use those WriteRTGPixelArray and CopyRtgBlit with the same code logic as Napalm code do ? So maybe we even can found a bug in os4 component and can report it as well

Sounds like you fix all the problems already :) Btw, what the problem was with "stuck right after the big "NAPALM" banner" ? Just in some technical interest to know what the differneces in that terms beetwen sam and peg2 :)

I think you misunderstand: Reth was able to run the game _before_ I even started touching the code, I haven't released my code to anyone yet (before now). As with the stuckness after the banner, I don't know yet, but I'm working on it. Have you tried it on your peg2 machine??

Quote:

So, except the corrupted graphics game already works with sound and so on ?:)

I don't know yet wether the sound works or not. Only thing I know is, that it is using Paula directness, so it can only maybe work with NallePuh. I might try and demangle the sound driver module and see, if I can get some ahi in there.

Please can you remove the links to the Napalm executable and source (or I will do it for you ), it is still a commercial product so the modified executable should not be distributed (even if it doesn't work without all the data files!). You can use something like gpatch to distribute a patch file which can be applied.

Ok, I removed the link. I didn't consider it dangerous since Clickboom seems to mind their own business, but hey...

(The current link just contains my own code.)

By the way: How did you manage to get Wipeout running on a SAM?? I can install it, run it and start a game, but then it very quickly locks up the entire machine, and also there is some gfx problem with the shadow (or smth). I don't have those updates from ACube installed, do I need them??

Ok, I removed the link. I didn't consider it dangerous since Clickboom seems to mind their own business, but hey...

(The current link just contains my own code.)

It's a bit of a grey area, I think ClickBoom's own updates contained the full executable. However distributing modified versions of closed-source software is usually frowned upon, so better to be on the safe side, I don't want amigans.net to get into trouble. Aminet etc would likely only accept a patch file too.

Quote:

By the way: How did you manage to get Wipeout running on a SAM?? I can install it, run it and start a game, but then it very quickly locks up the entire machine, and also there is some gfx problem with the shadow (or smth). I don't have those updates from ACube installed, do I need them??

There is a graphical glitch (fixed in update 3 I believe), but other than that it works ok... or at least I thought it did. I can't test right this minute.

I doubt the updates would make any difference, but they are worth installing anyway!