 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Zeld |
| Pages: 1 2 3 |
| User | Post | ||
Zeld Red Paragoomba                   Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| Assuming you know the opcodes, it should be a process of using a debugger to find which routine is the cause of what you want to change and simply changing the opcodes to suit your fancy. If the changes you want to make involve ADDING code, you'll have to put the code you're adding into some empty space (manually expanding the ROM to get this space if possible and necessary) and linking to it with a jump. Then you'll have to link back to where you came from with a return at the end of your code.
You'll have to use the stack or something similar (I don't know much about other assembly languages aside from ARM) to store the registers that you plan to overwrite with your script so that you can return them to their previous state and avoid an emulator crash. You'll need a program called an assembler to take opcodes and convert them to hexadecimal if you plan on writing long scripts that are too long to be assembled by hand but contiguous enough to be able to be assembled by an assembler with no allocation issues. I mean, you wouldn't want to make 27 separate files with one opcode each and assemble each opcode separately in cases where you must branch repeatedly. I think you would only have that problem with ARM7 Thumb, though, since that's the only processor I can think of that can't jump further than 4 megabytes at a time without using space-eating PC relative loads, which aren't handy for plug-in ASM coding (which is apparently what it's called when you link from a routine to your own and then back). I hope I didn't just post something completely inferior to the advice of someone more professional v_V |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
Originally posted by jonghyunchung Originally posted by Griff Morivan Griff isn't saying Kirby will just be able to float. He's saying that you will have to make him able to float by learning how to edit the game's programming. First, you would need to figure out what causes Mario to fall. I'm going to guess there's a falling bit. Finding the routine that tells this bit to be set and then telling it to only do so after a certain number of loops would work. You'd have to program your own variable by finding empty RAM space to use for the loop of how many jumps you have left before Kirby gets breathless. I think a timer would actually be more reflective of a Kirby game, though. In that case, you could hook your loop into the timer. LDA #Falling/jumping status byte offset - load the offset LDA A - load the actual byte LDX #Mask - this is a hex number that can be used for an AND operation AND accumulator and mask - mask the bit that would be set if you are in the air CMP Accumulator with #[value of being in the air] BNE #offset - if you aren't in the air, setting "offset" as the address of the rest of the timer opcode will resume the game LDA #Timer offset LDA A - otherwise, you can get the timer's current time and store it to a RAM address of your choice Then, you can use some other compares and stuff to check when a certain number of seconds have passed and have it take away your breath if you've been airborne too long, or to return your breath if you've landed. (Sorry if my crummy 6502 attempt is bad; I don't know 6502. I just wiki'd some opcodes and tried to throw something together. Notice how little I attempted to script...I was getting bored fast) Then you should probably alter the jumping speed so that he jumps more like an inflating balloon rather than simply hopping off of what would seem to be an invisible surface. You'll have to animate him bloating up for the full effect. I'm not sure what you would do about the little ball of air he exhales when he runs out of breath, and I definitely don't want to know how you would program the collision detection to make that ball of air lethal to enemies like in other Kirby games. It would even have to break bricks to be fully functional. What a pain. I could have sworn I saw somewhere that someone had made a hack for how high Mario can jump and maybe even how fast he falls. Whoever that is would be a big help for fleshing out this hack. Perhaps they have some notes they'd like to share *hint hint* |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| To stay true to Nintendo's own method of copyright information, it should be changed to "1985-2007". Not saying it's a must, but that's how Nintendo would display it.
"1985-2008" if you take too long  |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
Originally posted by Alice Which introduces a need for a form of limitation to the number of jumps you can do or how long you can repeatedly jump. There should also be a way to keep the player from jumping off the top of the screen, because a timer oriented limitation to how long you can jump would still allow players with fast thumbs to skip over everything. I thought that some way of making Kirby jump weaker as he nears the top of the screen might help too. Perhaps you can implement a Y position check when Kirby jumps that makes his jumping power inversely proportional to how high off the ground he is...and, of course, make it so he can't jump even just a pixel higher if he goes off screen. Perhaps this would handle my other suggestion of making his mid air jumps look more like Kirby's usual mid air jumps, rather than appearing to hop around on invisible surfaces. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
Originally posted by jonghyunchung Shouldn't he be bigger than that? He has an infinite supply of fire inside of him until he gets hit, so he wouldn't just deflate like that after each breath of fire. ... lol reference Originally posted by never-obsolete Forkin' nice (at least some people know 6502, eh?) Too bad all that nice effort you put into making my ideas into assembly won't help the guy if he doesn't know what to do with it :\ |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| The alternate is actually the standard...you can't pop LR in thumb mode.
You could use a load SP relative as an alternate...and decrement it yourself to emulate a full pop (it is decrement, right? I don't pay much attention to that). |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| A bit late for this, but I just thought of something neat:
Hector of Chad: Wait Hector of Chad: I've got it Hector of Chad: push {r0} Hector of Chad: mov r0, #0x[somebyte] Hector of Chad: lsl r0, r0, #0x[some shift amount] Hector of Chad: mov pc, r0 Hector of Chad: You'd only be able to go to a small handful of addresses Hector of Chad: but if you used it to jump to the end of the ROM Hector of Chad: and made a loop that determines where you branched from based on LR Hector of Chad: You could insert assembly hacks without losing registers and with minimum necessary space in the original routine to branch from So, like, push {r0} mov r0, #0x9 lsl r0, r0, #0x18 mov pc, r0 That takes you to the end of the ROM, preserves all registers, and only requires 4 instructions out of the original routine, which should be easy enough to find, right? The LR loop check is inefficient, but the preservation is nice. I haven't had any problems with any games I've changed that were caused by having too long of a custom sub routine. Any ideas of improvement? Edit: Arg, I forgot about the thumb bit. Well, that would cost an add r0, #0x1. Only one instruction...hopefully not going to be a problem 
Not like you can't just go there in ARM mode and switch back to thumb, to handle situations where you can't get in 5 replacement opcodes but can do 4. (edited by Zeld on 02-07-07 07:43 PM) (edited by Zeld on 02-07-07 07:45 PM) (edited by Zeld on 02-07-07 07:45 PM) (edited by Zeld on 02-07-07 07:46 PM) (edited by Zeld on 02-07-07 07:47 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| Wait, wouldn't that be a decrement? Or does it "increment" because of pipelining? :\
You can set a register to a range of 255 (not 256, because 0 would be useless) values with the mov function (and no, you can't shift while moving, because that is indeed an ARM only feature. Also, I haven't seen even ARM mode do that with an immediate value, but I don't see why it couldn't). That gives lots of nice ROM addresses to jump to...factor in the concept of different shift amounts, and that expands it even more. Yeah, I guess you might not have to use an LR loop. It's just, I don't want to have my assembly hacks spaced all over the expanded area of a ROM, because I'm working on expanding Fire Emblem 7, and there's lots of tables that will be going there. I'll have to place them accordingly with my assembly hacks in between with this new method, but I like it. 
For Fire Emblem 8, I already used a push {lr} bl $[Table, where LR is popped and compared to possible LRs to determine which subroutine to execute] pop {lr} - as stated above ldr first possible LR cmp register with loaded possible LR, current LR bne [Next compare] bl $[Hack] Then, at the hack routine, I do my business and load some numbers into the 8 base registers that I use to repair LR before popping 0-7. From there, I usually load one last word into a register that won't be used by the next routine and mov pc, that register. The returning issue is still there, I guess. You could still find registers that will be overwritten anyway and load a return address into it...or you could be a sneaky bastard and write your code in ARM, and load directly into PC (that works, doesn't it?) Oh, I have another question. I just got done writing my IEEE 32 bit floating point processing functions that handle addition, reciprocation, and multiplication (which allows me to do all 4 basic math operations, since subtraction is a variant of addition and division is multiplying by the reciprocal). I had to write my mutliplication function in ARM to make use of "umull" (thanks to whoever pointed out the umull operation in the programming thread I made >.>). After I assembled it and saw how big it was (400 bytes XP) I thought it would be slow, but it seems to actually calculate faster than the thumb scripts for addition and reciprocation. Is ARM mode just faster or something? If anyone cares, my reciprocator and my addition programs have 1:1 results with an actual java-based floating point calculator, but my multiplication function tends to give outputs that are just 0x1 off from the expected output. I debugged it to see why and it turns out the error occurs during the umull instruction. I can't do anything about that :\ (edited by Zeld on 02-08-07 09:52 AM) (edited by Zeld on 02-08-07 09:58 AM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| You know, if you debug the process of a mov pc, it will take you to the address&fffffff7, but r15 will be equal to address&fffffff7 plus 2 or 4, depending on the processor mode. It actually DOES increment because of pipelining >.>
What's the relationship you decided on between the day number and Adder's firepower? If it's directly proportional it's gonna be broken, no? |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| On that note, would it be possible to simplify code by taking out unneeded comparisons in cases where previous operations have altered the flags accordingly? I never tried it in thumb, but I've seen it used in ARM a lot (what with just about every operation in ARM being able to have conditions, it's no wonder). | |||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| Worked on this the past couple of days. I got into N64 assembly hacking just two days ago and this was the result.
803fffc0 - points to an address equal to the speed address -0xc4 Hook to from 80018DA0: j 80400000 nop (short) Get Speed Address: LUI T7, 0x8040 ADDIU T7, T7, 0xFFC0 LW T7, 0x0000 (T7) ADDIU T7, T7, 0x00C4 Get what goes in speed address and store it: LUI T6, 0x8040 ADDIU T6, T6, 0x002C LW T6, 0x0000 (T6) SW T6, 0x0000 (T7) Fix missing instructions and return: LUI T7, 0x8012 J 0x80018DA8 LW T7, 0xAE58 (T7) 80018DA0 0810 80018DA2 0000 80018DA4 2400 81400000 3C0F 81400002 8040 81400004 25EF 81400006 FFC0 81400008 8DEF 8140000A 0000 8140000C 25EF 8140000E 00C4 81400010 3C0E 81400012 8040 81400014 25CE 81400016 002C 81400018 8DCE 8140001A 0000 8140001C ADEE 8140001E 0000 81400020 3C0F 81400022 8012 81400024 0800 81400026 636A 81400028 8DEF 8140002A AE58 Above code pile allows for infinite max speed to hovercraft and plane; car can't move with this code active (really...you'll just drive in place. Dangerous...) Factor in button activated alterations of 8040002c and you can allow for instant acceleration/braking for the car and instant acceleration/infinite max speed for the other vehicles. This is the only way to make the car drivable. You must enter floats to the address, which means 4 codes per button combination...two for each 16 bits of the float, and 2 for the button conditions. You will need to know how to get the hex value of a float and convert it to the appropriate GS code. All vehicles use 0 for 0 speed, but entering 0 will not stop the plane or hovercraft. Instead, it will trick the game into thinking you're not moving and still let you move, allowing for infinite max speed. The car will just plain stop. As for actually going forward at high speeds, you can rely on infinite max speed, or enter 25 (as a float) for your speed to always go that fast when you press the appropriate buttons. 25 for the airplane and hovercraft is about 150+ km/h, and for the car, it is the same, only negative (the car drives backwards O_o). Conversely, entering -25 makes the plane and hovercraft go backwards insanely fast, and the car go forward. 25 is a bit too fast, actually; try 15... Try not to go out of the overworld maps when going that fast; it happens very easily. In actual races, however, the invisible walls will (from what I've seen every time so far) always be able to catch you, so you can just smash down the accelerator and plow through the race, Insane fun... I'll try to look into making some example button codes for reference on how to get the full use of this cheat. I apologize for the length, but hey, assembly hacks aren't only a couple of bytes long
Edit: You're definitely going to need an expansion pak for this code to work, or else the game will start executing from memory that doesn't exist. You should know what that means...I think Sukasa trademarked it, though, so I can't say it myself. 'nother Edit: It appears that if you use this code to accelerate at anytime before the announcer says "Go", you can take off and even control which way you're turning to get a head start. A really, really big one. Damn... 'nother Edit: I hit "B" to brake while riding the hovercraft with 8040002c set to 25 (float). I went about three times faster. Apparently I can hit B to go through walls, now... Edit, again: Because of the way the codes are set up, the values only need to be set once and then they can be left alone until you feel like changing them again or need to. So, rather than making the button codes be A and/or B, it might be better to just use combinations of L and another button (is L even used in this game?). You will need to reset the speed value to 0 when entering new areas or when changing vehicles, or your loss of control will hinder playing experience (I was about to enter a boss door, but had left the code at a value that made me drive backwards back into the level I had just come from, in the middle of a cutscene). (edited by Zeld on 02-13-07 05:27 PM) (edited by Zeld on 02-13-07 05:30 PM) (edited by Zeld on 02-13-07 05:46 PM) (edited by Zeld on 02-13-07 06:03 PM) (edited by Zeld on 02-13-07 06:07 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| It's not just a max speed modifier and it isn't global if you count that it doesn't work in mutliplayer
I would take what you've said into consideration (as usual), but now is time for celebrate victoly, so I must play around with codez before I bother touching up my crummy coding. I'm really, really sloppy and lazy :\ |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 6302 days Last view: 6300 days |
| ||
| It was a pseudo-max speed mod as well as a speed setting code. Directly setting your speed is awesome.
Now, however, it is not a max speed code. It isn't even a speed code, anymore. It is now an acceleration code, but if you set it up right it will act as a speed code and be very flexible in its control. You'll be able to play normally should you choose or need to. Here is the new version: ;Hook to from 80018DA0: j 80400000 nop LUI T7, 0x8040 ADDIU T7, T7, 0xFFC0 LW T7, 0x0000 (T7) ADDIU T7, T7, 0x00C4 LUI T6, 0x8040 ADDIU T6, T6, 0x0058 ;This stuff is in lower case because I recently assembled it into my old source. Floating point addition ftw ;Also, I had to explain to HyperHacker why adding the float form of 1 to a number in plain hex is the same as multiplying by 2^127, and not the same as adding 1 with the aid of a FPP XD lui A0, $8040 addiu A0, A0, $0050 swc1 f0, $0000 (A0) swc1 f1, $0004 (A0) lwc1 f0, $0000 (T7) lwc1 f1, $0000 (T6) add.s f0, f0, f1 swc1 f0, $0000 (T7) lwc1 f0, $0000 (A0) lwc1 f1, $0004 (A0) ;Fix missing instructions and return: LUI T7, 0x8012 J 0x80018DA8 LW T7, 0xAE58 (T7) 80018DA0 0810 80018DA2 0000 80018DA4 2400 81400000 3C0F 81400002 8040 81400004 25EF 81400006 FFC0 81400008 8DEF 8140000A 0000 8140000C 25EF 8140000E 00C4 81400010 3C0E 81400012 8040 81400014 25CE 81400016 004C 81400018 3C04 8140001A 8040 8140001C 2484 8140001E 0050 81400020 E480 81400022 0000 81400024 E481 81400026 0004 81400028 C5E0 8140002A 0000 8140002C C5C1 8140002E 0000 81400030 4601 81400032 0000 81400034 E5E0 81400036 0000 81400038 C480 8140003A 0000 8140003C C481 8140003E 0004 81400040 3C0F 81400042 8012 81400044 0800 81400046 636A 81400048 8DEF 8140004A AE58 Set 8040004C to -.3 with C Left, .3 with C Down, and 0 with B for best tested control. that is, I took out my USB controller and, with the N64 controller layout in mind, I designed the key layout for this code that would best suit a regular player. W00tness. Edit: Yes, the code is just too damned long, but there's not anything that can be done about it from what I could see. There just aren't any routines that have the right values in the registers 100% of the time. DKR abuses routines for multi-functionality so bad it hurts. (edited by Zeld on 02-14-07 11:38 PM) (edited by Zeld on 02-14-07 11:40 PM) |
| Pages: 1 2 3 |
| Acmlm's Board - I3 Archive - - Posts by Zeld |
