It is currently Thu Nov 23, 2017 10:54 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Jan 20, 2017 4:19 pm 
Offline

Joined: Fri Jan 20, 2017 3:12 pm
Posts: 2
lidnariq wrote:
No, because the instruction pointer already points to $D000 by the time the offset is going to be added. (Hence why relative branches have an effective displacement of -126 to +129 bytes)


Thank you!


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 6:21 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
lidnariq wrote:
No, because the instruction pointer already points to $D000 by the time the offset is going to be added. (Hence why relative branches have an effective displacement of -126 to +129 bytes)

Yes. Cycle 3 is the answer.
Code:
CFFE  F0 05     BEQ $D005
    #   address  R/W description
       --- --------- --- ---------------------------------------------
        1     PC      R  fetch opcode, increment PC
        2     PC      R  fetch operand, increment PC
        3     PC      R  Fetch opcode of next instruction,
                         If branch is taken, add operand to PCL.
                         Otherwise increment PC.
        4+    PC*     R  Fetch opcode of next instruction.
                         Fix PCH. If it did not change, increment PC.
        5!    PC      R  Fetch opcode of next instruction,
                         increment PC.

So, right, PC is at $D000 when adding the operand byte.


Last edited by Zepper on Fri Jan 20, 2017 7:17 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 6:35 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6450
Location: UK (temporarily)
You know how I was talking about a language barrier before?

Here's his question, emphasis mine:
blashyrk wrote:
Shouldn't an extra cycle be added at this point because we're branching from CFFE -> D005?


Please reread his question and my answer until you understand that I answered the question correctly.


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 7:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
lidnariq wrote:
Please reread his question and my answer until you understand that I answered the question correctly.

Did I answer incorrectly? I edited slightly my post to be crystal clear.


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 10:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19254
Location: NE Indiana, USA (NTSC)
Think of it this way: Look at the address of the opcode that would be executed if the branch were not taken. If the taken and not-taken opcode are in the same page, there is no page crossing penalty cycle.

In the present case of a branch at $CFFE, this not-taken instruction is at $D000. The taken instruction is $D005, which is in the same page as $D000.


Top
 Profile  
 
PostPosted: Sun Oct 15, 2017 3:31 pm 
Offline

Joined: Sun Oct 15, 2017 3:22 pm
Posts: 3
I am also sorry but I must resurrect this thread. There is something that I simply don't get.

I have been using this log to run my CPU through some tests and I actually don't understand at all what is happening to the "log registers" whenever it calls PHP followed by PHA.

If you look at line 73, the accumulator is set with the value 0x7F. Two lines before, it uses PHP when the Status Register is set at 0x6F, and just after it calls immediately PLA, which is supposed to pull back the same value (0x6F) and store it into the Accumulator...no ?
Unless PHP or PLA are supposed to modify the value in question, is there someone who can explain to me why the log is specifying the value 0x7F for the accumulator in this very specific line ?

EDIT : Same pattern for lines 82/83/84. Stores 0x64, retrieve 0x74. Each time the original value is met again by the use of AND instruction.


Last edited by Rational on Sun Oct 15, 2017 3:35 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Oct 15, 2017 3:33 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6450
Location: UK (temporarily)
nesdevwiki:CPU status flag behavior


Top
 Profile  
 
PostPosted: Sun Oct 15, 2017 3:37 pm 
Offline

Joined: Sun Oct 15, 2017 3:22 pm
Posts: 3
lidnariq wrote:


Thank you so much dude. I never saw it specified elsewhere before.


Top
 Profile  
 
PostPosted: Sun Oct 15, 2017 3:38 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6450
Location: UK (temporarily)
Is there another place we could put that information that would have helped you find it on your own?


Top
 Profile  
 
PostPosted: Sun Oct 15, 2017 3:48 pm 
Offline

Joined: Sun Oct 15, 2017 3:22 pm
Posts: 3
lidnariq wrote:
Is there another place we could put that information that would have helped you find it on your own?


No it is put in the right place. The thing is I already read this page before but it was for another reason. I completely forgot about these lines talking about PHP and BRK.

Usually I use this http://www.obelisk.me.uk/6502/reference.html or the Levanthal's 6502 book.

Once again thank you for your quick help :D


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 10 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