It is currently Sun Jul 22, 2018 11:48 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Sun Dec 18, 2016 1:15 pm 
Offline

Joined: Sun Dec 18, 2016 1:11 pm
Posts: 23
I want to disassemble an SNES game. I understand the basics of ASM. Thing is, this game hasn't ever been fully disassembled and commented unfortunately. All I'd like to do is understand what's going on behind the scenes when certain things happen in the game. What I'm looking for is a way to view what code is running, I just want to find, for example, where the code for when the player jumps is, so I can try and figure things out from there. Said game has a RAM detailed map include the addresses for the player's current state, his velocities etc., not sure if that would be helpful for this purpose or not, though, since that's a RAM map not a ROM map. Where should I start?


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 1:22 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20286
Location: NE Indiana, USA (NTSC)
If you have a RAM map, set write breakpoints on relevant addresses. That'll lead you to the vicinity of the code that updates those areas.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 1:28 pm 
Offline

Joined: Sun Dec 18, 2016 1:11 pm
Posts: 23
Right... what programs should I be using to do this? I haven't actually "gotten started" yet. Right now all I have is the rom and snes9x-rr with a lua script that shows me the values but that's it. No idea how to actually properly decompile and use said code to set breakpoints or anything.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 2:05 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
There's lots of ways to go about it. What worked for me was using Bizhawk, a bsnes-based emulator used mostly by people in the TAS community. It allows you to view and search RAM as well as trace logs. When I was trying to find particular bits of code myself that way, I'd usually start with a RAM search to find a value doing what I'd expect (increasing/decreasing/staying the same), then try messing with it to see what happens. When you find the right one you can search for that address in the trace of a frame or two.

That's what worked for me anyway


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 2:24 pm 
Offline

Joined: Sun Dec 18, 2016 1:11 pm
Posts: 23
So you're saying Bizhawk disassembles the entire game while it's emulating or what? Since I want to see the actual disassembled asm not just what values are changing.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 3:29 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20286
Location: NE Indiana, USA (NTSC)
Several debugging emulators disassemble the immediate area around the program counter whenever they hit a breakpoint.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 3:42 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
ittyBittyByte wrote:
So you're saying Bizhawk disassembles the entire game while it's emulating or what? Since I want to see the actual disassembled asm not just what values are changing.

If it has a CDL option, it can. The more you play, the more the CDL file gets updated, the more you know exactly which memory address is the start of an opcode.

_________________
__________________________
http://pcedev.wordpress.com


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 5:04 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
ittyBittyByte wrote:
So you're saying Bizhawk disassembles the entire game while it's emulating or what? Since I want to see the actual disassembled asm not just what values are changing.

SNES disassembly can be difficult... I tried running a rom through a disassembler but unlike NES a disassembler doesn't necessarily know which register size you're using at the time, and so trying to guess which length of instruction can be almost impossible, throwing off the interpretation of the whole thing.

The trace logs are where I spent most of my time. It shows you a full printout of everything the processor does in a frame, so you can search for the parts you're interested in if you know some key addresses and watch what it does. It'll also tell you the location in ROM the program that's running is at, so you can dig through the ROM file and read that directly too.

That's the best I got, really. I only halfway took apart one game, I haven't fully mapped one or anything.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 5:43 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3349
Location: Nacogdoches, Texas
Khaz wrote:
I only halfway took apart one game

Might I ask what game? Oh, and I'm glad you're back, from wherever. :) We definitely don't need any SNES developers leaving... :lol:


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 5:59 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
Dragon View for SNES, when I was working on TASing it. Taking that game apart taught me a lot. Sorry I haven't been active, just got stalled on my game for the last year or so. Trying to get back into it.


Top
 Profile  
 
PostPosted: Thu Mar 29, 2018 8:20 pm 
Offline

Joined: Thu Mar 29, 2018 8:05 pm
Posts: 2
Might be an old thread, but I need some help. What's the next step?

Background info:
I have a minimal knowledge of programming (a little C++, and it was the Assembly class that weeded me out of the CIS major at my college). I do remember a little bit (not much) about pointers and watched a few videos as a means of refreshing myself. I understood most of it, but not all of it. And none of the videos showed very much of what I want to do.

I read all the posts in this thread and downloaded most of the programs mentioned.

Have been playing with BizHawk, and did as much of the CDL as I could with the SNES game I want to disassemble. However, I need to know what to do next with the CDL file.
How does RAM maps and tracing fit into all this?
What program do I need to use next to take it from the CDL file to a usable (plan text) assembly language file?

If this ends up being a manageable effort, I'm might do it for a few more games I used to play.

Thanks guys!


Top
 Profile  
 
PostPosted: Thu Mar 29, 2018 10:20 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 478
Okay the SNES is complicated, and the 65816 is really complicated, well it can be or it can be straightforward, if you don't have a deep understanding, I mean you know what a Program Bank and Data Bank are, how LoROM/HiROM and address lines work, understand what PEA does how things change with REP/SEP etc ... forget the SNES for now. You need to work your way up to it..

Go to http://csdb.dk/release/?id=149429 and get Regenerator it makes life a lot easier, then either choose a really simple NES game, no bank switching or choose a Commodore 64 prg ( lots of them on the site, don't choose a demo they are hard core coding tricks to the max ) and start to get a feel for 6502 and how ASM works. Once you have mastered the 6502, then learn the extra complexities of a 65816 and a SNES.


Top
 Profile  
 
PostPosted: Fri Mar 30, 2018 1:14 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 118
I always recommend this video as a reference to the 6502.


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 6:49 pm 
Offline

Joined: Thu Mar 29, 2018 8:05 pm
Posts: 2
Ok. I'll get started! Thanks for the pointers guys!

Do you have a particular game in mind as a suggestion for a simple game to start on?

Cheers!


Top
 Profile  
 
PostPosted: Mon Apr 02, 2018 8:18 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3435
Location: Mountain View, CA
I'd suggest any of the first-gen games that are either 4mbit (512KByte), don't use expansion chips (DSP, etc.), and don't use "complicated features" if at all possible (the latter is highly subjective, not worth debating). I might suggest Super Buster Bros, although Super Mario World and Gradius 3 fall into the former category (though IMO SMW is probably too much considering it's complexity). Final Fantasy Mystic Quest also does. To expand the possibilities, you might consider 8mbit (1024KByte) games as well. Try to stick to first-gen though, as many are "early efforts" with general-purpose code vs. heavily optimised "we've had 4 years to do this" type of code.

Understand that the learning curve is going to be extremely steep if you've never done this before. You're going to feel overwhelmed very quickly. You're literally reverse-engineering something developed at commercial companies which took **years** for 10-15 people to complete as a team. If you aren't familiar with 65816 assembly (or even assembly in general), then you're going to be trying to learn a CPU architecture *and* a system architecture at the same time as figuring out someone else's code. Just be aware of what you're in for.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group