ira for Windows

[jotd]

@phx yeah, I could just salvage a newer compiled version (1997) with FPU/68020. FPU makes the difference, not CPU. Giving that up.

@BruceAbbot I have proof that this tool is utter crap. Besides corrupting relocations, it also merges chipmem & pubmem hunks into pubmem hunks => copperlists in data chip hunks are relocated in fastmem! I changed the allocation of the data & bss hunks for that newer exe and it works fine.

A proper hunk merger doesn't merge chip & public memory hunks. That tool is the main reason why most TFX executables are unusable.

If you want to merge hunks, use compressors like TurboImploder and most of all TEST THE EXECUTABLE before delivery...

[Bruce Abbott]

Originally Posted by phx

But did the program ever work?

Apparently not.

Instructions on TFX.HDF say:-

There are various different executable files on this HDF. Each file is
optimised to run TFX on a different hardware configuration:

TFX.OLD - The original 68020 (non-FPU) version (works with Fast RAM)
TFX.FPU - The original 68020 FPU version (works with Fast RAM)
TFX.020 - The patched 68020 FPU version (tested and works)
TFX.030 - The patched 68030 FPU version (tested and failed to work)
TFX.040 - The patched 68040 FPU version (tested and failed to work)

NOTE: The patched version has only been successfully tested under WinUAE using AmigaDOS and 4MB/8MB of Chip RAM. Initial testing has shown that this version won't even work on a real A1200 with Fast RAM installed - and real Amigas can't use more than 2MB of Chip RAM!

I tried putting an illegal instruction at the start of the 030 executable and then capturing it in the debugger on startup (to make sure it used the system loadseg routines etc.) then single-stepped through the code. It hit bad code just where I expected it to based on my disassembly. So the 030 version is simply corrupt - no wonder disassemblers can't handle it!

The original 020+FPU version seems to work fine on my A1200 with 50MHz 030+32MB FastRAM, so that would be the one to work on.

[jotd]

The patched 68020 FPU version (tested and works). It's from 1997 so maybe the most advanced/bugfixed of the lot. Good enough. Using FPU and all means it's reasonably fast (people always fantasize on 68040/68060 instructions but they don't bring a lot/are generally not exploited by compilers because too exotic, maybe except for MOVE16... I admit I'm not a specialist)

My understanding is that this game is a mix of assembly and C. Not sure that there are a lot of custom FPU routines. Just the ones from the FPU C lib I reckon.

yeah, probably the same patch I applied: load data & bss symbols in chipmem: works.

The fact that the ones that don't work fail is because of the corrupt hunk relocs (see a few posts above: ira disassembly looks fine on a BRA instructions, but when run, memory indicates that the code has been tampered with)
And yes now that you're mentionning it, I stumbled on a version where even disassembly was complete bogus. must have been the .030 one.

I have a TFX.040 working version (with symbols!) from DamienD collection. Someone must have gotten that directly from the devs before they used hunkwizard

[jotd]

oh found a bug related to ROXL

IRA disassembly (2.09) (part of a decrunch routine for a game)

	ROXR.W	#1,D4			;1f778: e254
	DC.W	$e5e8			;1f77a   <-- bloody garbage :)
	DC.W	$0028			;1f77c
	ROXR.W	#1,D4			;1f77e: e254
	DC.W	$e5e8			;1f780   <-- bloody garbage :)
	ORI.W	#$e254,(A0)		;1f782: 0050e254
	DC.W	$e5e8			;1f786   <-- bloody garbage + desync :)
	ORI.W	#$e254,EXT_0224.W	;1f788: 0078e254e5e8
	ORI.L	#$51ca0016,-(A0)	;1f78e: 00a051ca0016
	LEA	2(A0),A0		;1f794: 41e80002
	MOVE.W	#$000f,D2		;1f798: 343c000f
	DBF	D1,LAB_07D3		;1f79c: 51c9000a

same disassembly on winuae shows ROXL properly

0001F778 e254                     ROXR.W #$01,D4
0001F77A e5e8 0028                ROXL.W (A0,$0028) == $000043a8 [0000]
0001F77E e254                     ROXR.W #$01,D4
0001F780 e5e8 0050                ROXL.W (A0,$0050) == $000043d0 [0000]
0001F784 e254                     ROXR.W #$01,D4
0001F786 e5e8 0078                ROXL.W (A0,$0078) == $000043f8 [0000]
0001F78A e254                     ROXR.W #$01,D4
0001F78C e5e8 00a0                ROXL.W (A0,$00a0) == $00004420 [0000]
0001F790 51ca 0016                DBF .W D2,#$0016 == $0001f7a8 (F)
0001F794 41e8 0002                LEA.L (A0,$0002) == $00004382,A0
0001F798 343c 000f                MOVE.W #$000f,D2
0001F79C 51c9 000a                DBF .W D1,#$000a == $0001f7a8 (F)

[phx]

Sorry, just noticed that today. Yes, that's a bug. Fixed in the V2.10beta source, which you can download here: http://sun.hasenbraten.de/~frank/TEST/ira_210beta.lha

Thanks for reporting!

[jotd]

Indeed. Rebuilt it with gcc and tried a disassembly: ROXL bug is now history

thanks

[kamelito]

Is IRA supporting FPU?

[jotd]

no it doesn't. One version supported it but was lost. Sad ain't it?

[phx]

It's all prepared to reimplement them. Nicolas wanted to work on it - since a few years. I have not much time either (too many other projects).

I do smaller changes and fixes, though.

[kamelito]

I may be doing something wrong after the fpu I can’t disassemble the next instruction properly, I’ll have to double check before posting.

[jotd]

fpu isn't disassembled then desyncs the assembly stream. I use winuae to complete the assembly for FPU parts. Tedious but possible

[kamelito]

Originally Posted by jotd

fpu isn't disassembled then desyncs the assembly stream. I use winuae to complete the assembly for FPU parts. Tedious but possible

Exactly ! (I use either MonAm or Resource myself)

@PHX
IRA is not disassembling the following code stream. Isn't it suppose to be andi.b #$FB, CCR ?

DC.W $023c
DC.W $fffb

Another one :
DC.L $4e7a8801
isn't it supposed to be : movec vbr, a0 ?

[phx]

Originally Posted by kamelito

IRA is not disassembling the following code stream. Isn't it suppose to be andi.b #$FB, CCR ?

DC.W $023c
DC.W $fffb

IRA expects $00fb by default, because the MSB of the extension word should be unused in a byte-size instruction. Some assemblers generate such code, so you have to enable compatibility mode for that:

-compat=bi

DC.L $4e7a8801
isn't it supposed to be : movec vbr, a0 ?

Yes, it is. But this is a 68010 instruction. Add the option

-m68010

[kamelito]

Thanks it’ll try that. Is it possible to choose the data type binary?

[phx]

Originally Posted by kamelito

Is it possible to choose the data type binary?

You mean a binary file, generated for a fixed absolute address, without any hunk-format header? Yes. By giving the option

-binary

. Also

-offset

and

-entry

might be useful.

Note that reassembling raw binary files requires some more work, because there are no relocation tables which tell IRA about pointer locations. Usually you will have to find these locations yourself and add them with the

PTRS

directive to the config file.

[jotd]

you don't have to specify binary, it's automatic if IRA doesn't detect executable format.

Sometimes IRA wrongly detects Atari ST executable format, ignores "binary" switch, fails with error and ... deletes the file!

[malko]

Originally Posted by jotd

[...] Sometimes IRA wrongly detects Atari ST executable format, ignores "binary" switch, fails with error and ... deletes the file!

Looks like an M$ "feature"

[kamelito]

Originally Posted by phx

You mean a binary file, generated for a fixed absolute address, without any hunk-format header? Yes. By giving the option

-binary

. Also

-offset

and

-entry

might be useful.

Note that reassembling raw binary files requires some more work, because there are no relocation tables which tell IRA about pointer locations. Usually you will have to find these locations yourself and add them with the

PTRS

directive to the config file.

No, I meant for example a sprite that could be disassembled as binary to show it's shape, or any other data types were binary is more suited.

[phx]

Originally Posted by jotd

Sometimes IRA wrongly detects Atari ST executable format, ignores "binary" switch, fails with error and ... deletes the file!

I guess Atari detection should be removed, as long as the executable-loader is not implemented. Simply delete the ATARI_MAGIC case in ira.c.

In fact I noticed some Amiga games in the past which have an Atari header starting with $601a. Probably Atari ports, which have been assembled on an Atari for the Amiga?

Originally Posted by kamelito

No, I meant for example a sprite that could be disassembled as binary to show it's shape, or any other data types were binary is more suited.

Not sure why you want to do that, as any hex dump does the same. But if you don't want IRA to disassemble something you just have to remove the CODE directives from the config file. (Or I'm still misunderstanding you.)

Are you doing multi-pass reassembling using a config file at all?

[kamelito]

@PHX
In the sprite example, I could change the shape in the source if I wanted, ex a mouse pointer.
I suppose that it could be also useful in deciphering opcode but I'm no expert.
Yep I use multipass like in the 5th Element