Language…
4 users online:  Atari2.0, BabaYegha, sinseiga, Tsquare07 - Guests: 241 - Bots: 342
Users: 64,795 (2,375 active)
Latest user: mathew

Posts by shyguyhex

shyguyhex's Profile → Posts

Originally posted by Blakeoramo
Hey! Does anyone know the SM64 ROM Hack Playing setting for PJ64 2.1?
Ive tryed to copy the 1.6 settings, (Working only short lived), and 1.7, but the hacks I play, (even one's with just a simple music import), lag like a terrible session of Halo 3 with large amounts of lag, please help!#w{:<}

I'm guessing the reason you're getting a lot of lag is either the rom hack itself has performance issues or your computer doesn't like the gfx plugin.

Also make sure the cpu mode is on recompiler, not interpreter, because that can cause a bit of lag too.
(restricted)
(restricted)
ASM Resources and Discussion

Hello SMWC. It's apparent that many people on here are quite new to or don't know where to get started with assembly hacking, so this thread is here to serve as a resource for learning and understanding N64 ASM code.

Assembly or ASM is the low level code that the central processing unit reads and executes to make all the magic happen, and it's something that you should be somewhat familiar with in order to make edits to the way a game (namely SM64) works.


An excerpt from the function that prints HUD elements.


The code above is probably rather daunting to those who are new to ASM (it was to me when I started), but with a bit of patience and some memorization, you could be coding like a b0ss in no time. The first thing you should know is that the emulator of choice for viewing and testing ASM code is Nemu64, for its wonderful debugging capabilities. Nemu64 is not fond of VL-Tone's extended rom for one reason or another, so one idea here would be to do your assembly editing/testing with an original SM64 rom and then port your finished code over to your project rom.

I'll be compiling a list of tutorials/references/software that should aid in N64 ASM hacking here. If you have anything that you think should be added to the list, let me know.

Tutorials:
R4300i tutorial by Tarek
Simple debugging demonstration with Nemu64 by yoshielectron
LemASM demonstration by Skelux
MIPS Instruction Reference from University of Idaho


Assemblers:

B64si Beta
Command line assembler for ram/rom, comes with notepad++ syntax highlighter

By shyguyhex - Official thread

CajeASM Stable
Command line assembler, comes with a frontend and notepad++ syntax highlighter

By Tarek701 - Official thread

LemASM - GUI assembler by Lemmy, old but commonly used and gets the job done
Renegade64 - by Viper187
sgASM w2 - by shyguyhex

Other ASM related tools:
jalFinder - by shyguyhex (cmd line utility that scans rom for JALs to provided functions, probably only useful under special circumstances)
ASM address calculator - by shyguyhex



ASM Tips

Tip 1: When coding in ASM, always remember the "negative rule". If an immediate value is greater than 0x7FFF, then the value is negative!

If we want to load 32767 (decimal) to T0, we would first believe that we have to write:

LUI T0, 0x8001

But this is false. As 0x8001 is over 0x7FFF, we actually load -32767 into T0, which we didn't want! To solve this, you simply multiply 0x8001 with 0xFFFF and we get 0x7FFF. This value is not over 0x7FFF and so we now have 32767. So:

LUI T0, 0x7FFF

is correct.

Tip 2: The above rule also applies to load/stores. Remember, that each load/store aligns a 16-bit value to 32-bit! So, if the value is negative, it subtracts one from the upper half!

Let's say we want to load a value from 0x8033B218. It's the current coin amount and a halfword value. Your first thought would be most likely:

Code
LUI T0, 0x8033
LH T1, 0xB218(T0)


However, the above would actually load the value from 0x8032B218 and not the expected 0x8033B218. So, why's that? The instruction LUI simply loads 0x8033 to the upper half of T0; T0 = 0x80330000. LH however loads the lower half, but needs to shift it to the lower half obviously. As 0xB218 is over 0x7FFF, it's negative. Now, doing a shift to left means that MIPS still needs to keep the negative value and this means that the result would be 0xFFFFB218. This negative value is then added to 0x80330000, resulting in: 0x8032B218.

So, to solve this little problem we simply add 1 to the upper half "0x8033". So, we get 0x8034. So, later the game would subtract 1 and successfully loads the value from 0x8033B218.

Tip 3: The delay slot below Branches and Jump instructions is executed BEFORE the jump/branch instruction. Sometimes the delay slot can be useful. If there's nothing important to put in there, always remember to write a NOP!

To show off an example:

JAL 0x802D48D4
ORI A0, R0, 0x000A

This would first do ORI and then a JAL. Sometimes this can save a lot of code;

Code
LUI A0, 0x254D
ORI A0, 0x44A5
LUI A1, 0x254A
ORI A1, 0x222A
JAL 0x802D48D4
NOP


could be shortened to:
Code
LUI A0, 0x254D
LUI A1, 0x254A
ORI A0, 0x44A5
JAL 0x802D48D4
ORI A1, A1, 0x254A
Good points there. You can't expect to become a good ASM programmer over night. Baby steps are key.
Originally posted by MrNiki09
Hey guys.

I used Tile Molester to find the Ending Cake and I "found" it. Has to be between 010BB000 and 010E0800. The thing is that I can't edit it properly (because in TM it looks like a real mess, it's a miracle that I found it...). Opening it with N64Rip doesn't help neither since it is also displayed incorrectly (monochrome?).

Does anyone know how I can display it correctly so it can be edited?






It probably looks like a real mess because it's a large image, and the N64 only supports small images, so to make a big image, it has to use a bunch of small tiles.





Is this sort of what your seeing?



It's from frauber's texture dump </div>
(restricted)
(restricted)
(restricted)
Originally posted by mosky2000
Can someone please give me a text file with asm codes so I can try them out and see how it works? Also how do you put the behavior of any object with the asm code in it? (includes custom objects too)


To make a behavior call an asm function, you would put a 0C command in a behavior script; for example:
0C000000 80400000
This will make the script interpreter execute whatever asm function is at 80400000 in ram.

And then your asm would look something like this:
Code
addiu sp sp -40 ; allocate stack space
sw ra 0x14(sp)  ; save return address @ sp+0x14
lui t0 0x8036   ; t0 = 0x80360000
lw t0 0x1160(t0); t0 = value at 0x80361160, which will be a pointer to the current object
sw t0 0x18(sp)  ; save pointer to your object @ sp+0x18
nop ; \
nop ; | code which effects your object can go here
nop ; /
lw ra, 0x14(sp); load return address into register ra
jr ra          ; done
addiu sp sp 40 ; free stack space


So this is basically what the entire language is going to look like when it's finished.

I would also like to add a keyword like "crc_restore" (or "crc" because all of the keywords are 3 letters long) which would auto restore the checksum at 0x10 after patching. If anyone can hook me up with how the crc algorithm works I'd really appreciate it #tb{^V^}

Edit: just found an app called RN64crc which should do the job
le memez
(restricted)