I've been working on a MOS 6502 core for an 8-bit NES core that I'm putting in a Xilinx 7-Series FPGA. My testbench combines a 64KB block memory with the CPU core. The block memory uses a couple of different input files to specify its initial contents. I had been doing initial programming manually ...

That's right. It's the joy of two's complement: the bit patterns do exactly the same in both cases. Which might also answer your question about overflow: the adder doesn't need to know or do anything about overflow, it just adds. The overflow bit is purely an additional output.

Ok, that helps a ...

Thanks Ed.


Two great resources on the 6502 overflow flag:
http://www.6502.org/tutorials/vflag.html
http://www.righto.com/2012/12/the-6502- ... ained.html


Yep, I've read through both of those. In fact, I used the table from Ken Shirriff's blog to help construct the logic for the overflow flag ...

Working on a 6502 ALU implementation and wanted to see if I could get another pair of eyeballs on my method of simulating overflow behaviour during an addition operation. In pseudocode, I was planning to use the following:


for A in range(0, 256):
for B in range(0, 256):
carry_in = 1
# Add with ...

Any '02 data sheet will have that info. For the NMOS 6502, see for example:
6500 Microprocessors (Preliminary) (May 1976) http://6502.org/documents/datasheets/mos/mos_6500_mpu_preliminary_may_1976.pdf

or for 65c02 (which I highly encourage you make your simulator for, because it is far superior to ...

Can you elaborate? I do not understand what you mean. Thank you.

The branch, jump, no-op, store, push, and RTS instructions won't affect the status. Something like INX or PLX will make the status apply to the new X register value, while INY or PLY will make the status apply to the new Y register value. Something like INC <absolute> will make it reflect the new ...

My thought was to use an 8-bit mask of some sort to determine what the new value of the P register should be based upon the mask and the value to be stored in the accumulator - then combinatorially generate a new value for the P register that gets registered in at the same time as the accumulator ...

So I've had to uproot and redo a lot of what I had done earlier because I didn't have a sophisticated enough FSM to do more complex addressing modes. I'm sort of at a crossroads when it comes to updating processor status registers with results.

As an example, I am implementing absolute addressing ...

Yeah, I completely missed that in the instruction description - for some reason it completely escaped me that I needed to do something with the result. I suppose that's what I deserve working on code at 3:00 AM. I need to go back and modify some of my design now.

I may have answered my own question - the block diagram for the processor shows the ALU connected to an adder for some reason. Perhaps the ALU needed to use that to add something to the shifted result and then another clock cycle to register it back in the processor?

I've been working on my processor quite a bit over the last couple days and started implementing the ASL and LSR opcodes using absolute addressing mode. I observed that for other instructions that use the ALU (e.g., ADC) that mode takes 4 clock cycles to complete. Assuming that ASL and LSR are using ...

I've incorporated the ALU into my design and wrote a simple ROM to reset, do NOP, clear out the accumulator and start counting by 1. Now that I look at it, I think there is a bug in the ALU not clearing the zero bit in the status register. It took me a bit to figure out how to pipeline data through ...

I'm sure you're right - verification comes after code complete, for this. I don't think this kind of task is a terribly good fit for test-driven design.

Not necessarily test-driven - but writing the verification as you implement each instruction seems to me to be a good approach. But that's just ...

It'll be interesting to see what you come up with - especially if it's relatively easy to apply your verifier to other, existing, cores.

One thought: by checking the revision history of cores and emulators, you can see which bugs have commonly been fixed late in development. You can test your ...