RTK's guide: Assembly in one step

[Laserbeak43]

Hi,
i'm reading http://nesdev.com/6502guid.txt and i have a couple of questions these were originaly parts of an email thread i started to someone who's been really nice to help me, but i think i might be able to cut him a bit of slack if i post on these boards(thanks blargg)

ok first thing i noticed was in the section about stack pointers in
the third section of the tutorial, not far from the beginning. it says
it keeps info about where to return to after a JSR is executed, and
that this info is kept in low memory from $0100 - $01FF, which is 256
- 511 in decimal format, right? so why does the next statement say,
"The stack grows down from $01FF and makes it possible to nest
subroutines up to 128 levels deep."

erm i'm not exactly sure if this is really 256, my math might be off,
but it's definately more than 128 isn't it? or is it that a subroutine
takes up-2 bits of memory a peice?



ok here's a tricky one, has to do with binary numbers, maybe it's been
a while but i cant remember this trick:

it talks about relative addressing then goes to say that:

If the
value is > $7F (negative) then it is the 2's compliment of the given
value in the negative direction.

i'll pastebin the section:
http://rafb.net/p/L9BOR095.html

why would 0000 0001 would make it -1?
is this just saying that it wraps around? if it's over 256?
and if so, what's the relation of this example to absolute addressing?

[Dwedit]

Whenever you JSR, the "return address" is two bytes, and that gets pushed onto the stack. Stack is 256 bytes large, so that's 128 nested calls.

[Laserbeak43]

Whenever you JSR, the "return address" is two bytes, and that gets pushed onto the stack. Stack is 256 bytes large, so that's 128 nested calls.

cool so i kinda guessed the first one right, thanks!!!

[Disch]

i'll pastebin the section:
http://rafb.net/p/L9BOR095.html

why would 0000 0001 would make it -1?

The way he words it is a little confusing. 2's compliment is actually very simple:

$00 = 0
$01 = 1
$02 = 2
...
$7E = +126
$7F = +127
$80 = -128
$81 = -127
$82 = -126
...
$FE = -2
$FF = -1


A way which might help you figure it out would be if the number is >= $80, subtract $100 from it

$FE = -2 .... because ..... $FE - $100 = -2

[Laserbeak43]

nice trick.
i'll have to keep that one in mind as i practice. i'm sure i'll have plenty of chances to work that out very soon.(opens up calc.exe)

-edit-
hmm...
$FE - $100 = 18446744073709551614, in calc.exe

i guess cause there's no number threshold for it to be aware of?

well, darn, FE isn't such a small number in windows calculator either!
in fact, it seems to be 256 bigger
lol man the noobs can make people have so much fun laughing at the obvious, can't we?!
hmmmmm

[Disch]

$FE - $100 = 18446744073709551614, in calc.exe :roll:

i guess cause there's no number threshold for it to be aware of?

it's because it treats everything as unsigned when in hex mode

1) enter hex mode
2) input FE
3) press -
4) input 100
5) switch to dec mode
6) hit =

result: -2

or input FE, switch to dec, then subtract 256. Either or.

[blargg]

With an unsigned value, expanding it to a larger number of bits means just adding zero bits on the left. 11111111 = 255. Expanding that to 16 bits gives 0000000011111111. With two's complement (also called signed since it can represent negative values), expanding to more bits is called sign extension, since you have to fill the upper bits with the sign bit (the top bit). 11111111 = -1. Expanding that to 16 bits gives 1111111111111111. That should make sense since all the bits have to be 1 to cause a 16-bit value to wrap around to one less. But if you have 01111111 = +127, expanding that to 16 bits gives 0000000001111111.

So, when using the hex calculator it's going to give you the result in however many bits it uses, so negative values will be very large. This is easy to deal with in hex since you just ignore the upper digits. FF = 255 (unsigned) or -1 (signed). FFFFFFFF = -1 (signed) as well.

[Laserbeak43]

$FE - $100 = 18446744073709551614, in calc.exe

i guess cause there's no number threshold for it to be aware of?

it's because it treats everything as unsigned when in hex mode

1) enter hex mode
2) input FE
3) press -
4) input 100
5) switch to dec mode
6) hit =

result: -2

or input FE, switch to dec, then subtract 256. Either or.

hmm coulda swore i was doing it right, but your way worked! thanks!

With an unsigned value, expanding it to a larger number of bits means just adding zero bits on the left. 11111111 = 255. Expanding that to 16 bits gives 0000000011111111. With two's complement (also called signed since it can represent negative values), expanding to more bits is called sign extension, since you have to fill the upper bits with the sign bit (the top bit). 11111111 = -1. Expanding that to 16 bits gives 1111111111111111. That should make sense since all the bits have to be 1 to cause a 16-bit value to wrap around to one less. But if you have 01111111 = +127, expanding that to 16 bits gives 0000000001111111.

So, when using the hex calculator it's going to give you the result in however many bits it uses, so negative values will be very large. This is easy to deal with in hex since you just ignore the upper digits. FF = 255 (unsigned) or -1 (signed). FFFFFFFF = -1 (signed) as well.

wow tricky stuff but i've already read this 2 or 3 times and it's becoming a bit clrearer. maybe if i review the whole thread it'll start to make more sense

[Disch]

another way (which is probably easier) would be to do -($100-$FE). $100 - $FE = 2, negate that and you have -2.

[tokumaru]

Programmatically, the easiest way to negate a byte is to XOR it with $FF (inverting all the bits: 1's become 0's and 0's become 1's) and then add 1.

Take the number 2, for example. In binary it is 00000010. After XOR'ing it with 11111111 you get 11111101. Add 1 and you get 11111110, which is $FE.

Converting it back works exactly the same: 11111110 XOR 11111111 = 00000001, 00000001 + 1 = 00000010, which is 2. You will sure need to do this once in a while when programming games.

In 6502 assembly, the instruction used to XOR is "EOR". Windows calculator uses "XOR", if you're willing to try it out.

[tepples]

In 6502 assembly, the instruction used to XOR is "EOR".

Other than 6502/65816 and ARM, does any CPU architecture's official datasheets use "EOR"?

[Laserbeak43]

Programmatically, the easiest way to negate a byte is to XOR it with $FF (inverting all the bits: 1's become 0's and 0's become 1's) and then add 1.

Take the number 2, for example. In binary it is 00000010. After XOR'ing it with 11111111 you get 11111101. Add 1 and you get 11111110, which is $FE.

Converting it back works exactly the same: 11111110 XOR 11111111 = 00000001, 00000001 + 1 = 00000010, which is 2. You will sure need to do this once in a while when programming games.

In 6502 assembly, the instruction used to XOR is "EOR". Windows calculator uses "XOR", if you're willing to try it out.

windows calc gives me 1 if i type 1110 xor 1111

just got 110 after trying 1001 xor 1111, i think it's returning the values in decimal format

[baisoku]

In 6502 assembly, the instruction used to XOR is "EOR".

Other than 6502/65816 and ARM, does any CPU architecture's official datasheets use "EOR"?

Not that i know of. ARM's Thumb instruction set uses EOR because Thumb is modeled after 6502.

[gannon]

just got 110 after trying 1001 xor 1111, i think it's returning the values in decimal format

Windows Calculator drops the leading 0s

[Laserbeak43]

just got 110 after trying 1001 xor 1111, i think it's returning the values in decimal format

Windows Calculator drops the leading 0s

gotcha, thanks.