ShenoxVII (in all seriousness, you're a prick) Level: 24      Posts: 35/111 EXP: 75917 For next: 2208 Since: 10-09-10 Since last post: 9.0 years Last activity: 9.0 years  |
|
||
| 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  (Thanks to my friend henry for details] 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  Well, this is a good bit of information to put on these forums, 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. |
 Register - Login |
||
|
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies |
|
