Gunstar Heros disassembly?

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

OrangyTang
Interested
Posts: 30
Joined: Tue Feb 23, 2016 4:45 pm

Gunstar Heros disassembly?

Post by OrangyTang » Tue Feb 23, 2016 4:51 pm

Hello all!

I'm looking to get into asm coding and hackery, and the MD seems like an interesting place to start. I thought rather than start from scratch an interesting beginning might be to try and do a disassembly (a bit like the excellent sonicretro ones) for a game I'm familiar with.

Are there any existing disassemblies for Gunstar Heros? I'd like to take a stab at something that's not really been touched by the community, and GH has got so much going on technically it'd probably be pretty interesting. And potentially super complicated and beyond me, but whatever. :)

Alternatively, if there's any other interesting classic games that don't have a disassembly done on them yet I'm open to suggestions.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: Gunstar Heros disassembly?

Post by MintyTheCat » Tue Feb 23, 2016 10:08 pm

OrangyTang wrote:Hello all!

I'm looking to get into asm coding and hackery, and the MD seems like an interesting place to start. I thought rather than start from scratch an interesting beginning might be to try and do a disassembly (a bit like the excellent sonicretro ones) for a game I'm familiar with.

Are there any existing disassemblies for Gunstar Heros? I'd like to take a stab at something that's not really been touched by the community, and GH has got so much going on technically it'd probably be pretty interesting. And potentially super complicated and beyond me, but whatever. :)

Alternatively, if there's any other interesting classic games that don't have a disassembly done on them yet I'm open to suggestions.
GSH is a good place to start. You may find yourself referring back to the Sonic disassemblies fairly often though as reference.

You will also needs some tools. I use my own MD Util but I am not really looking to support it for the time being so you will have to write your own tools for now. The place to start is to make your own custom ROM version of GSH that is bigger than the original so that you can patch your own code in during disassembly to re-wire the game to try things out, and then you need to patch your ROM's checksum - simple to do with a tool or script. Over the next year or so I will release MDU publicly.

The best advice that I can give is to work incrementally but dive in and get to know the code. Use some tools to try to find graphics stored in standard formats - look up the compression schemes common to the MD for example.

Work in blocks: what is the main title screen? What is the attract mode? That sort of thing.
Once you have a feel for it then you can delve in and out and start to make sense of smaller blocks of code.
Aim to follow good practices from the outset as best you can and pick a well written MD game to learn from.

You will learn a hell of a lot by exposing yourself to a commercial game ROM's code and a lot more than simply following a tutorial - after all very few of us knew as much about the MD as the commercial developers did back the MD's hey day and what's more you will pick up a lot of tricks along the way as to how to use the 68K, Z80, etc.

Best of luck.

Cheers,

Minty.
UMDK Fanboy

Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: Gunstar Heros disassembly?

Post by Natsumi » Thu Feb 25, 2016 10:55 am

I do not know if there is a disassembly of the game, however if not, I would suggest not to make one as a first programming practice. Simply because you cant just change one line to see what happens, unlike with pre-existing disassembly. Instead, I'd suggest taking a look at the Sonic 1 disassemblies that exist already. They are a good way to practice programming and see what changes do what. I would also recommend against using the Git version as your primary disassembly; while its more documented, the file structure is horrible and many of the expressions are rather complex for their own good. Remembering few useful subroutines and RAM addresses by their number is not that hard in comparison to remembering tons of files, subroutines and RAM addresses by their weird titles, etc. Also if you have questions, its more likely its asked in some form before, sonic Sonic Retro and SSRG qna topics will likely help.

OrangyTang
Interested
Posts: 30
Joined: Tue Feb 23, 2016 4:45 pm

Re: Gunstar Heros disassembly?

Post by OrangyTang » Thu Feb 25, 2016 2:28 pm

Cheers guys, it's useful to have pointers like these. :) I'd like to take a stab at a dissassembly since I find I don't really learn from poking around existing disassemblies - they're impressive but unless I'm doing the work myself the knowledge just bounces off again and I don't remember it long term.

Is there any particular tools that you'd recommend? I've been trying to use 68kd but that doesn't work on Win7 64bit, and doesn't seem to run in Doxbox either. IDA Pro with the Mida script seems to produce something sensible, but after saving the asm out, it's not actually compilable with AS:

Code: Select all

> > >Gunstar Heroes (E) [!] disassembled.asm(2343): warning #50: privileged instruction                    
> > > 		rte                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2521): warning #50: privileged instruction                    
> > > 		move	#$2700,sr                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2567): error #1340: short addressing not allowed                    
> > > 		lea	(unk_F400).w,a2                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2567): error #1350: addressing mode not allowed here                    
> > > 		lea	(unk_F400).w,a2                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2662): warning #50: privileged instruction                    
> > > 		move	(sp)+,sr                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2734): error #1340: short addressing not allowed                    
> > > 		lea	(unk_E300).w,a0                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2734): error #1350: addressing mode not allowed here                    
> > > 		lea	(unk_E300).w,a0                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2735): error #1340: short addressing not allowed                    
Is that normal? I had expected the result would still compile, even if it was full of arbitrary lables and offsets.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: Gunstar Heros disassembly?

Post by MintyTheCat » Thu Feb 25, 2016 11:28 pm

Natsumi wrote:I do not know if there is a disassembly of the game, however if not, I would suggest not to make one as a first programming practice. Simply because you cant just change one line to see what happens, unlike with pre-existing disassembly.
Not at all: simply build a ROM that includes the original and is large enough to hold the code that you write, re-checksum, patch the MD header and you are up and running, repeat each time or better still use a proper patching method that keeps the entries as mods to the ROM image - like an update database. I do this myself for reversing work.

Saying that, it boils down to how able you are with Assembly in general and 68K/Z80 in particular.

As natsumi said, it is necessary to keep the Sonic 1 Disassembly around as a reference particularly for standard things.
Natsumi wrote: Instead, I'd suggest taking a look at the Sonic 1 disassemblies that exist already. They are a good way to practice programming and see what changes do what.
ROM-hacking I am told is the most involved but at the same time you get a LOT more knowledge in the practice so it may be worth it for some people but not for others. Remember that there is no better example of MD reference codewise than commercial ROMs - there were no books written, no tutorials written by people from back in the day so this is the best document that we have but it is testament all the same.

OrangyTang wrote:Cheers guys, it's useful to have pointers like these. :) I'd like to take a stab at a dissassembly since I find I don't really learn from poking around existing disassemblies - they're impressive but unless I'm doing the work myself the knowledge just bounces off again and I don't remember it long term.
I agree: get burned often, find things out and find out how your original ideas were wrong :)
The MD, like a lot of ancient hardware now is a machine to be fiddled with and experimented with and no, the emulator usually lies so you have to hack the real hardware to learn something I find most of the time but Emulators are useful too for some situations.
OrangyTang wrote: Is there any particular tools that you'd recommend? I've been trying to use 68kd but that doesn't work on Win7 64bit, and doesn't seem to run in Doxbox either. IDA Pro with the Mida script seems to produce something sensible, but after saving the asm out, it's not actually compilable with AS:
Tools:

Assembler, Linker, etc: I have used ASM68K (old and a bit limited I find), VASM (decent and actively developed) and GNU-AS (been with us for years and you get the Binary-Utils for free - very flexible and will most likely be with us for decades). When I first got into the MD I used ASM68K but it is a bit shit I feel so I switched to AS and yes, it has some odd additions and departs slightly from standard 68K but this no longer is an issue for me as I can use both. The main advantage to VASM and AS is that they allow you to use Linker-Scripts and both are a lot easier when linking to C code than ASM68K would be.

UNIX: all the tools that I use that matter but I cannot remember them to list them here but all the usual stuff.

Hex Editor: you need at least one decent Hex Editor - I use HxD under Windows and Od under UNIX.

Diff: I use Beyond Compare and it rules - well worth the $.

MD Util: my own Swiss-Army Knife tool for MD work for all the standard stuff, e.g. patching your MD ROM, compression/decompression, etc. - I will release it maybe this year publicly; had to get a site sorted out for support and then I need to have the time to support it but yes, something like that or your own tools are what you need.

UMDK: yes, THE tool for working with the MD Hardware that I use. I also have a couple of Everdrives but do not use them now that I have UMDK.

Emulator: I use GENSIDA by Dr Mefisto and it is very good. Exodus worked once then crashed and never worked again; I have asked Nemesis to tell me what is going on. All the same, it is a very decent Emu to use when developing MD apps.

Disassembler: you have a few options here.

Tools to get inside the MD; I used an RS232 based command-monitor before I got UMDK and that allowed me to patch the MD's memory directly without needing to reset the MD Hardware but UMDK can offer you a lot more. I am looking to add the RS232 monitor support to UMDK to allow you get inside the MD directly without going through GDB.

Also, some people used the old 68K ICEs to get inside the 68K too but they may be a bit old and not really easy to get up and running these days on PC hardware.

Lab Equipment: Logic-Analysers, port capturers (joypad, RS232) and an Oscilloscope help. Note that UMDK now also has a Logic-Analyser built in too but I still use my other LAs to sample what UMDK cannot as UMDK is limited in channels.
OrangyTang wrote:

Code: Select all

> > >Gunstar Heroes (E) [!] disassembled.asm(2343): warning #50: privileged instruction                    
> > > 		rte                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2521): warning #50: privileged instruction                    
> > > 		move	#$2700,sr                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2567): error #1340: short addressing not allowed                    
> > > 		lea	(unk_F400).w,a2                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2567): error #1350: addressing mode not allowed here                    
> > > 		lea	(unk_F400).w,a2                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2662): warning #50: privileged instruction                    
> > > 		move	(sp)+,sr                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2734): error #1340: short addressing not allowed                    
> > > 		lea	(unk_E300).w,a0                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2734): error #1350: addressing mode not allowed here                    
> > > 		lea	(unk_E300).w,a0                    
> > >Gunstar Heroes (E) [!] disassembled.asm(2735): error #1340: short addressing not allowed                    
Is that normal? I had expected the result would still compile, even if it was full of arbitrary lables and offsets.
Yes, that is normal, but why the LEAs twice? That makes no sense. Can you show me the Hex for that section of the ROM please? I want to see what the code is directly.

But what you care about is the machine state - the Z80 and 68K's registers, the VDP's registers, etc.
What you do is you see what is referenced, what calls what, then try to work out what the code does vs. what you see the app/game doing in real time.

Good luck.
UMDK Fanboy

Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: Gunstar Heros disassembly?

Post by Natsumi » Fri Feb 26, 2016 12:04 am

OrangyTang wrote: it's not actually compilable with AS
I highly suggest against (for everyone) using AS. Its syntax is not compatible with any other assembler, disassembler, or other tool, it is slow as hell, its 68k and z80 implementations are crap and it accepts nonsensical opcodes and operands. It does not output correct errors (I once got it to say it wouldnt accept BNE as an instruction when momcpu is 68k. The issue was like 200 lines up which resolved it). It always doesnt seem to even build identical ROM image despite no changes in code!!! I would suggest ASM68K personally. Sure its not perfect tool either, but it can do most of what AS can, assemblers super quick, uses very little system resources, and still has very powerful macro language. Only really bad thing is it does not support Z80 (but it was never developed Z80 in mind either).

OrangyTang
Interested
Posts: 30
Joined: Tue Feb 23, 2016 4:45 pm

Re: Gunstar Heros disassembly?

Post by OrangyTang » Fri Feb 26, 2016 7:50 am

MintyTheCat wrote: ...
Good stuff, thanks!
MintyTheCat wrote: Yes, that is normal, but why the LEAs twice? That makes no sense. Can you show me the Hex for that section of the ROM please? I want to see what the code is directly.

But what you care about is the machine state - the Z80 and 68K's registers, the VDP's registers, etc.
What you do is you see what is referenced, what calls what, then try to work out what the code does vs. what you see the app/game doing in real time.
So this is from some asm output generated from messing around in IDA (still working my way through the IDA book, so I'm really not sure what I'm doing yet). The actual area around the error looks like this:

Code: Select all

loc_DC6:				; CODE XREF: sub_D48+52j
		move.w	#$8F02,(a0)
		move.l	#$93409400,(a0)
		move.w	#$9580,(a0)
		move.w	#$96F1,(a0)
		move.w	#$977F,(a0)
		move.l	#$C0000080,($FFFFF700).w
		move.w	($FFFFF700).w,(a0)
		move.w	($FFFFF702).w,(a0)

loc_DEC:				; CODE XREF: sub_D48+7Aj
		lea	(unk_F400).w,a2
		movea.w	($FFFFF70C).w,a3
		cmpa.w	a2,a3
		beq.w	loc_E10

loc_DFA:				; CODE XREF: sub_D48+BEj
		move.l	(a3)+,(a0)
		move.l	(a3)+,(a0)
		move.l	(a3)+,(a0)
		move.w	(a3)+,(a0)
		move.w	(a3)+,(a0)
		cmpa.w	a2,a3
		bne.s	loc_DFA
		move.w	a3,($FFFFF70C).w
		move.w	a3,($FFFFF70E).w
And the label it's referencing is:

Code: Select all

		dc.b   0
		dc.b $74 ; t
		dc.b $4E ; N
		dc.b $75 ; u
unk_F400:	dc.b $61 ; a		; DATA XREF: sub_D48:loc_DECo
		dc.b   0
		dc.b   0
		dc.b $FC ; ü
		dc.b $3B ; ;
		dc.b $7C ; |
		dc.b   0
		dc.b $14
		dc.b   0
		dc.b $48 ; H
		dc.b $42 ; B
		dc.b $6D ; m
Where unk_F400 is way down at line 60000 (I haven't managed to figure out where in ROM that'll appear yet). I guess I'm trying to come at this from the opposite direction - just get an .asm file that recompiles to the exact same bytes, without worrying about what the code is actually doing right now. Which is why I'm confused why IDA would generate an instruction different from what's actually decoded. I assume the error is because unk_f400's address doesn't fit in 16bits, so I guess that means it *used* to fit within, but now doesn't in my .asm file?

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Re: Gunstar Heros disassembly?

Post by r57shell » Fri Feb 26, 2016 10:21 am

I just wanna warn you.
If you wanna make full disassembly of some game, it will took for you several years. (solo)
Image

Natsumi
Very interested
Posts: 81
Joined: Mon Oct 05, 2015 3:00 pm
Location: 0x0
Contact:

Re: Gunstar Heros disassembly?

Post by Natsumi » Fri Feb 26, 2016 10:34 am

I'd say months is closer to accurate, depending on the size of the ROM and complexity of the code. Of course, the skills of the user also factors on the speed they can resolve code. Yes it could take years, no doubt, but I know people who can make a building disassembly of a game in even weeks. Not very well documented but fully usable.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: Gunstar Heros disassembly?

Post by MintyTheCat » Fri Feb 26, 2016 10:53 am

Natsumi wrote:
OrangyTang wrote: it's not actually compilable with AS
I highly suggest against (for everyone) using AS. Its syntax is not compatible with any other assembler, disassembler, or other tool, it is slow as hell, its 68k and z80 implementations are crap and it accepts nonsensical opcodes and operands. It does not output correct errors (I once got it to say it wouldnt accept BNE as an instruction when momcpu is 68k. The issue was like 200 lines up which resolved it). It always doesnt seem to even build identical ROM image despite no changes in code!!! I would suggest ASM68K personally. Sure its not perfect tool either, but it can do most of what AS can, assemblers super quick, uses very little system resources, and still has very powerful macro language. Only really bad thing is it does not support Z80 (but it was never developed Z80 in mind either).
Do you mean GNU AS or GAS right?

If so this is simply not the case and GAS runs fast, you are able to find the bugs in your code from the Assembler alone and what's more you have the symbols, listing and such available. You may be referring to a multi object file that you turn into an ELF file though but that is not an issue in GAS itself.
UMDK Fanboy

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: Gunstar Heros disassembly?

Post by MintyTheCat » Fri Feb 26, 2016 11:37 am

OrangyTang wrote:
MintyTheCat wrote: Yes, that is normal, but why the LEAs twice? That makes no sense. Can you show me the Hex for that section of the ROM please? I want to see what the code is directly.

But what you care about is the machine state - the Z80 and 68K's registers, the VDP's registers, etc.
What you do is you see what is referenced, what calls what, then try to work out what the code does vs. what you see the app/game doing in real time.
You need to tell us what a0 is set to but my guess is the VDP's control-port from the code you list here.
I have begun to annotate your listing but I would need more contextual information to determine exactly what is going on and time :D
OrangyTang wrote:
So this is from some asm output generated from messing around in IDA (still working my way through the IDA book, so I'm really not sure what I'm doing yet). The actual area around the error looks like this:

Code: Select all

loc_DC6:				; CODE XREF: sub_D48+52j
		move.w	#$8F02,(a0)         ; Set VDP's auto-increment to two - assuming a0 is set to VDP's control-port.
		move.l	#$93409400,(a0)  ; This looks wrong to me.
		move.w	#$9580,(a0)         ; Set DMA source: top byte.
		move.w	#$96F1,(a0)         ; Set DMA source: middle byte.
		move.w	#$977F,(a0)         ; Set DMA source: low byte.
		move.l	#$C0000080,($FFFFF700).w ; Set location $FFF700 to $C0000080 - what is that location used for and what does the value mean? Find out.
		move.w	($FFFFF700).w,(a0)  ; VDP Word1 set to $C0000080 : W1 is: CD1CD0=0b11, A13..A0=0.
		move.w	($FFFFF702).w,(a0)  ; VDP Word2 set to what ever is at $FFFFF702 - find out.

I do not have the time to annotate the rest of the disassembly now but follow what I did above filling in your knowledge :)

loc_DEC:				; CODE XREF: sub_D48+7Aj
		lea	(unk_F400).w,a2
		movea.w	($FFFFF70C).w,a3
		cmpa.w	a2,a3
		beq.w	loc_E10

loc_DFA:				; CODE XREF: sub_D48+BEj
		move.l	(a3)+,(a0)
		move.l	(a3)+,(a0)
		move.l	(a3)+,(a0)
		move.w	(a3)+,(a0)
		move.w	(a3)+,(a0)
		cmpa.w	a2,a3
		bne.s	loc_DFA
		move.w	a3,($FFFFF70C).w
		move.w	a3,($FFFFF70E).w
And the label it's referencing is:

Code: Select all

		dc.b   0
		dc.b $74 ; t
		dc.b $4E ; N
		dc.b $75 ; u
unk_F400:	dc.b $61 ; a		; DATA XREF: sub_D48:loc_DECo
		dc.b   0
		dc.b   0
		dc.b $FC ; ü
		dc.b $3B ; ;
		dc.b $7C ; |
		dc.b   0
		dc.b $14
		dc.b   0
		dc.b $48 ; H
		dc.b $42 ; B
		dc.b $6D ; m
Where unk_F400 is way down at line 60000 (I haven't managed to figure out where in ROM that'll appear yet). I guess I'm trying to come at this from the opposite direction - just get an .asm file that recompiles to the exact same bytes, without worrying about what the code is actually doing right now. Which is why I'm confused why IDA would generate an instruction different from what's actually decoded. I assume the error is because unk_f400's address doesn't fit in 16bits, so I guess that means it *used* to fit within, but now doesn't in my .asm file?
From the Map and Listing files generated check the location - you may find that some are on odd addresses - use the Even directive to fix that.
IDA should generate a list of what it considers code segments but you also have to help IDA determine what is code and what is data.
UMDK Fanboy

OrangyTang
Interested
Posts: 30
Joined: Tue Feb 23, 2016 4:45 pm

Re: Gunstar Heros disassembly?

Post by OrangyTang » Fri Feb 26, 2016 11:59 am

MintyTheCat wrote: You need to tell us what a0 is set to but my guess is the VDP's control-port from the code you list here.
I have begun to annotate your listing but I would need more contextual information to determine exactly what is going on and time :D
See this is where I think I have a conceptual gap that means I'm probably not making sense. I don't understand why generating an initial .bin -> .asm that can be compiled back to a byte-idential rom can't be done 100% automatically. Yes the raw bytes can be intepreted as either code or embedded data, but (ignoring readability issues) a collection of bytes can be converted back to opcodes. And if the byte pattern doesn't correspond to an exact byte code, then just into an assembly directive to embed / poke that data value at that point in the binary. Which is why I'm confused that IDA seems to have generated a non-compilable .asm listing.

But... experimenting with three different disassemblers suggests that something in my reasoning above is incorrect, or the tools aren't good enough (or more likely, I'm using them wrong). So which bit am I misunderstanding here?

Thanks.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: Gunstar Heros disassembly?

Post by MintyTheCat » Fri Feb 26, 2016 12:15 pm

OrangyTang wrote:
MintyTheCat wrote: You need to tell us what a0 is set to but my guess is the VDP's control-port from the code you list here.
I have begun to annotate your listing but I would need more contextual information to determine exactly what is going on and time :D
See this is where I think I have a conceptual gap that means I'm probably not making sense. I don't understand why generating an initial .bin -> .asm that can be compiled back to a byte-idential rom can't be done 100% automatically.
Please be very careful to make the distinction between compiling and assembling - you mean assembling here.
Well, it cannot be done automatically as you have several types of entries within the ROM, e.g. MD graphics data of various kinds, Z80 code, 68K code and other types of data. IDA does not know initially what the entire ROM comprises of at first - look up for the first and second pass disassembly process works.
OrangyTang wrote: Yes the raw bytes can be intepreted as either code or embedded data, but (ignoring readability issues) a collection of bytes can be converted back to opcodes. And if the byte pattern doesn't correspond to an exact byte code, then just into an assembly directive to embed / poke that data value at that point in the binary. Which is why I'm confused that IDA seems to have generated a non-compilable .asm listing.
The world is your oyster at the assembly level; you can interpret data as code and like wise as you need to - that is what IDA, being interactive, offers you as a user. You know that if a read or write action occurs into a section of ROM/RAM that you are looking data and variables but if you see jumps and branches that you are looking at code - IDA knows this too or at least it makes a best guess with the first-pass.
OrangyTang wrote: But... experimenting with three different disassemblers suggests that something in my reasoning above is incorrect, or the tools aren't good enough (or more likely, I'm using them wrong). So which bit am I misunderstanding here?
Thanks.
Most likely, as I have found this myself it is a combination of us and the tools.
I use IDA a lot and I cannot fault it. How much experience do you have with 68K, Z80 and the Megadrive? You may well be 'trying to run before you can walk kind of thing which is not a bad thing provided that you take small but sure steps along the way.

To make real progress you have to have no fear of the hardware and you have to understand it. You also have to know 68K pretty well because stumbling at an opcode and the effect it has on the hardware will disrupt the flow and lessen your chances of comprehension.

Worst-case: work with a 68K simulator and writes your own 68K Assembly programs - ignore C as most commercial MD games were written in pure Assembly. You can tell very quickly that this code was written by human and not machine as the machine is too overly cautious.
UMDK Fanboy

OrangyTang
Interested
Posts: 30
Joined: Tue Feb 23, 2016 4:45 pm

Re: Gunstar Heros disassembly?

Post by OrangyTang » Fri Feb 26, 2016 12:38 pm

MintyTheCat wrote: Well, it cannot be done automatically as you have several types of entries within the ROM, e.g. MD graphics data of various kinds, Z80 code, 68K code and other types of data. IDA does not know initially what the entire ROM comprises of at first - look up for the first and second pass disassembly process works.
I apologise if I'm being dense here, just trying to narrow down the reason for this specific behaviour.

I get that the actual raw bytes could be all kinds of things, and that pulling them apart is the human bit. But I don't understand why IDA has seen a sequence of bytes and interpreted them as (in this case) a LEA instruction with an out-of-range value, ie. a fragment of asm which doesn't assemble back into the same raw sequence of bytes. Yes, it could be some kind of non-code data, but that would still have a valid transformation to an asm form, even if it didn't make sense from a human point of view.

I suspect the above makes no sense. I'm having a hard time communicating exactly what I mean :S

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: Gunstar Heros disassembly?

Post by MintyTheCat » Fri Feb 26, 2016 1:05 pm

OrangyTang wrote:
MintyTheCat wrote: Well, it cannot be done automatically as you have several types of entries within the ROM, e.g. MD graphics data of various kinds, Z80 code, 68K code and other types of data. IDA does not know initially what the entire ROM comprises of at first - look up for the first and second pass disassembly process works.
I apologise if I'm being dense here, just trying to narrow down the reason for this specific behaviour.

I get that the actual raw bytes could be all kinds of things, and that pulling them apart is the human bit. But I don't understand why IDA has seen a sequence of bytes and interpreted them as (in this case) a LEA instruction with an out-of-range value, ie. a fragment of asm which doesn't assemble back into the same raw sequence of bytes. Yes, it could be some kind of non-code data, but that would still have a valid transformation to an asm form, even if it didn't make sense from a human point of view.

I suspect the above makes no sense. I'm having a hard time communicating exactly what I mean :S
Simply tell IDA to treat the section that it thought was code as data - that way it will look correct. Make sure that it really is though so if you see the PC being set to that address then you know it was actually code. It never does any harm to treat everything at the start as data as you work your way through. IDA will make a best guess and get it wrong. Is this your code, a tutorial ROM or a commercial ROM?

Actually, IDA could if you tell it or it thinks the bytes are opcodes get it wrong and thereby generate illegal code :D
UMDK Fanboy

Post Reply