retroben's n64 gameshark requests thread.
Just request for any kind of code you can think of and I will try to make it happen.

I just wish I actually understood hex, offsets, etc, then I'd actually be able to do cool hacks like you :D

Hexadecimals and you.
Elementary my dear Watson.
Hex numbers 0F 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12... Decimal numbers 09 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18... Additionally hex goes A0FF as well. Hex A0=160 (16 x 10 = 160) Decimal 160=160 Every tens place in hex equals sixteen. Hex 10=16 16=22 1A=26 20=32 (decimals 16+16=32) Decimal 10=10 16=16 20=20 22=22 26=26 32=32 Bits are in the same byte of an address. 8bits=1byte with ten placements. The bits are as follows. bit0? 0=0 neutral bit1 1=1 bit2 2=2 bit3 4=4 bit4 8=8 bit5 10=16 bit6 20=32 bit7 40=64 bit8 80=128 bit9? FF=255 maximum (256th number including zero) It can use any and every mixture of bits. Example:bits 6,5,and 3 20+10+4=34 (52 in decimal). 007F in hex are the positive numbers. 80FF in hex are the negative numbers. Couning down from FF. Examples: FF= 1 FE= 2 80= 127 (maximum negative) 7F= +127 (maximum positive) To think,I learned hex all on my own,not in school. 
Quote:

What kind of codes would you be looking for?

Quote:

You can search for decimal values in the memory debugger.
In fact, that's the default. You don't really need to know hexadecimal. If you view the raw memory in RDRAM though, then you need to understand hex. But, understanding base sixteen (i.e., hex), is pretty much the exact same as learning any other arithmetic base. It's Third Grade knowledge, in fact. This stuff (not hex directly its self) was in the books when I was like, 8: The decimal 666 is, in "extended notation", 6*(100) + 6*(10) + 6*(1). More scientifically, 6*(10^2) + 6*(10^1) + 6*(10^0). The base of each exponent is 10 because sonamed "decimal" means ten digits. If you already understand that then I think you pretty much already know hexadecimal. You just don't realize it. :D 
Quote:
You said 52 which is only half of 104 because you got the bit offsets wrong. First, there are only 8 bits in a byte, not 10. There's no "bit8" and "bit9". It's just bits 0 to 7, numbered littleendian. Second, bit 0 is NOT "neutral". 2 to the power of 0 is 1, not 0. So bit 0 means you mask  1, bit 1 means you mask  2, bit 2 means you mask  4, etc. all your values are off. :D Quote:
If it were a CPU besides MIPS/Intel it could be 1's complement negation, and negative numbers would not look exactly as you said. More over, for our purposes, either in hacking or otherwise, a "byte" in a memory viewer should always default to an "unsigned char" perspective in C, so rather than signextending it, we're better off initially interpreting memory results as zeroextended bytes in the range 0:+255, not 128:+127. Quote:
I had to begin with reading about it at first, though, initially, in an archive I downloaded. Otherwise, how do we know exactly which knowledge to pursue? 
Zero is neutral because it is neither negative or positive.
There is no negative zero. I know 8bits,ten positions make it decimal/hexadecimal. Hexadecimal means ten with additional six while hex means six. I may have bit positions wrong,but my values are correct. Every bit is multiples of two of the previous bit. 0 1 2 4 8 16 32 64 128 255 0 1 2 4 8 10 20 40 80 FF I forgot to realize that 80 in hex can be positive when used in half words (2 byte length). A perfect example is the universal Sega Genesis Sonic 1/2/3/K/3K games Ring Count Pro Action Replay code. Rings=127 FFFE20:007F Rings=128 FFFE20:0080 Rings=255 FFFE20:00FF Rings=256 FFFE20:0100 Rings=999 FFFE20:03E7 The two byted amounts will stay positive until after 7FFF. Rings=32767 (garbled counter) FFFE20:7FFF Values 80FF in one byte codes can sometimes still be positive when used in item counts. In physics based codes,80FF are negative. Running forward current speed is 32 (20 in hex). Using the Zelda OOT Press A to Run Fast cheat modified as an example. It might be two bytes long,which would need FFE0 for negative 32. Change 20 to E0 and you will run backwards at 32 speed when trying to run forward. Proof of zero being neutral,you will not move forward or backward with 0. 
I don't care.
Bit 0 is not neutral. It's a part of a byte, equally as much as every other bit. Bits in a byte are numbered 0 to 7, not 1 to 10 or whatever. So the correct answer was 104, not 52. Quote:
A halfword can easily be 1 single byte on systems you haven't hacked for yet. A halfword may also be 4 bytes or more for other systems. To specify a negative hex, you use the negative sign, just as you would in decimal. 0x80 is 128; +0x80 is +128. Most often, a single byte in computer science is interpreted as "unsigned"; meaning it's 0:255, not 128:+127. 0xFFFF could be either +65535 or 1 if the 16bit number is signed. It depends which N64 CPU instructions buffer the number from RDRAM and how the programmer chooses to read it. There is no universal rule of thumb that 0x8000:0xFFFF in 2 byte is ALWAYS a negative number, etc. 
All times are GMT. The time now is 01:34 PM. 
Powered by vBulletin® Version 3.7.3
Copyright ©2000  2018, Jelsoft Enterprises Ltd.