new to the 6502 of things

[BigEd]

Somehow I was reminded of a manual for an apple ii program which I think does a good job of introducing machine code and assembly language programming. See this previous thread:
The Visible Computer - 6502

The manual is here (pdf).

Perhaps also see this other previous thread:
Best way to start learning 6502 Assembler

Keep trying: you will find that the lightbulb will come on, at some point, and things will make sense.

[barrym95838]

That "MACHINE LANGUAGE FOR BEGINNERS" book has an intended audience -- hobbyists who already know BASIC and their machine fairly well. If you aren't in that group, then a bit of confusion is certainly understandable, even for a sharp guy like yourself. Congratulations on your pending arrival! Plan for some late nights with that one.

[oscilloscope]

so i have taken on board the recommendations , but some one them e reads are mainly for the apple from what i can make out. ,

I'm gravitating toward the commodore / vic / c64 etc. i have again hit a learning wall again so i bought another book! this time 6502 machine language , for beginners it has quite abit of humour within it which was quite nice to read although I'm not if it was meant to be funny in places .. anyway i engaging a page regarding the following
7 6 5 4 3 2 1 0
MSB <<<< >>>> LSB
1 0 1 1 0 1 0 0

ok so the book then starts talking about "high order byte" & "lower order byte" , but doesn't really explain what they are and how to work out from the example above which is actually from the book. i have attempted to read up on it from various places but its not really explaining how to work them out...

now my theory is it whatever half adds up to the most out of decimal value , is that the high order byte too? or am i barking up the wrong tree.?

[BigDumbDinosaur]

oscilloscope wrote:

now my theory is it whatever half adds up to the most out of decimal value , is that the high order byte too? or am i barking up the wrong tree.?

Suppose you have the number 1234 sitting in memory. A memory cell can only hold 0-255, so the number is stored in two pieces. In the case of 1234, the first or lower memory cell will contain 210. The second or higher memory cell will contain 4. The number would be interpreted as 4 × 256 + 210. This is a universal idiom with the 6502 family, in which 4 is the high order byte or most significant byte, and 210 is the low order byte or least significant byte.

As you can see, numbers that exceed 255 are stored "backwards" in memory in multiple pieces. We call the backwards storage method "little-endian."

In hexadecimal, 1234 would be represented as $04D2, the dollar sign indicating that this is a hexadecimal value. Within that number, $D2 is the least significant byte and $04 is the most significant byte.

[oscilloscope]

BigDumbDinosaur wrote:

oscilloscope wrote:

now my theory is it whatever half adds up to the most out of decimal value , is that the high order byte too? or am i barking up the wrong tree.?

Suppose you have the number 1234 sitting in memory. A memory cell can only hold 0-255, so the number is stored in two pieces. In the case of 1234, the first or lower memory cell will contain 210. The second or higher memory cell will contain 4. The number would be interpreted as 4 × 256 + 210. This is a universal idiom with the 6502 family, in which 4 is the high order byte, or most significant byte, and 210 is the low order byte or least significant byte.

As you can see, numbers that exceed 255 are stored "backwards" in memory in multiple pieces. We call the backwards storage method "little-endian."

In hexadecimal, 1234 would be represented as $04D2, the dollar sign indicating that this is a hexadecimal value. Within that number, $D2 is the least significant bye and $04 is the most significant byte.

oh my , so here goes . I have just watched a video on big & little endian. now its got me thinking , so little-endian flips the bits backwards so there high bits are on the left... apposed to the right , so it the cells add up to the high end side of the >>> 7 , 6 , 5 , 4 , 3 , 2 , 1 , 0
and i fathom the 6502 runs on little-endian binary notation ? i know i have repeated some of what you said but i think its sinking in slowly. and the brain is flexing and it feels good to learn...

now that being said so the high side would be the most significant bit? as is its in little-endian?

[GARTHWILSON]

oscilloscope wrote:

so little-endian flips the bits backwards so there high bits are on the left... opposed to the right

No; bit order within a byte is still normal, but when you have the two bytes of an address, the low byte comes first, and then the high byte. There's an explanation of why this helps performance, near the end of the memory-map-requirements page of the 6502 primer, at http://wilsonminesco.com/6502primer/MemMapReqs.html, following the heading "Low Byte First." Do go through the whole 6502 primer if you have not already. It was written to address questions and problems and kept coming up on the forum. It has 22 pages arranged in a logical order, and I try to keep the links current and keep making updates as the need arises.

[oscilloscope]

GARTHWILSON wrote:

oscilloscope wrote:

so little-endian flips the bits backwards so there high bits are on the left... opposed to the right

No; bit order within a byte is still normal, but when you have the two bytes of an address, the low byte comes first, and then the high byte. There's an explanation of why this helps performance, near the end of the memory-map-requirements page of the 6502 primer, at http://wilsonminesco.com/6502primer/MemMapReqs.html, following the heading "Low Byte First." Do go through the whole 6502 primer if you have not already. It was written to address questions and problems and kept coming up on the forum. It has 22 pages arranged in a logical order, and I try to keep the links current and keep making updates as the need arises.

I just large question all written out as i was trying to make sense of the big & little endian notations and byte order etc , and i think i had a light bulb moment. although i could be very wrong.

so big-endian is written positional numbering notation like 1 ,2 ,3 ,4, ,5 etc little endian is reversed 5 , 4 , 3 , 2 , 1 , appreciate that is not a to scale of binary and hex i'm just trying to make sense of it all. i feel i am close. , and the least significate bit would be 5 on big endian ? , and the most sign most significate bit on little endian is 1 ?
all?

i did get a little confused from the page you linked me and jumping from 3-4 different places to make sense of the notations.

[barrym95838]

oscilloscope wrote:

i feel i am close. , and the least significate bit would be 5 on big endian ? , and the most sign most significate bit on little endian is 1 ?

I think you're very close, but you're incorrectly fixating on bits instead of bytes. Read BDD's example above very carefully again.

There was another twist when 16-bit processors got into the mix (see middle-endian or The NUXI problem), but you probably don't need to dig that deeply to gain a working understanding.

[BigDumbDinosaur]

barrym95838 wrote:

There was another twist when 16-bit processors got into the mix (see middle-endian or The NUXI problem), but you probably don't need to dig that deeply to gain a working understanding.

I have to mildly admonish you not to add to his confusion with the NUXI problem. It's not applicable to a 65(C)02 system, so better if we keep it out of the discussion.

[BigDumbDinosaur]

oscilloscope wrote:

so big-endian is written positional numbering notation like 1 ,2 ,3 ,4, ,5 etc little endian is reversed 5 , 4 , 3 , 2 , 1 , appreciate that is not a to scale of binary and hex i'm just trying to make sense of it all. i feel i am close. , and the least significate bit would be 5 on big endian ? , and the most sign most significate bit on little endian is 1 ?

As Garth said, endianess has nothing to do with bits, only bytes. Please reread my earlier explanation and DO NOT THINK IN TERMS OF BITS!

[oscilloscope]

BigDumbDinosaur wrote:

barrym95838 wrote:

There was another twist when 16-bit processors got into the mix (see middle-endian or The NUXI problem), but you probably don't need to dig that deeply to gain a working understanding.

I have to mildly admonish you not to add to his confusion with the NUXI problem. It's not applicable to a 65(C)02 system, so better if we keep it out of the discussion.

i may explode

[oscilloscope]

BigDumbDinosaur wrote:

oscilloscope wrote:

now my theory is it whatever half adds up to the most out of decimal value , is that the high order byte too? or am i barking up the wrong tree.?

Suppose you have the number 1234 sitting in memory. A memory cell can only hold 0-255, so the number is stored in two pieces. In the case of 1234, the first or lower memory cell will contain 210. The second or higher memory cell will contain 4. The number would be interpreted as 4 × 256 + 210. This is a universal idiom with the 6502 family, in which 4 is the high order byte or most significant byte, and 210 is the low order byte or least significant byte.

As you can see, numbers that exceed 255 are stored "backwards" in memory in multiple pieces. We call the backwards storage method "little-endian."

In hexadecimal, 1234 would be represented as $04D2, the dollar sign indicating that this is a hexadecimal value. Within that number, $D2 is the least significant byte and $04 is the most significant byte.

I have read it over and over again.... so i have some questions....

So memory cell 1 has 210. memory cell 2 has 4. so why times 4 x 256 --- ? is it because 4 is half of the 8 bits :shugs: , and 256 is becauseeee 0-255 can hold in a memory cell.?

so is the higher memory cell (2) is that because its physically higher in the number chain?

so little endian is backwards.... which I'm understanding slowly at a snail pace....

ah man its harder then i thought i think

[GARTHWILSON]

oscilloscope wrote:

So memory cell 1 has 210. memory cell 2 has 4. so why times 4 x 256 --- ? is it because 4 is half of the 8 bits :shugs: , and 256 is becauseeee 0-255 can hold in a memory cell.?

so is the higher memory cell (2) is that because its physically higher in the number chain?

Suppose you put your 16-bit (2-byte) number at address 0001 and 0002 (since you mention "memory cell 1" and "memory cell 2" above). Your 1234, in base ten, is $4D2 in hexadecimal. It's not clear if you understand the hexadecimal number base ("hex" for short); but it's basically the same thing as binary but made easier to handle because we group binary digits (bits) in sets of four so there aren't so many digits. One hex digit corresponds exactly to four binary digits. The $4D2 works out this way when compared to the binary number:

Code: Select all

   4    D    2
 0100 1101 0010

Hex makes it easier than decimal to see certain patterns when we're dealing with things like address ranges for address decoding.

The $4D2 goes into your two memory locations this way:

Code: Select all

Memory address 0001 holds the $D2 which is 11010010 in binary.
Memory address 0002 holds the   4 which is 00000100 in binary.

[oscilloscope]

GARTHWILSON wrote:

oscilloscope wrote:

So memory cell 1 has 210. memory cell 2 has 4. so why times 4 x 256 --- ? is it because 4 is half of the 8 bits :shugs: , and 256 is becauseeee 0-255 can hold in a memory cell.?

so is the higher memory cell (2) is that because its physically higher in the number chain?

Suppose you put your 16-bit (2-byte) number at address 0001 and 0002 (since you mention "memory cell 1" and "memory cell 2" above). Your 1234, in base ten, is $4D2 in hexadecimal. It's not clear if you understand the hexadecimal number base ("hex" for short); but it's basically the same thing as binary but made easier to handle because we group binary digits (bits) in sets of four so there aren't so many digits. One hex digit corresponds exactly to four binary digits. The $4D2 works out this way when compared to the binary number:

Code: Select all

   4    D    2
 0100 1101 0010

Hex makes it easier than decimal to see certain patterns when we're dealing with things like address ranges for address decoding.

The $4D2 goes into your two memory locations this way:

Code: Select all

Memory address 0001 holds the $D2 which is 11010010 in binary.
Memory address 0002 holds the   4 which is 00000100 in binary.

i do have a tendency to over think things and assume something is far more difficult when it comes to learning things , i have stuck with binary as it makes sense.. well sort of, i still need the 128 , 64 , 32 etc etc to hover around when i am understanding it, i work it out in binary then change it to hex..

i do hope it clicks soon , the whole odd way the RAM numbering locations , is a whole different head ache i'm not looking forward too.

[GARTHWILSON]

oscilloscope wrote:

i do have a tendency to over think things and assume something is far more difficult when it comes to learning things , i have stuck with binary as it makes sense.. well sort of, i still need the 128 , 64 , 32 etc etc to hover around when i am understanding it, i work it out in binary then change it to hex..

Once you know what it's all about, it's ok to use a calculator function to do the conversions—just as we require kids to know how to do multiplication and long division by hand, and once they understand it well, it's ok to let them use a calculator. Converting between hex and decimal, especially 16 or more bits, is pretty tedious to do by hand. I just reach for my HP-41cx calculator/computer and use its built-in conversion functions. I don't know what others on the forum are using, but I don't think anyone is doing it by hand.

You mentioned using the C64. One of our kids used it extensively with GEOS to write reports 'n' stuff in junior high, but I never got familiar with it. I do remember however that its BASIC only let the user deal with numbers in decimal, which I never could figure out, since certain things are easier in hex and it had to convert internally anyway.