| |||
Views: 88,312,626 |
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search | 03-28-24 09:55 AM |
|
Guest: Register | Login |
0 users currently in ROM Hacking | 2 guests | 1 bot |
Main - ROM Hacking - Help with hacking/disassembling the NES Mega Man games | New thread | New reply |
jagfillit |
| ||
Newcomer Level: 7 Posts: 1/6 EXP: 1073 Next: 375 Since: 08-15-09 Last post: 5276 days Last view: 5156 days |
I've asked a few places but found nothing, hopefully you guys can help...
I've started messing around with the Mega Man games, specifically 4. I have a moderate knowledge of ASM (in general, not 6502 specifically) but am having trouble getting started with ASM-hacking the game. Whenever I try to disassemble the game via a program, it produces numerous errors, primarily due to the fact they can't read tables in the game's ASM. Is there a program that can correctly disassemble the Mega Man games, or even better yet, a preexisting disassembly I can work with? |
Insectduel |
| ||
Hammer Brother Level: 68 Posts: 381/1069 EXP: 2681170 Next: 47630 Since: 02-16-08 From: Insectduel's office Last post: 1228 days Last view: 1227 days |
Hello and welcome to the world of insanity where all the questions can be answered. Basically, the FCE Ultra X Emulator at Zophar's Domain has lots of Debugging features, it's own hex editor, Trace Logger, Code/Data logger etc. It's much more better than those basic disassembly or corruption programs you're using.
Some NES Mega Man games already covered some disassembly data. Check Datacrystal or Rom Haacking Dot Net to get these documents. Good luck! EDIT: I noticed that you say that you specify Mega Man IV. Well, these 2 sites are very helpful. |
Kiokuffiib11 |
| ||
Porcupo Level: 40 Posts: 36/313 EXP: 405963 Next: 35346 Since: 07-10-09 From: Marquette, Michigan Last post: 3283 days Last view: 1906 days |
If you're looking for a program that can SHOW the disassembly of a game, Look for "sadasm 1b". Google it up, it should be the first on the list.
____________________ セシル |
jagfillit |
| ||
Newcomer Level: 7 Posts: 2/6 EXP: 1073 Next: 375 Since: 08-15-09 Last post: 5276 days Last view: 5156 days |
Posted by Insectduel Actually, FCE Ultra has the same issue I'm having with the other programs. It can't read tables, so it'll spit out long strings of DEX, DEY, CMP and other opcodes that make no sense in context. I'm not sure if that's a problem with all disassemblers though (if it is, I'll feel rather stupid for asking around). In the case that it is, does anyone have any tips on figure out what's part of a table? I know illegal opcodes and nonsense routines are hints but I can't be sure what ends and starts where. |
Trax |
| ||
Yellow Stalfos Level: 71 Posts: 894/1145 EXP: 3028618 Next: 138496 Since: 07-06-07 From: Québec Last post: 3598 days Last view: 2850 days |
Loch NES can disassemble NES code, and stop at the condition you provide. If you want to differentiate between tables and code, you have to analyze the code itself and look for adresses that are used to load a byte. If you end up with nonsense code after a RTS or a JMP, it's probably a data table. If you can find the highest value possible that can point into this table, you will most likely see a chunk of code again, and so on... |
jagfillit |
| ||
Newcomer Level: 7 Posts: 3/6 EXP: 1073 Next: 375 Since: 08-15-09 Last post: 5276 days Last view: 5156 days |
The thing about that is if a table is read as code, the whole disassembly would most likely be wrong from then on. Like if there's a line 20 A9 15, where 20 is part of a table, it would be LDA #$15, but disassembler would spit out JSR $15A9. I have no way of knowing where I can start or if it's correct.
I'd need some way of knowing what's what before even starting. |
never-obsolete |
| ||
Rat Level: 24 Posts: 54/96 EXP: 74323 Next: 3802 Since: 02-22-07 From: Phoenix, AZ Last post: 2567 days Last view: 2567 days |
Play the entire game with the code/data logger running. You'll still need to go over it by hand since it'll be difficult to make sure every possible branch is taken, data is read, etc...
I'm not sure if there are dissassmblers that'll use the *.cdl file. I tried writing one awhile back, but it was only useful for NROM and mappers that use 32K banks. Even then it would still mess up on games that run code from ram. |
Trax |
| ||
Yellow Stalfos Level: 71 Posts: 895/1145 EXP: 3028618 Next: 138496 Since: 07-06-07 From: Québec Last post: 3598 days Last view: 2850 days |
That's why you must work on knowing how the ROM works. At some point, you get to know how to deduce the tables boundaries. If you look in the chunk of data preceding the table with 20 A9 15, you will eventually find a branch to the address of A9. Of course, it's not always crystal clear, but usually, if you can't find any JSR, JMP, BEQ, etc., for that address, it means it's part of something else, in occurrence, a data table...
Your example would be discarded as a JSR anyways, since it would yield JSR $15A9, which doesn't make sense, since code must be located in CPU RAM range of 8000-FFFF. Or possibly in the SRAM range, which is 6000-7FFF... If you can't find the table's length, then forget it for now, and explore another place. You will return to it eventually. There are also pointer tables, which are fairly easy to discern, visually. If you see an alternance of bytes in the 80-FF range, with other bytes, usually increasing, then you most likely have a pointer table. And they can hardly be confused with code... |
DarkPhoenix |
| ||
Micro-Goomba Level: 12 Posts: 16/19 EXP: 6496 Next: 1425 Since: 05-24-07 Last post: 5271 days Last view: 5258 days |
You have to disassemble in sections - you figure out where the code starts, and where it ends, and then disassemble that section.
The only tools that I know of that do branch following and whatnot to avoid incorrectly disassembling data are expensive commercial tools, and even with those tools, you won't uncover all of the code without some degree of work. As you said, you need to know what's what before you start: While you play the game, check for changes in memory after certain actions (the same way you find cheat codes - or alternatively, just look up some addresses other people have found). Then, run through again with a debugger running, placing a breakpoint when that memory is modified to find the instruction that modifies it - Then disassemble around that instruction. It's limited, but this way you can find the instructions relevant to what you want to change quickly, without digging through a lot of unrelated code. |
bbitmaster |
| ||
Newcomer Level: 5 Posts: 1/3 EXP: 379 Next: 150 Since: 08-29-09 Last post: 5300 days Last view: 5314 days |
Consider yourself in luck.. well almost, I don't have Mega Man 4.
I've pretty much been out of the hacking community for several years now. I only ever look at this forum once every few months if ever, but I just happened to come by and see this request. Basically, back when I designed FCEUXD's code/data logger (in 2004 no less), my whole dream for it was to create a program that would produce a nice formatted re-assembleable disassembly with code and data separated. I actually ended up creating a semi-working disassembler that did this. It was way too buggy and messy to ever share, but I got it to output a good disassembly for one game. That game was megaman 3. At around the same time, a fellow named _hyde_ was coding his own emulator with similar logging capabilities, and a similar disassembler. He produced assemblies for about a dozen games... of those megaman 1 and 2 were included. So basically, I have disassemblies of Megaman 1, 2, and 3. They should all re-assemble with CA65. The megaman 1, 2 disassemblies were done by _Hyde_, and the megaman 3 one was done by me. I would post them here, but I'm unsure of the rules on this forum. Since, Technically you can create a 100% complete original working rom with them. So instead, I'll opt to send it to anyone who asks either via e-mail or PM. ( my e-mail is bbitmaster@gmail.com ). I usually hang out in #rom-hacking on irc.esper.net if anyone wants to come and talk about any of this. jagfillit, check your pm, I am about to send you links. bbitmaster |
zbyte |
| ||
Boomerang Brother Z is Superior! Level: 66 Posts: 242/1016 EXP: 2380770 Next: 81081 Since: 06-10-09 Last post: 4403 days Last view: 2882 days |
¤ I have used your hex and your code logger. When I wanted to look for SMB3 music stuff, this person told me to use the code logger to find it, and I did, but I wasn't sure which part of the blue was the world's music header I was looking for...
This is the Mega-Man thread though... People here brag about the FAQ, and it says no links to ROMs, doesn't mean no site names... ____________________ No quotes found; we apologize for the inconvenience. Commas, question marks, and semicolons are available, though. |
jagfillit |
| ||
Newcomer Level: 7 Posts: 4/6 EXP: 1073 Next: 375 Since: 08-15-09 Last post: 5276 days Last view: 5156 days |
Okay, using the help I got, I was able to get most of the data I need. However, there's one thing in specific I need help with. Mega Man's jump height. I've been unable to find how this is handled.
My goal is to make a perfect (or as close to it) port of the NES Mega Man engine(s), so I'm trying to figure out the original math used behind all possible jump heights. I've recorded and looked at screenshots, but I can only get so much out of this. If anyone can help me in any way, I'd be grateful. |
GreyMaria |
| ||
>implying even the Japanese understand the Japanese Level: 105 Posts: 1440/2851 EXP: 11892589 Next: 369671 Since: 07-13-07 Last post: 4468 days Last view: 4438 days |
Posted by zbyte Posted by "The FAQ" Directly mentioning the site name is one step away from giving a link to a ROM in public (PMs are fine). Common sense tells us this. If you're going to talk about the FAQ, at least make sure you know it first. < Also, to the OP, good luck with the project. We always like to see ambitious hackers succeed. ____________________ we're currently experiencing some technical difficulties |
bbitmaster |
| ||
Newcomer Level: 5 Posts: 2/3 EXP: 379 Next: 150 Since: 08-29-09 Last post: 5300 days Last view: 5314 days |
well, if you're trying to simulate the physics, I might as well give a really formal discussion of how this is handled in megaman 3.
All of the megaman games use a form of fixed point arithmetic to store all of the numbers. Basically one byte tells the whole number, and another byte tells the fraction. This gives a 8.8 fixed point precision. So, if you have the number $0180 the whole number part would be $01 while the fraction part would be $80 so this would be 1.5 The whole number part tells the pixel location. So basically, this allows for things to move at fractional velocities. lets say I am at position $0000 moving at a velocity of $0040 on each frame. My position would go like Frame 0: $0000 Frame 1: $0040 Frame 2: $0080 Frame 3: $00C0 Frame 4: $0100 Frame 5: $0140 Frame 6: $0180 Frame 7: $01C0 Frame 8: $0200 so basically with this velocity you will move 1 pixel every 4 frames. These numbers also have a sign bit according to 2's complement so $0180 = 1.5 but $ff80 = -0.5 $ff00 = -1, $fe00 = -2 etc... Anyway, now that that is out of the way... what the game does, is it has an 8.8 fixed point variable associated with megaman's position, and an 8.8 fixed point variable associated with his velocity. When you jump his velocity initially gets set to $04E5 via the below code (megaman 3): Note: the high byte of his velocity is in $0460 and the low byte is in $0440 $CEB3: A9 E5 LDA #$E5 $CEB5: 9D 40 04 STA $0440,X @ $0440 = #$E5 $CEB8: A9 04 LDA #$04 $CEBA: 9D 60 04 STA $0460,X @ $0460 = #$FF After this, gravity is simulated by subtracting $0040 from the velocity on each frame. The code to subtract is given below: $F7F2: BD 40 04 LDA $0440,X @ $0440 = #$A5 $F7F5: 38 SEC $F7F6: E5 99 SBC $99 = #$40 $F7F8: 9D 40 04 STA $0440,X @ $0440 = #$A5 $F7FB: BD 60 04 LDA $0460,X @ $0460 = #$04 $F7FE: E9 00 SBC #$00 $F800: 9D 60 04 STA $0460,X @ $0460 = #$04 As you can see from this code, the value $0040 is actually stored in ram at location $99. This is actually like a constant that is used for all objects in the game. If you change it, I am pretty certain that many enemies and things in the game will fall with a lower gravity. Anyway, so basically what happens is on each frame the velocity is added to the position, and $0040 is subtracted from the velocity. I could throw together an excel spreadsheet to show exactly how his position will change with all of this going on, and to show exactly how many pixels up he will go with a given initial velocity. But it basically makes the familar parabola that you see when he jumps and lands. (It's also a nice cheap way of simulating newtonian physics in discrete time) If you want to change the jump height, the best way is to change the value of the initial velocity boost. The $04e5 value. the $04 is in the rom at location $03cec9 the $e5 is in the rom at location $03cec4 changing these offsets in megaman 3 should let you change his jump height. Anyway, just thought I'd post this because SO MANY remakes and homebrew games get jump physics all wrong... EDIT: What the heck... here's a excel spreadsheet simulating one of these jumps. I used decimal values in excel. so $04e5 became 4 + 229/256 = 4.89453125. I got a maximum height of about 50 pixels. http://bbitmaster.com/misc/megaman3jump.xls -bbitmaster |
jagfillit |
| ||
Newcomer Level: 7 Posts: 5/6 EXP: 1073 Next: 375 Since: 08-15-09 Last post: 5276 days Last view: 5156 days |
Thanks so much. I was able to get everything I needed from that. |
jagfillit |
| ||
Newcomer Level: 7 Posts: 6/6 EXP: 1073 Next: 375 Since: 08-15-09 Last post: 5276 days Last view: 5156 days |
Sorry to gravedig, but I've got another issue, again with jumping. I've been combing through 3 and 4, but can't figure out how the game handles jumping while underwater. I think a completely different routine is used, as gravity is never changed. Does anyone know how this works? |
kuja killer |
| ||
Level: 55 Posts: 123/628 EXP: 1240985 Next: 73204 Since: 03-20-07 From: Lake Havasu City, Arizona Last post: 253 days Last view: 1 day |
Posted by jagfillit For 3, yup. Thing is, water still uses the same jump power setting as you normally would jump in air. It's like 4.xx or something. What it does is it sets $B9 to 03, and like the jumping/gravity type routines check for that B9, and it won't ever modify megaman's Y position as long as that register is non-zero. It just counts down. 03 02 01 00 -- make megaman move up/down, 03 02 01 00 -- make megaman move up/down, etc. So the lower the number, the less amount mm moves in water, the higher, the more. fiddle with $3D047, you'll see what i mean. and like do it on a screen that's entirly full of water, like the doc gemini man stage, or just quickly do a little edit on a level with the MegaFLE level editor for testing |
Main - ROM Hacking - Help with hacking/disassembling the NES Mega Man games | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
MySQL - queries: 109, rows: 146/147, time: 0.018 seconds. |