Pipelined 6502

[GARTHWILSON]

manili wrote:

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.

Quote:

- 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.

[manili]

GARTHWILSON wrote:

manili wrote:

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.

Quote:

- 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.

[Arlet]

The MCS6500 Family Programming Manual says on page 144:

Quote:

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:

Quote:

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.

[manili]

Arlet wrote:

The MCS6500 Family Programming Manual says on page 144:

Quote:

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 ?

[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.

[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.

[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.

[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.

[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.

[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

[GARTHWILSON]

manili wrote:

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.

[KC9UDX]

BigEd wrote:

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.

[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.

[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.

[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 ?