Acmlm's Board - I2 Archive - Rom Hacking - ASM Hacking Question - Controller Presses
| User | Post |
Rockman
Posts: 179/250 |
I didn't post the address because I didn't remember it at the time. All it takes is a simple cheat search to find it. And I already told you the value to search for. Its 4. In fact, you don't even need to look for it. Just changing that $18 to a $16 will suffice. There are multiple ways to do things. This is a very simple way, which happens to work. Just change that one byte for rapid fire.
And no HyperHacker, I shouldn't at least post the addresses. If you don't know how to test cheat addresses even after I gave you the value to search for, then this isn't for you. If you need documentation on how to use FCEUD, read this:
http://desnet.fobby.net/doc/fceud_tutor1.txt |
HyperLamer
Posts: 4160/8210 |
You should at least post the addresses.  |
Rockman
Posts: 178/250 |
Well, I managed to do it!
You can't really tell from the screenshot, but Mega Man can now rapid fire. I was actually able to do it in a lot simpler way than I thought. It just hit me!
It was so simple to do, that its not worthy of a patch. Here's how to do it:
- Set a Breakpoint of Read to Address $18.
- Press run 17 times to get to the LDA $18 and AND #02.
- What you want to do, is change that $18 to a $16.
Basically, changing that allows you to hold down the button to fire rapidly. Then, all that is left to do is change how many bullets come out of your cannon.
Do a Cheat Search for the hex value, 04. The value is at the bottom of the list (don't remember which one). You can figure out the rest. 
The only thing I didn't get to yet, is being able to rapid fire while you are on a ladder. I'll do that later.
But anyway, I really appreciate your help Disch. I would buy you dinner if I could. |
Dish
Posts: 333/596 |
Originally posted by Rockman
I need help with something.
BEQ means Branch on Result Zero.
Does this mean to branch to that location if the result is false?
Technically... all it means is "Branch if the Z flag is set". How the Z flag is set depends on the previous instruction(s). Typically, the Z flag is set when the last instruction resulted in an output of Zero (and is cleared otherwise). For example:
LDA #$00 ; this will set the Z flag
LDA #$01 ; this will clear it (nonzero)
SEC
SBC #$01 ; This will subtract 1 from A, making it zero -- so the Z flag will be set
LDA #$0E
CMP #$0E ; CMP internally does subtraction to set flags. 0E - 0E = 0, so Z will be set
CMP #$0D ; However, 0E - 0D = 1, so Z will be clear here
BNE is the inverse -- all it means is "Branch if Z flag is clear".
edit:
To further clarify your bolded section:
$9538:A5 18 LDA $18 = #$00
$953A:29 02 AND #$02
$953C:F0 05 BEQ $9543
That BEQ will branch... since the previous instruction (AND) will produce a result of zero, setting the Z flag. If $18 had the B button pressed ($02), the AND would produce a nonzero result, clearing the Z flag -- and the branch would not occur. |
Rockman
Posts: 177/250 |
I need help with something.
BEQ means Branch on Result Zero.
Does this mean to branch to that location if the result is false?
If that is true, then BNE means Branch if Result is Not Zero, meaning, branch if result is true?
Right now, I'm trying to make an ASM hack to Mega Man.
What I'm trying to do is make it so if you hold down the fire button, Mega Man can rapid fire. I actually wanted to do this a very long time ago, but couldn't because of lack of knowledge. Now, I feel ready enough to tackle it.
The address for buttons that are just pressed is $18, just like it is in SMB3.
So, I set a read of $18, and press Run 17 times to get to the code I'm looking for.
$9538:A5 18 LDA $18 = #$00
$953A:29 02 AND #$02
$953C:F0 05 BEQ $9543
$953E:20 1E A7 JSR $A71E
$9541: D0 00 BNE $9543
$9543:AD 80 06 LDA $0680 = #$FF
$9546:30 29 BMI $9571
$9548:20 C4 9B JSR $9BC4
$954B:B0 09 BCS $9556
$954D:A5 14 LDA $14 = #$00
$954F:29 01 AND #$01
$9551:F0 06 BEQ $9559
$9553:4C 29 96 JMP $9629
$9556:4C 33 96 JMP $9633
$9559:AD 80 06 LDA $0680 = #$FF
$955C:30 10 BMI $956E
$955E:C9 01 CMP #$01
$9560:90 0C BCC $956E
$9562:F0 0A BEQ $956E
$9564:A9 01 LDA #$01
$9566:8D 80 06 STA $0680 = #$FF
The fire button, which I'm pretty sure is the B Button, is #$02, which is shown above. First, I want to work with the JUST PRESSED button ($18), before I go into the HELD DOWN button ($16). But, I need help. I don't know where the code for firing the bullets are. I highlighted the beginning of the code. Could somebody explain what that BEQ does? |
Gavin
Posts: 618/799 |
Originally posted by iamhiro1112
My questions weren't neccesarily a do it for me question. But I was curious if anyone had wanted to fix those problems. I am currently hacking the graphics part of Super Mario World NES and was hoping to see this games many issues resolved. But I am perfectly willing to try and tackle the issue myself. I don't have the knowledge to do it yet, but I'm sure theres enough faqs out there for me to learn.
Anyway, I'll try to keep on topic from now on.
my most recent comment just above this one applies equally to your question, iamhiro.
the moral of the story is that with any game hacking on the level of assembler, it's generally a very good idea to have a more intiment understanding of the game you're working on.
so really it depends on what the game's controller processes look like. as DD and Parastye and whomever else has said, you'll want to be using the game's built in controller functions. Start by locating where and how the game stores button status info, then look for reads to that ram address using an advanced debugger (such as FCEUXD) and go from there. |
iamhiro1112
Posts: 365/487 |
My questions weren't neccesarily a do it for me question. But I was curious if anyone had wanted to fix those problems. I am currently hacking the graphics part of Super Mario World NES and was hoping to see this games many issues resolved. But I am perfectly willing to try and tackle the issue myself. I don't have the knowledge to do it yet, but I'm sure theres enough faqs out there for me to learn.
Anyway, I'll try to keep on topic from now on. |
Gavin
Posts: 617/799 |
if you are asking if it is possible to analyze and alter the game's controller handling code in the assembler programming language, then yes. however you must understand that video games are created just like any other piece of software, just because it's an NES game doesn't automatically mean there is some sort of "NES template" that the games are created out of or that all games developed uesd a uniform developement library.
there are certain predictable elements, however. if a game wants to work with a controller (as in like every game created for the NES) and it wants to use all buttons on the controller, there will be 8 reads to $4016, and the controller hardware will be initialized (all that "half-strobe" nonesense aside). Though how a game goes about that differ. There can be, as in the case of FF1, a decrementing loop that rotates each button status bit into a single memory address. It didn't have to do that though. The game could have loaded each button status bit manually, with 8 reads to $4016, it could have stored the button status bits into 8 separate memory addresses.... get the point? there are many many ways to handle the same operation, it depends on what the game needs and whatever the programming felt like doing at the time, and that can vary. and just as the actual reading and storing of the information can vary, obviously the handling of button presses can be different depending on what the game needs. if it needs to know if the current button was also the previous button pressed, blah blahblah, it's going to have different routines and therefore you're going to have to hack the game differenty.
the moral of the story is that with any game hacking on the level of assembler, it's generally a very good idea to have a more intiment understanding of the game you're working on. |
Dish
Posts: 330/596 |
Originally posted by eb_h4x0r
Is it possible to ASM hack other games for the controller thing?
Umm... what are you talking about? |
eb_h4x0r
Posts: 4/12 |
Is it possible to ASM hack other games for the controller thing? |
bbitmaster
Posts: 75/103 |
Originally posted by iamhiro1112
Here's a question. Would it be possible to fix up the control in Super Mario World NES at all? One of the games biggest flaws is that a running jump goes the same length, height and speed as a walking jump. It kind of kills the flow of the gameplay. The run speed needs to be brought down a notch too cause you usually wind up running into enemies if you try to run. Also the cape has no float functions which it should.
It's been my personal experience that anytime someone asks "is x possible?," what they really want is someone to do it for them. I sure hope you aren't trying to ask someone to do such a big hack for you, because anyone with enough skill probably has their own projects to be working on.
In any case, this is a very bad question to ask, anything (within reason) is possible if you have enough time and effort to put into it. Do you? If so, messing with the game in FCEUXD, and reading this thread are good starting points.
All I can say is good luck!
|
DahrkDaiz
Posts: 594/885 |
iamhiro: your post has NOTHING to do with the topic of this conversation, and is thus, deemed off topic. Controller press routines and the physics of SMW NES have very little to do with each other. Others who frequent this forum agree that you seemed to make off topic comments and posts like this all the time.
Please remain on topic or say nothing at all, you have been warned. |
iamhiro1112
Posts: 361/487 |
Here's a question. Would it be possible to fix up the control in Super Mario World NES at all? One of the games biggest flaws is that a running jump goes the same length, height and speed as a walking jump. It kind of kills the flow of the gameplay. The run speed needs to be brought down a notch too cause you usually wind up running into enemies if you try to run. Also the cape has no float functions which it should. |
KP9000
Posts: 202/261 |
I believe it needs to be within the same bank... I'm probably not correct but I know its something along those lines. I'm in the process of learning ASM right now and I'm just taking a wild shot at it.
Anyways, that is looking pretty cool Rockman! You should make a tutorial on this also! |
Rockman
Posts: 170/250 |
You were right Disch. Thanks. My Branch wasn't correct, and the code section with the NOPs was the pause screen. I noticed that in the RAM viewer, pressing the start button shows up as 10, and the code shown there was AND #$10, meaning that pressing start executed the code for the pause. So, I now know what I was doing wrong, however, even with the proper code I have, I couldn't find free space within the limits to put the code, so I had to go over the Pause routine.
I'll have to figure out where to find some free space to my new code tomorrow. There is lots of free space in the ROM, but it has to be within that area, or it won't work. I have tried many times.
So, I managed to do what I wanted to do, initially as practice.
Press select...
And Tanooki Mario you become!
http://www.geocities.com/heavencloud7777/smb3.zip
I even made a patch if anyone wants to try it out. Remember, until I figure out how to do it a better way, you can't pause in the game. But the ASM hack works perfectly fine.
You need to right click and select save target as if you want to download it. |
Dish
Posts: 329/596 |
[edit]
My previous theory seems to have been wrong -- I'm looking at the area you're talking about now it does only seem to be called once per frame.
[edit again]
your branch is screwey -- that might be part of your problem
BEQ $00 <-- is a null branch. It will not branch anywhere regardless of the state of the Z flag (although it will burn extra cycles depending on the Z flag). If you're wanting to skip the following instruction, you'd want:
BEQ $03 (skip 3 bytes -- the following INC is 3 bytes long)
[edit a 3rd time]
I put in your same code at the start of the NOP chunks I think you were talking about ($3CE8E in the (PRG 0) rom) -- with the corrected BEQ command. And it seems to *kind of* be working.
It seems like that NOP chunk is only run when the game is paused -- so it will only add lives when you press select while the game is paused. That's how it worked for me. One life per press -- but the life count in the status bar didn't change until you unpause. |
Rockman
Posts: 169/250 |
Okay, now I'm having a little bit of trouble. I'm trying to write my own code for SMB3, so when you press the select button, it increases your lives by one. This, I'm doing for practice.
What I'm doing, setting a breakpoint of read, to $18. Then, I press run to get to the section that has the NOP'd out code. That is where I'm putting my code.
A5 18
29 20
F0 00
EE 36 07
Those are the bytes above.
The actual code:
LDA $18
AND #$20
BEQ [next line]
INC $736
I looked at the RAM in the memory viewer. When you press select, the number 20 comes up. Meaning, that the number 20 means select.
So, I looked at code I saw for the jump button, and I tried to write my own. But its not working correctly.
Instead of select, it increase the lives by about 20 when you press the Start button. Its weird. |
Gavin
Posts: 614/799 |
Originally posted by Disch
FF1's method is actually roundabout and wasteful (AND + CMP is silly -- a simple LSR would be much easier and more effective). Something like this makes more sense to me (probably is in more games):
LDX #$01
STX $4016
DEX
STX $4016 ; strobe joypad
LDX #$08
loop:
LDA $4016 ; get button state (p1)
LSR A ; move low bit to carry flag
ROR joy_data_p1 ; roll carry flag into memory
LDA $4017 ;get button state (p2)
LSR A ; move low bit to C flag
ROR joy_data_p2 ; roll C into mem
DEX
BNE loop ;loop 8 times
ah yes, correct you are. I think i remember you alerting me to this fact way back when i was messing with controller stuff and working with FF1. I had typed up that small ff1 controller workings a while ago and only changed it grammatically and organizationally really. you're method is much much better. and as an aside: i'm not saying it's best to write you're own controller handling routines for an existing game (because as everyone has pointed out, it's pointless and overly-complicated), just showing one way one game handles it, so someone might have a better understanding of it  |
Rockman
Posts: 165/250 |
Originally posted by BMF54123
Friggin' awesome, Gav! I never could figure out exactly how that code worked...for some reason, the whole concept of ROL and the Carry bit went completely over my head. It looked to me like it was constantly rotating the same byte over and over again, and the flags just "magically" appeared there. I feel really stupid now. 
I felt a little stupid yesterday too, after I found out that it wasn't really that hard to begin with, and I can't believe that I didn't pick it up before.  |
Dish
Posts: 328/596 |
FF1's method is actually roundabout and wasteful (AND + CMP is silly -- a simple LSR would be much easier and more effective). Something like this makes more sense to me (probably is in more games):
LDX #$01
STX $4016
DEX
STX $4016 ; strobe joypad
LDX #$08
loop:
LDA $4016 ; get button state (p1)
LSR A ; move low bit to carry flag
ROR joy_data_p1 ; roll carry flag into memory
LDA $4017 ;get button state (p2)
LSR A ; move low bit to C flag
ROR joy_data_p2 ; roll C into mem
DEX
BNE loop ;loop 8 times
Originally posted by DahrkDaiz
As far as a I know, NES only has the 2 registers which you must strobe. Though I rememeber reading something about a "half" strobe, but I never did read any more information on what that exactly did or the results of doing it.
I heard from somewhere (can't remember where -- and I doubt it's accurate) that reading $4016/7 on a half strobe (writing 1 but not 0) will access the Famicom expansion port rather than joypad data. Although I find that to be rather unlikely. I'd imagine reading either reg on an incomplete strobe would just give you garbage joypad data.
Other terminology I've seen thrown around is writing 1 is called "resetting the strobe", and writing 0 is called "clearing the strobe". To me this would imply that writing 1 make it so the next button read will be the A button. And that writing 0 would clear out current joy data and fetch new data from the gamepad. So I'd guess that if you did something like the following:
LDX #$01
STX $4016
LDA $4016
STX $4016
LDA $4016
I'd think you'd just get the status of the A button over and over every time you read -- and it would never change (it would never refresh with whatever's currently being pressed, since you're never clearing the strobe). This is all a complete guess though -- I really don't know.
edit:
but, erm, yeah. As Para and others have mentioned -- you shouldnt' be doing this. If the game is already strobing and fetching joypad data (which it IS) you shouldn't - since that is unnecessary work and could even cause problems. DD already posted those offsets to where key state is stored in RAM. |
| This is a long thread. Click here to view it. |
|
hukka
