Page 5 of 7
Re: Pipelined 6502
Posted: Mon Oct 17, 2016 7:50 pm
by GARTHWILSON
Hi all,
I have done the BRK and RTI instructions. And now I can say implementing other instructions, is somewhat straightforward and I think it's going to be finished until to night. My processor has still no way to handle external interrupts.
Two questions :
- After BRK, should I push B and I flags on to the stack, because they are both 1 ?
BRK is not affected by the interrupt-disable bit; so "I" could be either 0 or 1 when BRK is encountered in the program and executed. The processor status gets pushed onto the stack. along with the 1 in the position of the B bit which does not physically exist in the status register. The I bit is set during the interrupt sequence; but that does not change the status byte that gets pushed.
- After RTI, should I pop B and I flags off the stack, because maybe they are turned off during interrupt handling ?
RTI restores the status that was pushed during the interrupt sequence. Again, there is no B bit in the processor status register. It's just a bit position that gets used when pushing the status. In the case of IRQ\ hardware interrupts, the I bit had to be clear when the interrupt hit, so normally the RTI would restore the I bit as 0; but you can change the status byte record on the stack in the ISR, before reaching the RTI. The way to do that is typically PLA, AND#/ORA#, PHA.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 11:57 am
by manili
Hi all,
I have done the BRK and RTI instructions. And now I can say implementing other instructions, is somewhat straightforward and I think it's going to be finished until to night. My processor has still no way to handle external interrupts.
Two questions :
- After BRK, should I push B and I flags on to the stack, because they are both 1 ?
BRK is not affected by the interrupt-disable bit; so "I" could be either 0 or 1 when BRK is encountered in the program and executed. The processor status gets pushed onto the stack. along with the 1 in the position of the B bit which does not physically exist in the status register. The I bit is set during the interrupt sequence; but that does not change the status byte that gets pushed.
- After RTI, should I pop B and I flags off the stack, because maybe they are turned off during interrupt handling ?
RTI restores the status that was pushed during the interrupt sequence. Again, there is no B bit in the processor status register. It's just a bit position that gets used when pushing the status. In the case of IRQ\ hardware interrupts, the I bit had to be clear when the interrupt hit, so normally the RTI would restore the I bit as 0; but you can change the status byte record on the stack in the ISR, before reaching the RTI. The way to do that is typically PLA, AND#/ORA#, PHA.
Hi Garth,
Thanks for the answer. My ISA reference is "MCS6500 Family Programming Manual" which is somewhat different with what you are talking about ( I think ). Because as far as I understood the B flag is a real one and is set after BRK instruction. Would you mind take a look at
the book , maybe there are something that I misunderstood.
BTW thanks a lot for the REPLY

.
P.S. : Currently all of instructions have been implemented successfully (except BIT) . But there are some problems with synthesizing and I'm working hard to solve them.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 12:02 pm
by Arlet
The MCS6500 Family Programming Manual says on page 144:
In order to know whether the vector was fetched in response to an interrupt or in response to a BRK instruction, the B flag is stored on the stack, at stack pointer plus 1, containing a one in the break bit position, indicating the interrupt was caused by a BRK instruction
It also says on page 27:
This bit should be considered to have meaning only during an analysis of a normal interrupt sequence. There are no instructions which can set or which reset this bit.
By the way, if you look at the
copy on this site, then the pdf allows searching for BRK throughout the document.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 12:05 pm
by manili
The MCS6500 Family Programming Manual says on page 144:
In order to know whether the vector was fetched in response to an interrupt or in response to a BRK instruction, the B flag is stored on the stack, at stack pointer plus 1, containing a one in the break bit position, indicating the interrupt was caused by a BRK instruction
By the way, if you look at the
copy on this site, then the pdf allows searching for BRK throughout the document.
Thanks a lot Arlet. So this means/shows that the B flag is a physical one, isn't it ?
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 12:13 pm
by Arlet
In the NMOS 6502 the B flag is not a real one (I've edited my post to show another quote from page 27). It cannot be set or cleared, and there's no direct way to test it. If you do a BRK, and then immediately check the flags (PHP followed by PLA), you'll see the bit cleared.
Only when the flags are pushed to the stack, during handling of a BRK instruction, is the '1' OR-ed to the write.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 12:19 pm
by BigEd
Maybe this will help: There's a bit in the pushed value of the status, but there is no bit in the status register.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 4:14 pm
by KC9UDX
In perfect theory, the B flag is real and does exactly what it should.
It is always 1 except when BRK is executing. Therefore, it is always 1 whenever you try to read or test it, because you can't read or test the status register with a BRK instruction.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 4:28 pm
by BigEd
There are certainly different ways to think about it, and it would be nice to have some way which is both simple and correct! But because it's impossible to store a zero in that position, and since we know from visual6502 that there is no latch which holds a value for that position, we say that there is no B bit in the status register.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 5:31 pm
by KC9UDX
Impossible to store a zero? I thought it was always zero. Or is it always one? I guess I'd know if I ever actually used it.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 5:47 pm
by BigEd
It's a one. If you push 00 and pull it into the status register, then push that value and take a look, you'll see it's turned into $30, because of the two missing bits which act as 1s.
LDX #$00
TXA
PHA
PLP
PHP
DEX
TXA
PLA
TXA
PHA
PLP
PHP
INX
TXA
PLA
NOP
See this simulation:
http://www.visual6502.org/JSSim/expert. ... 08e88a68ea
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 6:32 pm
by GARTHWILSON
Hi Garth,
Thanks for the answer. My ISA reference is "MCS6500 Family Programming Manual" which is somewhat different with what you are talking about ( I think ). Because as far as I understood the B flag is a real one and is set after BRK instruction. Would you mind take a look at
the book , maybe there are something that I misunderstood.
It refers to the B bit; but again, it's only in the stacked status byte, not in the processor's status register. This is covered in my
6502 interrupts primer, in the
BRK section.
Re: Pipelined 6502
Posted: Tue Oct 18, 2016 7:55 pm
by KC9UDX
It's a one. If you push 00 and pull it into the status register, then push that value and take a look, you'll see it's turned into $30, because of the two missing bits which act as 1s.
OK thanks. After some thought I did know this, and should have had it right to begin with. I did correct my post.
Re: Pipelined 6502
Posted: Sat Oct 22, 2016 8:16 pm
by manili
Hi all,
After all, I finally found a way to synthesize the core. Does anybody know how to get the report of maximum possible frequency from Quartus II ? I don't have any board/FPGA to test the core but I want to know my processor max clock speed.
Thanks a lot.
P.S. : I'll publish the pre-release version till Friday.
Re: Pipelined 6502
Posted: Sun Oct 23, 2016 4:05 am
by MichaelM
Congratulations. Cannot help with Quartus; have never used it. Someone here has used it will likely post something soon. You can also try the Altera forums.
Re: Pipelined 6502
Posted: Tue Oct 25, 2016 5:38 pm
by manili
Hi all,
I finally decided to use PlanAhead 14.7 to synthesize the core. However the result of synthesis process is varied between 123.24 MHz - 159.5 MHz.
Below is the result of synthesis which targeted Artix-7 + some changes to defaults of PlanAhead synthesis process, like "-ram_style block", "-opt_level 2" :
Code: Select all
Minimum period: 8.114ns (Maximum Frequency: 123.247MHz)
Minimum input arrival time before clock: 9.190ns
Maximum output required time after clock: 0.911ns
Maximum combinational path delay: No path found
Since I'm not an experienced FPGA designer, I want to know what do you think about these results, is the core fast enough ?