User | Post |
HyperLamer
Posts: 2533/8210 |
It's just like using Snes9x trace logs, but it puts them in order and doesn't repeat anything. It won't come out looking like the original but it should be re-assembleable and laid out properly (just with generic label names, and any unused code such as debug modes marked as data). |
ev0
Posts: 9/27 |
http://setsuna.the2d.com/?page=utils
xkas one of the better assembler (or the best... xD) |
Hyde
Posts: 5/24 |
Originally posted by MathOnNapkins Wait... so um I'm confused. Are you trying to do an automatic disassembly or are you trying to do a disassembly based off playing the game?
To get a complete disassemly you must use an emulator of some sort, unless, of course, you come up with some sort of kick-ass algorithm that reveals every piece of information you need about code segments. By the way, for those of you who have not yet seen my disassembler, go to the Games Sources sections of my site:
http://hydesprojects.cjb.net
(I promisse I am not going to advertise it again) |
bbitmaster
Posts: 37/103 |
All I can say is good luck, I've been planning on doing this with the nes for the past 2+ years, although I've got sidetracked
I still want to accomplish this with FCEUXD, but it will still take quite a bit of work. |
MathOnNapkins
Posts: 1155/2189 |
Wait... so um I'm confused. Are you trying to do an automatic disassembly or are you trying to do a disassembly based off playing the game? |
HabsoluteFate
Posts: 85/179 |
Originally posted by Parasyte Yes, the idea is nothing new. It can be done. Just don't expect the output to be equivalent to source code.
The output should still end up ok enough to re-assemble though in theory |
Parasyte
Posts: 165/514 |
Yes, the idea is nothing new. It can be done. Just don't expect the output to be equivalent to source code. |
HabsoluteFate
Posts: 84/179 |
Originally posted by Hyde I've done something like this, but for the NES. The disassembler works in combination with an emulator that keeps track of code / data information. Doing such a thing for the SNES would be more complicated though. First of all, you'd have to keep track of which code blocks are to be interpreted under 16/8 bit mode. Sure, an emulator could help you with this, but what if a block can be executed under both modes? This can be a big problem. Also, indirect jumps cannot be handled correctly without the use of an emulator. One good thing about the SNES though, is that, if I remember correctly, it does not provide carts with means to perform bankswitching. SPC7000 disassembly does not seem to be terribly difficult, as I've learned from working on my own disassembler.
Hi, I'm already keeping track of what mode all pieces of code i run though are (during their first encounter since the dissasembler doesn't need to dissasemble the same piece twice). I might learn i need to go though code more than once later but that will come as i do this and any other surprises i might see...hopefully i wont Basically I assume an address is Data at first. I go though it and as i go though it I mark things as 8 or 16 bit depending on what mode i'm in right now. At the very worst I might miss some code areas and they will show up as data....which would still show up as proper assembly in the decompiled file...hopefully that will be minimal though and perhaps as i work on this there will be less and less isntances of that
As for the emulator requirements I guess its all part of the "fun" stuff I'm going to learn as I go...I did want to have an emulator in what i'm designing anyways since i want better debugging with tracing through code as well as breakpoints in code. Although early on the emulation will occur without sound & graphics to keep things simple...I don't want to tackle sound quite yet...although i will have to at some point...I havent had the chance to look into the SPC's processor yet... I have a couple of op codes working right now (emulated) but i just started so that should grow over time..
I am using Peer's modified Snes9x to verify my code...as for the blocks that can be interpretted in both 16 & 8 bit...i did think about the fact that it would be possible but I'm hopping there arent any...I couldn't think of how the code would have been written in the first place to allow for that?
Originally posted by Parasyte
Originally posted by Evil Peer although because it will have to "emulate" while it disasembles its going to be slower at doing it than other dissasemblers....
I am afraid there is no feasible way to do this. Even during full emulation, not all code will be executed in any given playthrough. Your real nemesis here is the code routine pointer table.
---Evil Peer
On the contrary! IDA Pro does exactly that; emulates instructions to seperate code from data. It's not PERFECT, exactly. But it gets the job done. If you don't know what IDA Pro is, here's an example: http://www.datarescue.com/idabase/gallery/6502.htm
Good to know my idea has worked somewhere else even though it might not be entirely perfect! |
Parasyte
Posts: 164/514 |
Originally posted by Evil Peer although because it will have to "emulate" while it disasembles its going to be slower at doing it than other dissasemblers....
I am afraid there is no feasible way to do this. Even during full emulation, not all code will be executed in any given playthrough. Your real nemesis here is the code routine pointer table.
---Evil Peer
On the contrary! IDA Pro does exactly that; emulates instructions to seperate code from data. It's not PERFECT, exactly. But it gets the job done. If you don't know what IDA Pro is, here's an example: http://www.datarescue.com/idabase/gallery/6502.htm |
Hyde
Posts: 4/24 |
I've done something like this, but for the NES. The disassembler works in combination with an emulator that keeps track of code / data information. Doing such a thing for the SNES would be more complicated though. First of all, you'd have to keep track of which code blocks are to be interpreted under 16/8 bit mode. Sure, an emulator could help you with this, but what if a block can be executed under both modes? This can be a big problem. Also, indirect jumps cannot be handled correctly without the use of an emulator. One good thing about the SNES though, is that, if I remember correctly, it does not provide carts with means to perform bankswitching. SPC7000 disassembly does not seem to be terribly difficult, as I've learned from working on my own disassembler. |
HabsoluteFate
Posts: 83/179 |
Originally posted by Evil Peer although because it will have to "emulate" while it disasembles its going to be slower at doing it than other dissasemblers....
I am afraid there is no feasible way to do this. Even during full emulation, not all code will be executed in any given playthrough. Your real nemesis here is the code routine pointer table.
---Evil Peer
I'll be using recursion as i mark things as code (default will be that something is data).... for example if i have a conditional jump that i encounter i will follow the jump no matter what if i havent gone to that sub routine yet (if something is already marked as code then i have already gone to it and know that i dont need to jump to it)...i also take note of wether we're in 8 or 16 bit register modes for all code locations to help the back trace... I have had this working in my java version before...the only thing i was missing was indirect pointers to routine locations (which i'm assuming is what you are referring to when you mention the code routine pointer table?)...i'm hopping that by emulation i can store all valid indirect sub routine locations |
MathOnNapkins
Posts: 1144/2189 |
Well good luck, I was thinking about attempting something of this sort, but I think it's far easier to use a trace log in most cases. Then fill in the holes. I think you'll definitely run into some issues once you sit down and seriously think about it. --- if I understand what you are attempting. But good luck anyways.
|
Geiger
Posts: 198/460 |
although because it will have to "emulate" while it disasembles its going to be slower at doing it than other dissasemblers....
I am afraid there is no feasible way to do this. Even during full emulation, not all code will be executed in any given playthrough. Your real nemesis here is the code routine pointer table.
---Evil Peer |
HabsoluteFate
Posts: 81/179 |
Originally posted by Evil Peer Does anyone know of a SNES Assembler/Dissasembler combination that works?
Well, my favored SNES disassembler is Dispel, but I know nothing about assemblers.
---Evil Peer
Thanks...! doesn't do everything i need it to but it seems to work out better than y0shi's Looks like i'll probably have to write my own dissasembler like i was going to....i have some experience already with jSmwDev although that was written in Java...this one will be in C++ and will seperate data from code...although because it will have to "emulate" while it disasembles its going to be slower at doing it than other dissasemblers.... check out the SMW thread on "jSmwDev" for more detail...although the dev environment i'm making is specific to SMW the disassembler should end up generic enough to work with any SNES games
|
Geiger
Posts: 196/460 |
Does anyone know of a SNES Assembler/Dissasembler combination that works?
Well, my favored SNES disassembler is Dispel, but I know nothing about assemblers.
---Evil Peer |
HabsoluteFate
Posts: 80/179 |
Hi all, Does anyone know of a SNES Assembler/Dissasembler combination that works? For an example using the dissasembler a .asm file is created I can then take this .asm file and assemble it the newly assembled file is still valid and plays in an emulator.
Something preferrably with source code...If there is no such thing i'll probably have to write the dissasembler but I'm hopping I wont...
I know there is Tracer by y0shi but i haven't found an assembler that succesfully recompiles it
Thanks! |