Points of Required Attention™
Smaghetti, a new Super Mario Advance 4 editor, is currently in development! Check out the thread HERE!

Please chime in on a proposed restructuring of the ROM hacking sections.
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
Posted on 08-24-09 08:59 PM Link | Quote | ID: 114058

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
Posted on 08-24-09 10:03 PM (rev. 2 of 08-24-09 10:06 PM) Link | Quote | ID: 114060


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
Posted on 08-25-09 12:38 AM Link | Quote | ID: 114065


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
Posted on 08-25-09 03:14 AM Link | Quote | ID: 114069

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
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..


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
Posted on 08-25-09 03:38 AM Link | Quote | ID: 114070


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
Posted on 08-25-09 09:19 PM Link | Quote | ID: 114117

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
Posted on 08-25-09 09:33 PM (rev. 5 of 08-25-09 09:43 PM) Link | Quote | ID: 114120


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
Posted on 08-25-09 09:40 PM Link | Quote | ID: 114123


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
Posted on 08-27-09 05:04 AM Link | Quote | ID: 114179


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
Posted on 08-29-09 03:12 AM Link | Quote | ID: 114231

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
Posted on 08-29-09 04:45 AM Link | Quote | ID: 114233


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
Posted on 09-07-09 04:47 AM Link | Quote | ID: 114622

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
Posted on 09-07-09 04:59 AM Link | Quote | ID: 114624

>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
People here brag about the FAQ, and it says no links to ROMs, doesn't mean no site names...
Posted by "The FAQ"
DO:
  • Exercise common sense when posting.


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.

</offtopic>


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
Posted on 09-08-09 12:32 AM (rev. 3 of 09-08-09 12:53 AM) Link | Quote | ID: 114682

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
Posted on 09-08-09 08:25 PM Link | Quote | ID: 114706

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
Posted on 10-17-09 02:33 AM Link | Quote | ID: 117367

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
Posted on 10-17-09 02:50 AM Link | Quote | ID: 117368


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
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?


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

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.028 seconds. (340KB of memory used)
MySQL - queries: 109, rows: 146/147, time: 0.018 seconds.