It is currently Fri Aug 23, 2019 2:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Wed Jul 24, 2019 10:55 am 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 31
tepples wrote:
In C, C++, Java, and Python:
  • & means bitwise AND, which considers each bit of the input values separately and outputs an integer with bits set where both corresponding input bits were set.
  • && means logical AND, which considers the input values as a whole: true if both are nonzero and false otherwise. In C and C++, the output value is 1 for true or 0 for false.

3 & 6 evaluates to 2, based on the binary values 0011 and 0110.
3 && 6 evaluates to 1, as both sides are nonzero.
2 & 5 evaluates to 0, based on the binary values 0010 and 0101.
2 && 5 evaluates to 1, as both sides are nonzero.

In addition, && doesn't even try to evaluate its second input if the first input is zero. This behavior is called "short-circuiting." So 0 & (1 / 0) is undefined behavior because of the division by zero, but 0 && (1 / 0) evaluates to zero because the division is never reached.

Further reading:

Thanks! That's very helpfull.

I made some progress! I have now about 20 CPU opcodes implemented. I however have some questions, (1) Instructions like ADC state that "the Zero Flag must be set if A = 0", does this automatically mean I have to unset it if a != 0 or do I not touch it at all if A != 0? (2)What does the stack look like? I mean in the way of adding things to it, is the stack in c++ terms like a vector of uint8_ts? Or does one stack push contain more than 8 bits of data? (3) E.g. do PHP and PHA push to the same stack or do they have their own stack location?


Top
 Profile  
 
PostPosted: Wed Jul 24, 2019 12:43 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21560
Location: NE Indiana, USA (NTSC)
I can't think of any 6502 instructions* that either set a flag or leave it unchanged based on a condition. If you read that a flag is "set if" some condition is true, there's an implied "or clear if not."

There is only one stack pointer S, which indexes the page at $0100-$01FF. PHP, PHA, JSR, and BRK** all push to the same stack, and PLP, PLA, RTS, and RTI all pop from it.


* The 65816 in the Super NES has rep and sep, but not 6502.
** Because handling of /IRQ and /NMI shares most of the machinery of the BRK instruction, most of what is written about BRK applies to them as well.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed Jul 24, 2019 2:55 pm 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 31
tepples wrote:
I can't think of any 6502 instructions* that either set a flag or leave it unchanged based on a condition. If you read that a flag is "set if" some condition is true, there's an implied "or clear if not."

There is only one stack pointer S, which indexes the page at $0100-$01FF. PHP, PHA, JSR, and BRK** all push to the same stack, and PLP, PLA, RTS, and RTI all pop from it.


* The 65816 in the Super NES has rep and sep, but not 6502.
** Because handling of /IRQ and /NMI shares most of the machinery of the BRK instruction, most of what is written about BRK applies to them as well.

Thanks, I'll adjust my code to clear them when not set.

Just to be sure about the stack pointer thing, if I do PHP and then PHA, the they would be behind each other on stack, so first the value PHP pushed, then 8 bits later, the PHA value. So it is possible to read them back in the right registers, but you have to do it in reverse. So first PLA and then PLP. This also means it is possible to incorrectly load them right? So PLP on a value that was written with PHA.
If this is true, isn't this very annoying for programmers, since they have to make sure that they read the values back in the correct order, or things get funky.(Unless that is what the intend ofcourse).

Also, am I correct the JSR instruction also pushes the program counter to the same stack?(meaning one has to be careful when calling RTS, because previous written stack stuff has to be popped first by e.g. PLP if it was written with PHP)

Edit:
Also, I don't know if this is a stupid question, but does the ROM/program itself decide where to place it's stack and make sure it's free of interference with other variables, or is it something the processor has an assigned spot for?


Top
 Profile  
 
PostPosted: Wed Jul 24, 2019 10:20 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21560
Location: NE Indiana, USA (NTSC)
timl132 wrote:
tepples wrote:
There is only one stack pointer S, which indexes the page at $0100-$01FF. PHP, PHA, JSR, and BRK** all push to the same stack, and PLP, PLA, RTS, and RTI all pop from it.

Just to be sure about the stack pointer thing, if I do PHP and then PHA, the they would be behind each other on stack, so first the value PHP pushed, then 8 bits later, the PHA value. So it is possible to read them back in the right registers, but you have to do it in reverse. So first PLA and then PLP. This also means it is possible to incorrectly load them right? So PLP on a value that was written with PHA.

Correct. It's also very common to do two PHA then an RTS as a way of jumping through a jump table. See "RTS Trick" on the wiki.

timl132 wrote:
Also, am I correct the JSR instruction also pushes the program counter to the same stack?

Yes. That's what I meant by "PHP, PHA, JSR, and BRK all push to the same stack."

timl132 wrote:
does the ROM/program itself decide where to place it's stack and make sure it's free of interference with other variables, or is it something the processor has an assigned spot for?

Both. The processor has a designated 256-byte area in memory for the stack, but the TXS instruction tells the processor where to start the stack within that area. The stack is always in $0100-$01FF, but many programs will put the stack in one part of $0100-$01FF and other variables in another part of $0100-$01FF. Your homework is to find all the 6502 references you can find through a web search and read carefully the description of what TXS, PHA, and PLA do.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed Jul 24, 2019 10:40 pm 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 31
tepples wrote:
timl132 wrote:
tepples wrote:
There is only one stack pointer S, which indexes the page at $0100-$01FF. PHP, PHA, JSR, and BRK** all push to the same stack, and PLP, PLA, RTS, and RTI all pop from it.

Just to be sure about the stack pointer thing, if I do PHP and then PHA, the they would be behind each other on stack, so first the value PHP pushed, then 8 bits later, the PHA value. So it is possible to read them back in the right registers, but you have to do it in reverse. So first PLA and then PLP. This also means it is possible to incorrectly load them right? So PLP on a value that was written with PHA.

Correct. It's also very common to do two PHA then an RTS as a way of jumping through a jump table. See "RTS Trick" on the wiki.

timl132 wrote:
Also, am I correct the JSR instruction also pushes the program counter to the same stack?

Yes. That's what I meant by "PHP, PHA, JSR, and BRK all push to the same stack."

timl132 wrote:
does the ROM/program itself decide where to place it's stack and make sure it's free of interference with other variables, or is it something the processor has an assigned spot for?

Both. The processor has a designated 256-byte area in memory for the stack, but the TXS instruction tells the processor where to start the stack within that area. The stack is always in $0100-$01FF, but many programs will put the stack in one part of $0100-$01FF and other variables in another part of $0100-$01FF. Your homework is to find all the 6502 references you can find through a web search and read carefully the description of what TXS, PHA, and PLA do.

Sorry, I misread the JSR part.

Okay so there is a designated stack area, but the program decides where it starts in that area. So I'm assuming the stack pointer address is 8 bit so it can't go outside that stack range?

Quote:
our homework is to find all the 6502 references you can find through a web search and read carefully the description of what TXS, PHA, and PLA do.

I will, but the basics are that it takes a variable(e.g. X register), add's it to the stack, and moves the stack pointer right?


Top
 Profile  
 
PostPosted: Wed Jul 24, 2019 11:22 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
Okay, this behaviour needs to stop. Right now. Situations like this make me wish I hadn't rescinded my admin flag some years ago.

You've now had 4 separate people tell you to read resources, and all of us giving you links/advice on what to read; one was extremely nice in referring to it as "homework". I happen to be more brash than others.

I really couldn't care less if you don't like to read books/references -- your "learning limits" are not my responsibility/problem. In turn, what you're doing is sucking up people's time due to your refusal to read said materials. Saying "I will read them, but..." then proceeding to ask the question that would've been answered if you'd read said materials, is incredibly rude. I don't expect you to read back-to-back entire tomes, but do expect you to at least exert reasonable (read: more than minimal) effort in finding the answer yourself via said materials offered. Every question you've asked so far -- no exception -- is answered in those materials.

Everyone learns differently, but the materials we've given you are in fact good teaching materials (the book I mentioned previously actually reads quite nicely, and there's even an entire website and forum dedicated to the CPU -- 6502.org -- which is a fantastic repository of top-grade info) with factually accurate information. We understand you want to learn (and that's awesome), and have a goal of making a 6502/NES emulator (that's also cool), but please understand that by doing what you're doing, you're making some of us unwilling to answer future questions due to your unwillingness to use the resources we've provided. It borders on narcissistic behaviour -- not a good first impression.

I think once you've read said resources, or at least begin to get a feel for them via as reference guides, you'll begin to see how/why you can basically answer many of the more "basic" or "obvious" questions by yourself. After becoming a bit more educated with the CPU, I think you'll have lots of questions about certain behaviours (ADC/SBC is a good but common example) and similar complications, but more "basic" things like "so what do these opcodes do? How does the stack behave?" are completely covered by said materials.

In short: please don't abuse the human resources here on the forum. We are adults (almost all of us) with full-time jobs and lives. We have a passion for what we do on the forum, and we love helping, but we aren't going to feed you via silver spoon. Respectfully, please show some self-driven incentive for the more basic stuff -- we know it's new to you and not to us, but our time is as valuable as yours.


Top
 Profile  
 
PostPosted: Thu Jul 25, 2019 12:11 am 
Offline

Joined: Tue Jul 23, 2019 10:41 am
Posts: 31
koitsu wrote:
Okay, this behaviour needs to stop. Right now. Situations like this make me wish I hadn't rescinded my admin flag some years ago.

You've now had 4 separate people tell you to read resources, and all of us giving you links/advice on what to read; one was extremely nice in referring to it as "homework". I happen to be more brash than others.

I really couldn't care less if you don't like to read books/references -- your "learning limits" are not my responsibility/problem. In turn, what you're doing is sucking up people's time due to your refusal to read said materials. Saying "I will read them, but..." then proceeding to ask the question that would've been answered if you'd read said materials, is incredibly rude. I don't expect you to read back-to-back entire tomes, but do expect you to at least exert reasonable (read: more than minimal) effort in finding the answer yourself via said materials offered. Every question you've asked so far -- no exception -- is answered in those materials.

Everyone learns differently, but the materials we've given you are in fact good teaching materials (the book I mentioned previously actually reads quite nicely, and there's even an entire website and forum dedicated to the CPU -- 6502.org -- which is a fantastic repository of top-grade info) with factually accurate information. We understand you want to learn (and that's awesome), and have a goal of making a 6502/NES emulator (that's also cool), but please understand that by doing what you're doing, you're making some of us unwilling to answer future questions due to your unwillingness to use the resources we've provided. It borders on narcissistic behaviour -- not a good first impression.

I think once you've read said resources, or at least begin to get a feel for them via as reference guides, you'll begin to see how/why you can basically answer many of the more "basic" or "obvious" questions by yourself. After becoming a bit more educated with the CPU, I think you'll have lots of questions about certain behaviours (ADC/SBC is a good but common example) and similar complications, but more "basic" things like "so what do these opcodes do? How does the stack behave?" are completely covered by said materials.

In short: please don't abuse the human resources here on the forum. We are adults (almost all of us) with full-time jobs and lives. We have a passion for what we do on the forum, and we love helping, but we aren't going to feed you via silver spoon. Respectfully, please show some self-driven incentive for the more basic stuff -- we know it's new to you and not to us, but our time is as valuable as yours.

Okay. I understand what you are saying.
I will read the books and sources everyone here linked before asking further questions. Thanks.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group