Some disassembled games with debug infos.

[Retro1234]

Originally Posted by phx

It's not easy to get an original GGS disk.

Download the WHDload version from here
http://www.whdownload.com/games/Pack..._v1.3_2500.zip

Inside the Zip is a Disk image called Disk.1 this is made from an Origanal commercial release -There were two commercial versions the first one had a bug saveing the high scores.You can also get an image in IPF.

Yeah im sure ive read that the Red Sector version has bugs in later levels.

Ive been poking around a Little in GGS Only with the maps and graphics - :-( Im still riping graphics when I can they seem to be all different sizes.

Id be curious to have a look at the source and compiled version ,Please could I get a Copy.

[phx]

Originally Posted by Boo Boo

Inside the Zip is a Disk image called Disk.1 this is made from an Origanal commercial release

Arrrgh! I should have known that before I started resourcing.
Maybe it's enough to extract the end-level...

Ive been poking around a Little in GGS Only with the maps and graphics - :-( Im still riping graphics when I can they seem to be all different sizes.

I have all data as separate files. A problem might be that the graphics also include data: for example all masks are preceded by three words defining the width in words, width in pixels and height.

Id be curious to have a look at the source and compiled version ,Please could I get a Copy.

No problem. Just drop me a mail.

[Retro1234]

Amazing - only had a quick look
Bobing.data - has the main Sprite
MapIMG.data - main tiles
Have to look further but very impresive.

Ran perfect from HD and exited pressing ESC back to workbench

[kamelito]

Same kind of list for PC DOS games, a bit off topic but could be interesting for porting those game to the Amiga eventually.
Kamel

http://bringerp.free.fr/forum/viewtopic.php?f=1&t=128

[hitchhikr]

Added Feud.

First post can't be edited anymore (maybe it's too old).

[TCD]

Added Feud to the first post

[earok]

Apologies if this is off topic, I'm attempting to make a very minor tweak to Test Drive 2 but haven't been able to disassemble it into something I can reassemble. IRA gives me this error:


Hunk...:00005734 NOT SUPPORTED.

[phx]

Originally Posted by earok

Hunk...:00005734 NOT SUPPORTED.

Which file did you try to disassemble? Is it even a hunk-format executable at all (has to start with 0x00, 0x00, 0x03, 0xf3) ?

If not, you should try to disassemble in binary mode (-BINARY option). Otherwise, there may be a bug in IRA.

[jotd]

Test Drive 2 has overlay hunks IIRC. IRA does not like them a lot. D68K works rather well with them.
Well, I prefer IRA, but when I cannot use it, I fall back to D68K. You can even convert D68K code into IRA code using a proper "sed" command.

[earok]

@phx it does indeed start with those four bytes.

@jotd I guess that's the problem! I haven't been able to assemble it with Phxass after putting it through D68K though. I don't know what switches to use, I figured NOPC and HexData switches were the logical ones but it results in a single error when attempting to assemble it:

JMP	L000C49(PC,D0.W)
36 Undefined symbol
in line 37766 (= line 37766 of duel.asm)

If I comment out that line it assembles (a few KB larger than the original) but doesn't run at all.

Btw I'm totally new to anything ASM related, so apologies for my ignorance

[phx]

Originally Posted by jotd

Test Drive 2 has overlay hunks IIRC. IRA does not like them a lot.

You're right! Overlay support is still missing. That explains it.
But also D68k doesn't explicitely mention Overlays in its documentation. At least it seems to read (or skip) those hunks correctly.

Originally Posted by earok

I haven't been able to assemble it with Phxass after putting it through D68K though.

As far as I understand D68k generates code which is compatible with the A68k assembler. PhxAss should assemble A68k sources fine.

JMP    L000C49(PC,D0.W)
36 Undefined symbol

Did you see L000C49 anywhere else in the output source? If not this may be a bug in D68k.
This looks like a jump table, and the L000C49 label cannot be far from the JMP instruction (maximum 128 bytes before or 126 bytes after it).

If I comment out that line it assembles (a few KB larger than the original) but doesn't run at all.

LoadSeg() doesn't even want to load it? Or does it crash?
Maybe the overlay support is not perfect after all.

[earok]

Originally Posted by phx

Did you see L000C49 anywhere else in the output source?

Nope, I didn't. One peculiarity with the labels, the label before that instruction is L000C48 and the one after was L000C4A. Peculiar that they mostly increase by iterations of 1 except for that big jump there.

Originally Posted by phx

LoadSeg() doesn't even want to load it? Or does it crash?
Maybe the overlay support is not perfect after all.

Just gives Software Failure, program failed (error #8000000B)


It could be that d68k doesn't like it or I'm using a completely wrong combination of switches

[phx]

Originally Posted by earok

the label before that instruction is L000C48 and the one after was L000C4A. Peculiar that they mostly increase by iterations of 1 except for that big jump there.

Most likely a D68k bug.

Just gives Software Failure, program failed (error #8000000B)

Maybe the removed JMP is so important that it is executed early. So the program runs over the now missing jump into the data of the jump-table. Guru #8000000B means that the data starts with $fxxx, like an FPU instruction.

When you show me a few lines before and 10-20 lines after that JMP, we may be able to reconstruct the missing label.

[RetroRusty]

Has anyone managed to get either the Zool 2 code or the Alien Breed SE code to run? I can assemble them without any errors or warnings, but when I run Zool 2 I just a red screen and when I run AB SE I just get a green screen. Anyone have any ideas what I'm doing wrong or is anyone having the same issues?

[Retro1234]

Not for ages! but I remember Zool 2 running well.

Forgot about these shame no-one did anything with these

[jotd]

if you reassemble a disassembled exe, make sure no optimizations are on. Data is often mistaken for code, and optimizations (like branch optimizations) from & on fake code change values and introduces bug. Most of the time it's ASCII errors (branch instructions are in the range of lowercase ASCII) but it can be other things

Or do things properly and identify ALL data zones... Not a piece of cake.

[saimon69]

Wonder if Outrun and Turbo outrun could be disassembled so for someone to do the same improvements that happened to the Atari STE version

[denis2342]

Originally Posted by phx

You're right! Overlay support is still missing. That explains it.
But also D68k doesn't explicitely mention Overlays in its documentation. At least it seems to read (or skip) those hunks correctly.


As far as I understand D68k generates code which is compatible with the A68k assembler. PhxAss should assemble A68k sources fine.

Did you see L000C49 anywhere else in the output source? If not this may be a bug in D68k.
This looks like a jump table, and the L000C49 label cannot be far from the JMP instruction (maximum 128 bytes before or 126 bytes after it).

LoadSeg() doesn't even want to load it? Or does it crash?
Maybe the overlay support is not perfect after all.

Most possibly the Label is inside the JMP instruction and cannot be displayed because of that.

one example with hex data:

				L00AE:
000D7C	FE18				dc.w	L009C-L00B0
000D7E	0002				dc.w	L00B1-L00B0
000D80	FF00				dc.w	L00A5-L00B0
000D82	FF00				dc.w	L00A5-L00B0
000D84	FE18				dc.w	L009C-L00B0
				L00AF:
000D86	90BC 0000 0068			SUB.L	#$00000068,D0
000D8C	B0BC 0000 0005			CMP.L	#$00000005,D0
000D92	640A				BCC.B	L00B1
000D94	E380				ASL.L	#1,D0
000D96	303B 00E4			MOVE.W	L00AE(PC,D0.W),D0
000D9A	4EFB~0000			JMP	L00B0(PC,D0.W)
				L00B1:
000D9E	422C 994A			CLR.B	-$66B6(A4)
000DA2	422C 9907			CLR.B	-$66F9(A4)
000DA6	6000 01C6			BRA.W	L00C2

D68k uses the tilde ~ to show that there is a label (L00B0 ) inside the command.

[phx]

Originally Posted by denis2342

Most possibly the Label is inside the JMP instruction and cannot be displayed because of that.

Other reassemblers would probably output

L00B0:  JMP     L00B0+2(PC,D0.W)

instead of indicating their failure with a tilde.

[denis2342]

Originally Posted by phx

Other reassemblers would probably output

L00B0:  JMP     L00B0+2(PC,D0.W)

instead of indicating their failure with a tilde.

Yes, that would do it. But the disassembler would need to check that that label is not used by anything else.

After some thinking, that would not work. The jumptable is relative to L00B0 and that value needs to be used for the JMP instruction.
So just put the label somewhere near and don't use the +2.