6502 branch offset calculation
Clash Royale CLAN TAG#URR8PPP
up vote
15
down vote
favorite
This question expands on How does the 6502 implement its branch instructions?
I'm working on a cycle accurate VHDL implementation on an FPGA. I have much of the program logic already written, but I can't wrap my head around how to logically calculate the relative addressing from the branch instructions.
From everything I've read and reviewed, the only outputs of the ALU are: result, alucout, and aluvout. I've read that the flag outputs from he ALU are routed to the control logic, even though it's not shown in the block diagram.
I built a truth table on several different scenarios for offsets, and it seems you can't just use carry and overflow to determine whether or not to carry to the high byte of the program counter. I even thought to move the bit 7 logic from the flags register logic to the alu, and route that to the control logic, but that wouldn't help either.
Some of the resources I've been using are:
Block Diagram
Visual 6502
Programming the 65816 - Has a section on the relative addressing in conditional branching
NESDev 6502 Text File
So to put all of this madness into a question... How is the (signed)offset calculated against the (unsigned)program counter, and how do you determine if you need to add a cycle to calculate the high byte of the program counter?
programming 6502 mos-650x microprocessor microcode
add a comment |Â
up vote
15
down vote
favorite
This question expands on How does the 6502 implement its branch instructions?
I'm working on a cycle accurate VHDL implementation on an FPGA. I have much of the program logic already written, but I can't wrap my head around how to logically calculate the relative addressing from the branch instructions.
From everything I've read and reviewed, the only outputs of the ALU are: result, alucout, and aluvout. I've read that the flag outputs from he ALU are routed to the control logic, even though it's not shown in the block diagram.
I built a truth table on several different scenarios for offsets, and it seems you can't just use carry and overflow to determine whether or not to carry to the high byte of the program counter. I even thought to move the bit 7 logic from the flags register logic to the alu, and route that to the control logic, but that wouldn't help either.
Some of the resources I've been using are:
Block Diagram
Visual 6502
Programming the 65816 - Has a section on the relative addressing in conditional branching
NESDev 6502 Text File
So to put all of this madness into a question... How is the (signed)offset calculated against the (unsigned)program counter, and how do you determine if you need to add a cycle to calculate the high byte of the program counter?
programming 6502 mos-650x microprocessor microcode
add a comment |Â
up vote
15
down vote
favorite
up vote
15
down vote
favorite
This question expands on How does the 6502 implement its branch instructions?
I'm working on a cycle accurate VHDL implementation on an FPGA. I have much of the program logic already written, but I can't wrap my head around how to logically calculate the relative addressing from the branch instructions.
From everything I've read and reviewed, the only outputs of the ALU are: result, alucout, and aluvout. I've read that the flag outputs from he ALU are routed to the control logic, even though it's not shown in the block diagram.
I built a truth table on several different scenarios for offsets, and it seems you can't just use carry and overflow to determine whether or not to carry to the high byte of the program counter. I even thought to move the bit 7 logic from the flags register logic to the alu, and route that to the control logic, but that wouldn't help either.
Some of the resources I've been using are:
Block Diagram
Visual 6502
Programming the 65816 - Has a section on the relative addressing in conditional branching
NESDev 6502 Text File
So to put all of this madness into a question... How is the (signed)offset calculated against the (unsigned)program counter, and how do you determine if you need to add a cycle to calculate the high byte of the program counter?
programming 6502 mos-650x microprocessor microcode
This question expands on How does the 6502 implement its branch instructions?
I'm working on a cycle accurate VHDL implementation on an FPGA. I have much of the program logic already written, but I can't wrap my head around how to logically calculate the relative addressing from the branch instructions.
From everything I've read and reviewed, the only outputs of the ALU are: result, alucout, and aluvout. I've read that the flag outputs from he ALU are routed to the control logic, even though it's not shown in the block diagram.
I built a truth table on several different scenarios for offsets, and it seems you can't just use carry and overflow to determine whether or not to carry to the high byte of the program counter. I even thought to move the bit 7 logic from the flags register logic to the alu, and route that to the control logic, but that wouldn't help either.
Some of the resources I've been using are:
Block Diagram
Visual 6502
Programming the 65816 - Has a section on the relative addressing in conditional branching
NESDev 6502 Text File
So to put all of this madness into a question... How is the (signed)offset calculated against the (unsigned)program counter, and how do you determine if you need to add a cycle to calculate the high byte of the program counter?
programming 6502 mos-650x microprocessor microcode
asked Aug 20 at 19:55


Evan
786
786
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
14
down vote
accepted
Quick shot, without looking it up in Visual 6502 (which would be the authorative option):
Sign extend the branch offset (replicate MSB of offset), that will tell you the ALU input for the PC high byte. Possible values are 0 and -1 (all 1s), these are available as constants.
Carry and sign of the branch offset together determine if an extra cycle is necessary (for carry and positive offset, or no carry and negative offset). That's a simple XOR.
The overflow flag shouldn't play a role.
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
1
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
 |Â
show 3 more comments
up vote
3
down vote
AFAIR it's Carry
XOR Sign
(of the offset).
If this yields true, it's increment when Carry
, otherwise decrement.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
Quick shot, without looking it up in Visual 6502 (which would be the authorative option):
Sign extend the branch offset (replicate MSB of offset), that will tell you the ALU input for the PC high byte. Possible values are 0 and -1 (all 1s), these are available as constants.
Carry and sign of the branch offset together determine if an extra cycle is necessary (for carry and positive offset, or no carry and negative offset). That's a simple XOR.
The overflow flag shouldn't play a role.
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
1
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
 |Â
show 3 more comments
up vote
14
down vote
accepted
Quick shot, without looking it up in Visual 6502 (which would be the authorative option):
Sign extend the branch offset (replicate MSB of offset), that will tell you the ALU input for the PC high byte. Possible values are 0 and -1 (all 1s), these are available as constants.
Carry and sign of the branch offset together determine if an extra cycle is necessary (for carry and positive offset, or no carry and negative offset). That's a simple XOR.
The overflow flag shouldn't play a role.
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
1
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
 |Â
show 3 more comments
up vote
14
down vote
accepted
up vote
14
down vote
accepted
Quick shot, without looking it up in Visual 6502 (which would be the authorative option):
Sign extend the branch offset (replicate MSB of offset), that will tell you the ALU input for the PC high byte. Possible values are 0 and -1 (all 1s), these are available as constants.
Carry and sign of the branch offset together determine if an extra cycle is necessary (for carry and positive offset, or no carry and negative offset). That's a simple XOR.
The overflow flag shouldn't play a role.
Quick shot, without looking it up in Visual 6502 (which would be the authorative option):
Sign extend the branch offset (replicate MSB of offset), that will tell you the ALU input for the PC high byte. Possible values are 0 and -1 (all 1s), these are available as constants.
Carry and sign of the branch offset together determine if an extra cycle is necessary (for carry and positive offset, or no carry and negative offset). That's a simple XOR.
The overflow flag shouldn't play a role.
answered Aug 20 at 20:18
dirkt
6,8781738
6,8781738
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
1
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
 |Â
show 3 more comments
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
1
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Awesome! That was right on my truth table and I didn't even see it. Thank you!
– Evan
Aug 20 at 20:56
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
Jup, that's it. Except there's no sign extension, just constant selection
– Raffzahn
Aug 20 at 21:36
1
1
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@Raffzahn: Well, the constant selection implements the sign extension... (and without knowing it's a sign extension, the whole process wouldn't made sense).
– dirkt
Aug 21 at 5:41
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
@dirkt Still stays a constant selection, as a sign extension would mean that there is somewhere a circuit propagating the sign. Wouldn't it? And for his task, coding it as a sign extension could result in a different implementation, eventually less performing. The task is rather staying with the template.
– Raffzahn
Aug 21 at 9:05
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
"as a sign extension would mean that there is somewhere a circuit propagating the sign." No, it wouldn't. You are missing the point.
– dirkt
Aug 21 at 9:47
 |Â
show 3 more comments
up vote
3
down vote
AFAIR it's Carry
XOR Sign
(of the offset).
If this yields true, it's increment when Carry
, otherwise decrement.
add a comment |Â
up vote
3
down vote
AFAIR it's Carry
XOR Sign
(of the offset).
If this yields true, it's increment when Carry
, otherwise decrement.
add a comment |Â
up vote
3
down vote
up vote
3
down vote
AFAIR it's Carry
XOR Sign
(of the offset).
If this yields true, it's increment when Carry
, otherwise decrement.
AFAIR it's Carry
XOR Sign
(of the offset).
If this yields true, it's increment when Carry
, otherwise decrement.
answered Aug 20 at 21:33


Raffzahn
32.2k470128
32.2k470128
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7327%2f6502-branch-offset-calculation%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password