 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - SM64 Hacking (Archive) - ASM hacking |  -  -  |
| Pages: 1 2 3 | Next newer thread | Next older thread |
| VL-Tone Member Super Mario 64 forum moderator Level: 53     Posts: 356/621 EXP: 1135503 For next: 21616 Since: 07-27-07 From: Montreal, Canada Since last post: 4.7 years Last activity: 1.2 years |
|
||||
|
| Deleted User Collection of nobodies |
|
||
Originally posted by VL-Tone For dealing with multiple levels, would a better solution be if there was no empty space to add more level data at the end of the level data, TT64 would put a pointer at the end of that levels data that pointed to the end of the rom, then TT64 would add the data there? Or would this not work, be complicated to make or require major reworking of the rom? If this solution did work, I suppose you wouldn't have to move data around, there would be no wasted space (except for the pointers), and the data could be as big as you want, as long as all the data loaded is not too big for the N64 to handle. The only downside would be that the data would get fragmented if you added data to the level which comes before another level (in the rom) and as such, the data would be unorganized. If this solution is followed, and if the data needs to be organized, a defragmenter would need to be made specially for Mario 64, or maybe manual editing to do the same thing. Your solution sounds easier to implement, though. Edit: I hope that stuff I said was correct. |
| messiaen Catgirl Level: 68 Posts: 414/1085 EXP: 2594037 For next: 134763 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
Right, I'll start documenting how each behavior which uses trajectory pointer works. There aren't much objects like this (most use the Platform On Tracks behavior), so hopefully a "universal solution" will be possible with simple changes.Originally posted by VL-Tone What about giving the user the option to choose what original level will be replaced, as adding new levels is probably too much trouble for now? One of the problems, however, is that there are lots of hardcoded stuff which relies on the Level ID number, but I guess that's something the user will have to discover on its own (I keep having surprises with the team hack) and eventually there will be workarounds for each issue. There is even some hardcoded stuff for "deleted levels" (if I'm not mistaken, to level number 0x20), but trying to trigger it didn't result in any noticeable effect. Originally posted by VL-Tone A 32MB ROM sounds like a good idea (and why not keep it also open to further expand to 48MB if needed?). Levels with complex geometry and, since RAM probably won't be a problem, much more textures than the original ones, will take a lot of space. When you talk about size limitation, do you mean a fixed size for each level (which I guess would mean all loaded banks) or a estimated size for each kind of bank (ie, 0x0E level script, 0x07 level geometry) ? ____________________ Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| VL-Tone Member Super Mario 64 forum moderator Level: 53 Posts: 358/621 EXP: 1135503 For next: 21616 Since: 07-27-07 From: Montreal, Canada Since last post: 4.7 years Last activity: 1.2 years |
|
||||
|
| Stevoisiak Member Level: 38 Posts: 173/283 EXP: 345476 For next: 24971 Since: 11-22-07 From: New York, Long Island Since last post: 12.3 years Last activity: 5.6 years |
|
||
Originally posted by VL-Tone One big problem with that. Wouldn't this cause a lot of people who don't read the readme's with hacks to use a patch for a 48MB rom hack on an old 24MB Rom? |
| Me-me 340    Level: 41  Posts: 51/341 EXP: 461679 For next: 18466 Since: 08-05-07 Since last post: 9.7 years Last activity: 8.1 years |
|
||
| There's an easy way around this: Put a big text that says READ THE README! in the first post, or post the readme document in the thread instead.  ____________________ Wow! SM64 is totally turned upside-down! |
| messiaen Catgirl Level: 68 Posts: 427/1085 EXP: 2594037 For next: 134763 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Here's a very interesting tutorial about setting up a GNU N64 Toolchain (on Windows) by ZZT32 (who has done some major work on Zelda64 hacking). There are some nice Zelda 64 example hacks included, plus a tool to convert the binary output into a Gameshark code. Here is something I tried in Mario64 (just a snippet). It saves a lot of time compared to doing it in MIPS ASM! Once we have some nice header files ready (ie, object structs and controller input), some pretty amazing stuff will be possible. mario64.h: mario64.c: Now I just hook this somewhere in one of the behavior scripts (Mario's behavior is useful for this) and it's done! ____________________ Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| Hectamatatortron Member Level: 35 Posts: 96/232 EXP: 257991 For next: 21945 Since: 09-19-07 Since last post: 7.2 years Last activity: 5.3 years |
|
||
|
Don't forget you can hook other things, too. Like, say, the constant routine that always executes. ;Constant hook 80327650 J 80400010 LUI K0, $8036 ;AT and K1 are free 80400010 ADDIU K0, K0, $72B0 SD AT, $0020 (K0) ;Inject code here ;Code ;End Inject ;If K0 needs to be free LUI K0, $8036 J 8032765C ADDIU K0, K0, $72B0 Not sure what that looks like in the ROM. The two codes I wrote in C++ for Mischief Makers were hooked a similar way. They had all the code they needed to be inserted at the constant execution level encapsulated within, and hooking from those kinds of areas gives you more freedom with the game. What I've been doing is getting .cpp files set up after I find a good chunk of data, and following the template I showed you. Then I find a place to hook that always executes and use an ASM template I made, along with a text editor that supports regular expression find and replace operations to quickly insert code compiled from C++ into the "code shell" the file has. Then I do some literal find and replace operations to fill out the parameters for the template, copy the WHOLE FILE into Renegade and bam, assemble it into a working code, no problems (assuming my code was coded correctly). The template can be found here. Thanks for confirming that hacking a game's assembly doesn't always have to be done with assembly. Maybe more people will try my method now, instead of being so skeptical... Edit: Maybe have your ASM pooled in some place such that a single hacked behavioral command can load it all at once into free RAM area, and from then on you will already know where to put new code you write. That ought to make the production cycle insanely fast. ____________________  
|
| messiaen Catgirl Level: 68 Posts: 428/1085 EXP: 2594037 For next: 134763 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| It certainly saves tons of time debugging stupid mistakes. So far the only problem is that sometimes I get "unsupported opcode" errors (all related to beql) when doing some "if" conditionals. Doing minor changes to the code layout seems to get over it (perhaps the compiler just chooses a different opcode), so I have no idea if it's my or the compiler's fault. I have never tried messing with this K0/K1 registers, I thought it was bad karma  . What I am doing is simpler: I just copy an entire area of the ROM to extended memory at the title screen, so the custom functions are loaded all the time and I can just call them whenever I want. The 'loader' code replaces one unused function, so there's no problem with that.In the N64 Toolchain package set by ZZT32 there are some handy tools such as one that will convert the binary compiled code to a Gameshark code (if I'm not mistaken, you also did a very similar tool), which is useful for testing stuff in Nemu. A question: how to make my function pass a float argument in register $F12 (used to pass float parameters) ? I tried seting this: But it compiled as something like ADDIU A0, R0, 0x0002 instead of using the $F12 register. Any ideas about this? ____________________ Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| Hectamatatortron Member Level: 35 Posts: 98/232 EXP: 257991 For next: 21945 Since: 09-19-07 Since last post: 7.2 years Last activity: 5.3 years |
|
||
|
Have you tried using the register keyword? I don't know the syntax your toolchain accepts, if any, for specifying the usage of a specific register. It may support inline ASM, however. Something like inline int Reciprocate(unsigned long Divisor) { asm volatile( "mov r0, %0\n\t" "mov r1, %2\n\t" "mov lr, pc\n\t" "bx r1\n\t" "mov %0, r0\n\t" : "=r"(Divisor) //Output list : "0"(Divisor), "r"(ReciprocateCall) //Input list : "r0", "r1", "cc" //Clobbered registers (cc here refers to the flag register) ); return Divisor; } ____________________
|
| messiaen Catgirl Level: 68 Posts: 431/1085 EXP: 2594037 For next: 134763 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Nevermind, it was something in the Makefile, now I don't have the annoying unsupported opcode problems and also the floats end up in the right float argument registers. Since this moved away a bit from ASM Hacking, I think I'll just start a new thread when I have some header files with the whole object struct/misc functions defined. ____________________ Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| yoshiman Member Level: 23 Posts: 92/95 EXP: 67008 For next: 715 Since: 12-21-07 From: London, England Since last post: 13.2 years Last activity: 12.9 years |
|
||
| Here's what I know so far about what happens when Mario runs up a slope. As Mario goes up the slope, the value at 8033B3BC (16-bit) increases, but is zero when he is not moving. However, the value does not lean Mario's body forward when still, only when running. This value ends up in Mario's graphics structure (geo layout) by a function call (80277294) from Mario's graphics structure. 8027737C LH T5, 0X000C(T4) T5=(8033B3BC) 80277380 SH T5, 0X001C(T6) (800F47C4)=T5 There is also a value at 8033B3BE (16-bit) which seems to turn Mario's body. ____________________ James S. We English do things a little differently...Anyone for a cup of tea while we hack?! |
| messiaen Catgirl Level: 68 Posts: 474/1085 EXP: 2594037 For next: 134763 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Nice to see you posting back! By he way, here's a map of the "Mario" struct I was doing a few weeks ago. It starts at 0x8033b170 and seems to be 0xc0 bytes long. Inside it, there is pointer to other structs, such as camera/controller. I guess one of the pointers could be to that data you posted, as a part of another Mario-related struct. At RAM 0x8032d93c lies a a global variation that contains a pointer to the 0x8033b170 struct. One of the most interesting parts is the action word, which relates to the list RomanianGirl posted in another thread. One code I did a while ago used that little snippet, which show how handy that list can be. ____________________ Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| VL-Tone Member Super Mario 64 forum moderator Level: 53 Posts: 380/621 EXP: 1135503 For next: 21616 Since: 07-27-07 From: Montreal, Canada Since last post: 4.7 years Last activity: 1.2 years |
|
||||
|
| yoshiman Member Level: 23 Posts: 93/95 EXP: 67008 For next: 715 Since: 12-21-07 From: London, England Since last post: 13.2 years Last activity: 12.9 years |
|
||
| Don't forget that only the middle of the three functions in the Mario behaviour script is actually the Mario behaviour, the other two are for the second debug display and the spawn debug mode. Thanks messiaen, I'm going to have to compare that with what I have for PAL (UK). Here is what I know of just a few of the functions called from the uncompressed Mario geo layout: 800F09F8 802773A4 Remove this pointer and Mario's head doesn't turn when looking around with Camera-up. 800F0A54 802771BC Remove this pointer and Mario doesn't blink, it seems to only affect when he is not moving. ____________________ James S. We English do things a little differently...Anyone for a cup of tea while we hack?! |
| VL-Tone Member Super Mario 64 forum moderator Level: 53 Posts: 385/621 EXP: 1135503 For next: 21616 Since: 07-27-07 From: Montreal, Canada Since last post: 4.7 years Last activity: 1.2 years |
|
||||
|
| Pages: 1 2 3 | Next newer thread | Next older thread |
| Jul - SM64 Hacking (Archive) - ASM hacking | - - |
 |
Acmlmboard - commit 47be4dc [2021-08-23] ©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al. Warning: You are using TidyHTML mode! Pages MAY and probably WILL break. To disable, click here or append 'xxx-off=1' to the URL!  |
| Query execution time: | 0.088819 seconds |
| Script execution time: | 0.040919 seconds |
| Total render time: | 0.129738 seconds |
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
