Updating Processor Status Flags on Emulator

[gmcastil]

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 mode using the FSM I've indicated. The ADC instruction requires four cycles - on the rising edge of the fourth clock, the FSM is in the ABS_2 state and the value to put into the accumulator is ready to be registered with the transition back to the FETCH state.

I'd like to solicit some suggestions on how to get the processor status values stored properly at that time as well. 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 does. To me that doesn't feel like a particularly clean way to do it though. If anyone has any suggestions, I'd appreciate hearing them.

Also, I'm aware that there are also special instructions that use and set flags differently - if anyone has advice on handling those, I'd appreciate it too. Thanks.

[GARTHWILSON]

Quote:

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

Make sure you do it for any result, including ones that don't alter the accumulator. I'm thinking of ones that modify the index registers or R-M-W instructions to memory without altering A, X, or Y.

[gmcastil]

GARTHWILSON wrote:

Quote:

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

Make sure you do it for any result, including ones that don't alter the accumulator. I'm thinking of ones that modify the index registers or R-M-W instructions to memory without altering A, X, or Y.

Interesting. So decode and execution of every instruction should produce a combinatorially determined new status register that gets updated on every instruction (regardless of whether it touches those bits?)

[GARTHWILSON]

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 value of the memory location you operated on, even though you didn't affect A, X, or Y. Math operations will affect the V flag, but logical operations will not.

[gmcastil]

GARTHWILSON wrote:

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 value of the memory location you operated on, even though you didn't affect A, X, or Y. Math operations will affect the V flag, but logical operations will not.

Ok. But from a broader architectural perspective, it doesn't sound like you're disagreeing with the idea. So I'll basically have a section of combinatorial logical that takes the the A, X, Y, P, IR, and ALU inputs and yields a new value for the processor status register. Do I understand you correctly?

[Klaus2m5]

Basically every operand going through the ALU must generate flags, every address must not.

In the 6502 the load instructions and move register instructions (- TXS) are routed through the ALU although they don't calculate anything other than the flags. Address indexing and branch offset calculation also use the ALU but do not update the processor status.

[gmcastil]

Klaus2m5 wrote:

Basically every operand going through the ALU must generate flags, every address must not.

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

[GARTHWILSON]

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/mo ... y_1976.pdf

or for 65c02 (which I highly encourage you make your simulator for, because it is far superior to the NMOS 6502):
W65C02S Microprocessor (May 17, 2013) http://6502.org/documents/datasheets/wd ... 7_2013.pdf which has the flag-effect info starting on page 28.

[gmcastil]

GARTHWILSON wrote:

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/mo ... y_1976.pdf

or for 65c02 (which I highly encourage you make your simulator for, because it is far superior to the NMOS 6502):
W65C02S Microprocessor (May 17, 2013) http://6502.org/documents/datasheets/wd ... 7_2013.pdf which has the flag-effect info starting on page 28.

I'm not confused about which flags need to be updated for each instruction / opcode - I was confused by the statement about opcodes going into the ALU and addresses not generating flags.

[Klaus2m5]

I didn't say that opcodes go into the ALU. I said operands go into the ALU.

See the block diagram at http://www.pagetable.com/?p=39 for reference.

The ALU is also used to generate the memory address (indexing, relative addressing). In this case the processor status must not be altered.

I should have looked at the block diagram earlier. It shows that N and Z flag update is independant of the ALU and comes directly from the data bus (DB7, DBZ). So a load instruction does not need to go through the ALU to set those flags. Only C and V are gated from the ALU (ACR, AVR) in case of a shift or a add/subtract operand.