Getting Napalm to run on AmigaOS 4.1.2?

@alfkil
Yep, IDA the best disassembler for all the time :)

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 ?

@kas1e

No, what I meant to say is, that I need a version of the gnu assembler ("as") that supports the -M option. Output from IDA
needs 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...

#as -v
GNU assembler version 2.18 (ppc-amigaos) using BFD version (GNU Binutils) 2.18

..
-L,--keep-locals keep local symbols (e.g. starting with `L')
-M,--mri assemble in MRI compatibility mode
--MD FILE write dependency information in FILE (default none)

OS4PPC on latest OS4 SDK IIRC

@jabirulo

But that is a powperpc assembler! What I need is 68k, which does not come with the SDK!

@alfkil
Btw, it is necessary to use 'as' exactly ? Maybe something like 'vasm' can help ?

@kas1e

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).

So where do we stand at the moment, is someone working on a patch to be able to run this classic game?

@Fairdinkem
We 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.

@Fairdinkem

I'm working on it...

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.

If someone wants to help, I can email "sources".

@ alfkil

Well as a fan of the game I want to thank you for trying I wish you all the best.

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??

@alfkil
Are you sure about endian issues ? I mean 68k and ppc are both big endianes, and usually "muffled" graphics when roots of problems are endians, looks a bit different.

Btw, the only bug with napalm its corrupted graphics ? No other DSIs of crashes or sound problems ?

@kas1e

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.

@alfkil

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:

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

Quote:

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:

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.

Quote:

Here ya go:

http://dl.dropbox.com/u/5482530/Code%20examples/NAPALM.lha

Have fun!

Maybe we can disassemble & reassemble WarpOS's games too ?

@samo

Haha, yes I would kill to have Wipeout2097 on my Sam

Don't know how to go about it, though. Does anyone know of an equivalent of IRA for powerpc??

@alfkil

Quote:

Wipeout 2097 already works on the SAM!

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.

@Chris

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??

Quote:

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:

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!

Chris