N64 DumpDiff

From en64 wiki
Jump to: navigation, search

I'd rather avoid "reinventing the wheel," if you will. ShenoxVII covered this topic well enough. Anyway, this page is dedicated to the differences between N64, V64 and Z64 dump types, internal programming of ROMs and also covers endianness.

Some stuff you will need to know.

Depending on the operating system to work, consider the byte order of numeric data types that use multiple bytes. There are two different formats,
called "Little Endian and Big Endian."

"Little Endian" means that the least significant byte is stored in the lowest address of memory and the most significant byte in the highest.

Thus, a 4-byte Long Int
Byte2 Byte3 Byte1 Byte0

be stored in memory as follows:
Base Address +0 ===> Byte0
Base Address +1 ===> Byte1
Base Address +2 ===> Byte2
Base Address +3 ===> Byte3

Intel processors (used in most personal computers) and DEC Alpha RISC are "Little Endian."

In the format "Big Endian" the most significant byte is stored in the lowest address byte of memory and less weight in the highest address.
Int Long before, now would be stored as follows:

Base Address +0 ===> Byte3
Base Address +1 ===> Byte2
Base Address +2 ===> Byte1
Base Address +3 ===> Byte0

Most UNIX systems, the Internet protocol TCP, Motorola 680x0 processors (and, therefore, the Macintosh), Hewlett-Packard PA-RISC and Sun SuperSPARC are
"Big Endian". The MIPS processor Silicon Graphics and IBM / Motorola PowerPC are able to understand both systems, so they are said to be "bi-endian."

What order is best?

Because of the historical rivalry between the PC and Mac, the question of the ordination of bytes has been widely discussed. Both systems have
advantages and disadvantages that follow.

In the "Little Endian", the assembly instructions to choose 1, 2, 4 or a larger number of bytes from the same way: first reading the low byte, which is
in the offset (offset) 0.

In addition, the 1:1 ratio between the offset and the number of byte math routines causes are easier to implement.

In the "Big Endian", by having the most significant byte first, you can check directly if the number is positive or negative only checking the first
byte (remember that the sign is stored in the first bit) and without need to know the length of the number.
This form of representation matches the order in which the numbers are written, so the routines to convert between numbering systems are more efficient
than if undertaken in "Little Endian."

To know the different formats
When running a program, you may need to get it tell the difference between the two formats and act accordingly when you are using.

If you want a program to run on multiple platforms to be taken into account if they use the same format, and if different tailor the program to it.
Otherwise, if the binary files used the program does not work, taking the wrong values.

The TCP protocol uses the format "Big Endian", so that systems that use "Little Endian" to convert the data to create the TCP / IP.

The formats "Little Endian and Big Endian" can be applied in addition to the management of bytes, the management of bits.

In a byte, a system that uses "Little Endian" has the least significant bit in the first bit and bit more weight in the last bit. In a "Big Endian",
the high order bit will be in the first bit and the lowest weight in the past.

When applied to the management of both bytes and bits, taking advantage of each, we find systems that use the format "Big Endian" for the bytes and the
"Little Endian" for the management of internally bits each byte, or vice versa.

Change from one format to another
To change from one format to another, we can build a function to swap the bytes. The procedure is simple:
Original Format -> ABCD
Format Changed -> DCBA
Moreover, given the symmetry between them, serves the same function for spending "Little Endian" to "Big Endian" as "Big Endian" a "Little Endian."
void Swap (long int * a)
{
long int b0, b1, b2, b3;
b0 = (* a) &0x000000FF;
b1 = ((* a) & 0x0000FF00)>> 8;
b2 = ((* a) & 0x00FF0000)>> 16;
b3 = ((* a) & 0xFF000000)>> 24;
* A = (b0 <<24) | (b1 <<16) | (b2 <<8) | b3;
}

/ * More efficient version * /
void Intercambio2 (long int * a)
{
* A =(((* a) & 0x000000FF) <<24) | ((((* a) & 0x0000FF00)>> 8) <<16) | \
((((* A) & 0x00FF0000)>> 16) <<8) | (((* a) & 0xFF000000)>> 24);
}


N64 (Little Endian) simplemte this extention is to save the data with this sequence

If I want to keep this format n64: AA BB CC DD / / EE FF GG HH / / II JJ KK LL
What I do is this: AA BB CC DD / / EE FF GG HH / / II JJ KK LL

Not that easy because we do not understand yet another example
Original Format
Address / / Value
1000 ------ AA
------ 1001 BB
------ 1002 CC
DD ------ 1003

N64 Format
Address / / Value
1000 ------ DD
------ 1001 CC
------ 1002 BB
------ 1003 AA

And every change must be 4 by 4 just in case see the above screenshot which compare the 3 formats

V64 (Bytewapped): Like the other format is just save the information in this way

If I want to keep this format n64: AA BB CC DD / / EE FF GG HH / / II JJ KK LL
What I do is this: AA BB CC DD / / EE FF GG HH / / II JJ KK LL

Bone is changing the sequence of 2 values, another example xD

Original Format
Address / / Value
1000 ------ AA
------ 1001 BB
------ 1002 CC
DD ------ 1003

V64 Format
Address / / Value
1000 ------ BB
------ 1001 AA
DD ------ 1002
------ 1003 CC

Note that the values are exchanged 2 by 2 to analyze the image above to see the difference

Z64 (Big Endian) simplemte this extention is to save the data in its original form without changing the sequence or anything like that

If I want to keep this format n64: AA BB CC DD / / EE FF GG HH / / II JJ KK LL
What I do is this: AA BB CC DD / / EE FF GG HH / / II JJ KK LL

Nothing fancy, so this extension is the most recommended for hackroms and the like for easy editing, but in any case there hexadecimal editors
automatically rearrange the alignment of bytes if you specify them and when I talk about alignment byte bytewapped I mean, Little and big endian<br>

Z64N64V64.png

Internal programming Roms

We continue with the explanation entendimo now that it's the extensions, now the question arises where the Roma language are scheduled? because the
response is in MIPS Assembler because if they read a little history of the console, the console processor is a 64-bit MIPS

The creators of the emulators are familiar with the MIPS language and what they do is emulate a virtual console that recognizes that format, like
Microsoft windows EXE for use MASM Assembler, remember that not a single assembler language are many and each with a different syntax

To see such as the MIPS assembler will show you a picture, using the display command Nemu64 and the other with a program called ELF Mutilator 

InternalprogVII.jpg

I hope it helps or informs someone someday. Also for people who may still not understand how v64, z64, and n64 are different (Check image if you don't)
it basically is the difference from n64, z64, and v64 are that the bytes are switched around. Say you have rom.z64 in the title for example in a hex
editor the bytes will be correctly matched to resemble a ACII value of the rom's internal name. Let's say it's ROM EXAMPLE, okay so if we look at it if
it's in .v64 format it would be like MEXAEOL PMR or something, then in n64 it will be a little bit closer like REM OMXALEP or something.