diff --git a/BUILD__WINDOWS_8md.html b/BUILD__WINDOWS_8md.html index d25397f64..b114efc26 100644 --- a/BUILD__WINDOWS_8md.html +++ b/BUILD__WINDOWS_8md.html @@ -5,7 +5,7 @@ -
Jump/Branch/Function - Tells the cpu to execute instructions somewhere else and come back here when done.Hexadecimal - A numbering system just like decimal (also called base-ten) or roman numerals. An easy method for programmers and computers to understand each other which groups/separates bytes of information in a readable format. Representing information as decimal results in an unreadable mess.s32/word/int - A max size for a number. Data represented as 32 bits or 4 bytes: 0x00000001. It consists of eight digits.s16/half-word/short - A number represented as 16 bits or 2 bytes: 0x0001. It consists of four digits. Maximum value 65,535 (0xFFFF).s8/byte/char - A number represented as 8 bits or 1 byte: 0x01. It consists of two digits. Maximum value 255 (0xFF).Computers use addresses to jump through code. This works similar to finding a house using its address. Except, that reaching the house is nearly instantaneous and it only contains more instructions and jumps or some data such as a texture or a text string. Also, when finished with the house, you travel back to the previous destination which may have some left-over instructions or more jumps. You can imagine this quickly becoming a spaghetti monster jumping all over the place.
-A typical N64 address: 0x8029E158
In an N64 program, addresses begin at 0x80000000. As you create code, data, and the like, the compiler will add onto this base number and assign variables to an address.
Might compile a_value to 0x80000004 and b_value to 0x80000008. At anytime if you manually wrote:
Both would output 2. This allows some trickery. Such as pointer math: print(0x800000004 + 0x80000004) would output 7.
Addresses generally count up by fours: 0x4, 0x8, 0xC, 0x10, 0x14, etc.
It does not when working with s8 and s16 integer types. An s32 or int always takes up eight digits: 00000001
Will output 1 but if you opened the program in a hexadecimal file you will notice that its written to disc as 0x00000001
An s16 looks like: 0x0001 an s8 looks like: 0x01.
Data can take up tonnes of space:
The address of this could extend from 0x80000100 to 0x800000534. However, you would not see 0x80000533. The compiler generally aligns objects to 4, 8, 0xC, or 0x10 (Note that files are generally aligned to 0x10). With the exception being when you're working with s16 and s8. If you have:
You might expect to see this: 000300000005 or 0x0003 0x00000005 But actually, it will be this:
This is called alignment. The compiler aligned b to the next 'major' address. Of course, if you program two s16's then the blank 0x0000 will be used. The max size of an s8 is 0xFF (255). Trying to write a number higher than 255 to an s8 type may crash the program as it might try to write onto the next variable.
-
Code contains addresses too. Lets take a look at some example assembly:
Format: rom address (file on disc), ram address, machine-code, assembly, arguments/parameters
The lui, addiu, ori, etc. are just representations of the machine-code. For example: 0x3C08800F is what the cpu is actually running. Lets break down this one command: op-code, parameters 0x3C is the op-code (lui or load-upper-immediate) this command loads an address. The 08 tells the CPU to use the register t0 and the 0x800F is the first-half of the address to load. So, in the register t0 (which is the size of an int: 0x00000000) the value 0x800F0000 is written.
Note that one machine-code command is the size of an int/s32/word. How do we load an address (which is the size of an int). There isn't enough room when you include the op-code and register: 0x3C08800F6990. That no worky. So we have to do this with two commands called a hi and a lo:
Now, we're going to add the offset: t0: 0x800F0000 + 0x6910 = 0x800F6910. If you run the game and use a memory viewer at this location. You will quickly realize this region of data (it's actually .bss but lets not get into that), is the controller data. The data alters to reflect which controller buttons are pressed. So if I just wanted to read one of these values, the assembly will do two commands to put the address in the register. Then another command can read the address in that register to receive the value at that location. This value can be compared to see if the button is active. Ex. zero might mean not pressed, whereas one might mean pressed.
Now, earlier it was mentioned that code contains addresses. If I wanted to, I could do this: Jump to: 0x80000410. Which would make the CPU start running code at that location. Or I could read the value that exists there: 0x2129FFF8. Not sure what I might do with that number, but it does act like a normal number. In decimal it is: 556,400,632. I could add and subtract to it (Which would likely crash the game if it tried to run that command after). Now, jumping to any code address in the middle of a function would almost certainly crash the game or result in strange behaviour. The purpose of this explanation is really to show that everything is just a bunch of numbers or values, represented by an address. Even code itself.
For a more refined explanation of addresses and pointers its suggested to use the Googles. However, this explanation was written with the N64 in-mind.
+This method is not recommended nor supported. However, it is the only solution to build in W7/W8. WSL is the path of least resistance, use that not this
@@ -96,36 +91,36 @@ Compiling mk64 Decomp In Windows
- leogames
The extraneous and convoluted process to building mk64 decomp on Windows begins with disabling your anti-virus program or adding an exception to the mk64 decomp folder and the msys2 installation folder. Please note that this action may impact the security of your system. Prior to proceeding, make sure to understand the increased security risks that may result from this step. Nobody except you, is responsible and liable for your system and its security.
-Any misteps may require a complete uninstall of MSYS2 MinGW x64 and restarting from the very beginning.
It is unknown if MSYS MinGW x32 is supported (most likely not).
Follow the initial instructions to update the base packages. Ignore installing any extra packages in-case they conflict with the below steps.
MinGW is a separate program from Msys2. However, it must be wrapped right into msys2. Compiling recomp requires steps using
MSYS2 MSYS and MSYS2 MinGW x64. The instructions will clearly differentiate which terminal program to launch and run in the section titles.
Compiling the recomp executable that generates the source files for compiling the compiler requires capstone. A disassembly, analysis, and reverse-engineering framework. Capstone is only available on MSYS2 MinGW x64. It is not available on MSYS2 MSYS. However, compiling the compiler itself requires MSYS2 MSYS because it contains an equivallent dependency for mman. A memory mapping library. MSYS2 MinGW x64 does not contain an equivallent dependancy.
For some reason on Windows capstone is inside of a capstone folder.
Download and install the mips64 tool chain:
https://github.com/N64-tools/mips64-gcc-toolchain
Merge the inner folders (bin, share, etc.) with the respective folders in C:\msys64\mingw64\
In MSYS2 MinGW x64 run in mk64/tools/ido5.3_recomp/:
Generate the .c files which will compile into the recomp binaries. mk64 requires the following compiler binaries: as1, cc, cfe, copt, ugen, ujoin, uld, umerge, uopt
In MSYS2 MinGW x64 run in the directory mk64/tools/ido5.3_recomp/:
If you get an assertion failed error. Then the directory to the compiler is incorrect. The binary for cc is in /ido5.3_compiler/usr/bin/ so do:
In MSYS2 MSYS run in the directory mk64/tools/ido5.3_recomp/:
-O2 is an optional optimization flag.
In /mk64/ run:
Replace # with your number of CPU cores for quicker compilation.
@@ -161,6 +156,7 @@ Step 8: Compile mk64 in <tt>MSYS2 MinGW x64</tt> diff --git a/compiling.html b/compiling.html new file mode 100644 index 000000000..22a417bbe --- /dev/null +++ b/compiling.html @@ -0,0 +1,144 @@ + + + + + + + +|
+ Mario Kart 64
+
+ |
+
The build system has the following package requirements:
binutils-mips >= 2.27 +python3 >= 3.6 +libaudiofile +
To add submodules run git submodule update --init --recursive after cloning.
Both EU builds first requires US to be built first:
Now build either EU 1.0 eu-1.0 or EU 1.1 eu-final
diff/first-diff commands
To install build dependencies:
Install the following AUR packages:
Review the n64decomp/sm64 readme for instructions to compile in other distributions.
+Compiling on Windows requires MSYS2 MinGW x64. The setup process is a tad intensive.
+
Instructions here
+Install Homebrew, then install the following dependencies:
When building, use gmake to ensure that homebrew make is used instead of the old, macOS system make.
Build the Docker image:
When building and using other tools, append the following in front of every command you run:
For example:
Place a US version of Mario Kart 64 called baserom.us.z64 into the project folder for asset extraction.
Run the following commands after pulling:
|
+ Mario Kart 64
+
+ |
+
Jump/Branch/Function - Tells the cpu to execute instructions somewhere else and come back here when done.Hexadecimal - A numbering system just like decimal (also called base-ten) or roman numerals. An easy method for programmers and computers to understand each other which groups/separates bytes of information in a readable format. Representing information as decimal results in an unreadable mess.s32/word/int - A max size for a number. Data represented as 32 bits or 4 bytes: 0x00000001. It consists of eight digits.s16/half-word/short - A number represented as 16 bits or 2 bytes: 0x0001. It consists of four digits. Maximum value 65,535 (0xFFFF).s8/byte/char - A number represented as 8 bits or 1 byte: 0x01. It consists of two digits. Maximum value 255 (0xFF).Computers use addresses to jump through code. This works similar to finding a house using its address. Except, that reaching the house is nearly instantaneous and it only contains more instructions and jumps or some data such as a texture or a text string. Also, when finished with the house, you travel back to the previous destination which may have some left-over instructions or more jumps. You can imagine this quickly becoming a spaghetti monster jumping all over the place.
+A typical N64 address: 0x8029E158
In an N64 program, addresses begin at 0x80000000. As you create code, data, and the like, the compiler will add onto this base number and assign variables to an address.
Might compile a_value to 0x80000004 and b_value to 0x80000008. At anytime if you manually wrote:
Both would output 2. This allows some trickery. Such as pointer math: print(0x800000004 + 0x80000004) would output 7.
Addresses generally count up by fours: 0x4, 0x8, 0xC, 0x10, 0x14, etc.
It does not when working with s8 and s16 integer types. An s32 or int always takes up eight digits: 00000001
Will output 1 but if you opened the program in a hexadecimal file you will notice that its written to disc as 0x00000001
An s16 looks like: 0x0001 an s8 looks like: 0x01.
Data can take up tonnes of space:
The address of this could extend from 0x80000100 to 0x800000534. However, you would not see 0x80000533. The compiler generally aligns objects to 4, 8, 0xC, or 0x10 (Note that files are generally aligned to 0x10). With the exception being when you're working with s16 and s8. If you have:
You might expect to see this: 000300000005 or 0x0003 0x00000005 But actually, it will be this:
This is called alignment. The compiler aligned b to the next 'major' address. Of course, if you program two s16's then the blank 0x0000 will be used. The max size of an s8 is 0xFF (255). Trying to write a number higher than 255 to an s8 type may crash the program as it might try to write onto the next variable.
+
Code contains addresses too. Lets take a look at some example assembly:
Format: rom address (file on disc), ram address, machine-code, assembly, arguments/parameters
The lui, addiu, ori, etc. are just representations of the machine-code. For example: 0x3C08800F is what the cpu is actually running. Lets break down this one command: op-code, parameters 0x3C is the op-code (lui or load-upper-immediate) this command loads an address. The 08 tells the CPU to use the register t0 and the 0x800F is the first-half of the address to load. So, in the register t0 (which is the size of an int: 0x00000000) the value 0x800F0000 is written.
Note that one machine-code command is the size of an int/s32/word. How do we load an address (which is the size of an int). There isn't enough room when you include the op-code and register: 0x3C08800F6990. That no worky. So we have to do this with two commands called a hi and a lo:
Now, we're going to add the offset: t0: 0x800F0000 + 0x6910 = 0x800F6910. If you run the game and use a memory viewer at this location. You will quickly realize this region of data (it's actually .bss but lets not get into that), is the controller data. The data alters to reflect which controller buttons are pressed. So if I just wanted to read one of these values, the assembly will do two commands to put the address in the register. Then another command can read the address in that register to receive the value at that location. This value can be compared to see if the button is active. Ex. zero might mean not pressed, whereas one might mean pressed.
Now, earlier it was mentioned that code contains addresses. If I wanted to, I could do this: Jump to: 0x80000410. Which would make the CPU start running code at that location. Or I could read the value that exists there: 0x2129FFF8. Not sure what I might do with that number, but it does act like a normal number. In decimal it is: 556,400,632. I could add and subtract to it (Which would likely crash the game if it tried to run that command after). Now, jumping to any code address in the middle of a function would almost certainly crash the game or result in strange behaviour. The purpose of this explanation is really to show that everything is just a bunch of numbers or values, represented by an address. Even code itself.
For a more refined explanation of addresses and pointers its suggested to use the Googles. However, this explanation was written with the N64 in-mind.
+Directories | |
| directory | Understanding the Basics |
| directory | basics |
| ▼ docs | |
| Understanding the Basics | |
| basics | |
| ▼ include | |
| ► libc |
|
+ Mario Kart 64
+
+ |
+
|
+ Mario Kart 64
+
+ |
+