Close, but no cigar tonight. Will add the decimal point, then get the timer tuned in tomorrow.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I discovered a problem with the core when barrel shifting to the right 12x. I'll have to investigate if it's just this one opcode $B04A or others. The incorrect behavior after shifting a value of $9673, to the right 12x, is a value of $FFF9, instead of $0009. Barrel shifting to the right 8x and 4x appear to be correct.

EDIT: They're not correct, even the regular opcode LSR is shifting in ones. So, all right shift opcodes are shifting in 1's which means the carry flag being set for some reason. If I do a CLC,LSR,CLC,LSR,CLC,LSR,CLC,LSR it works ok. The one clue I have to make this a quick fix is that left shifts are working correctly. Something to do with the ALU.

EDIT: I think this is an error on line 70 of the ALU. CI should not be there? I'll try substituting a 1'b0 for it.

EDIT: That appears to work.
EDIT: No it doesn't work. I must've done something too quickly. This is going to kill me. Any hints?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Perhaps you are looking at the code implementing the ROR operations instead of the LSR operations. The code snippet that you provided is the implementation that I use for ROR:

_________________
Michael A.

Well, I've done more testing... I was puzzled at first because I know I've tested the barrel shifting before, when I first implemented it and it worked, but I didn't test it thoroughly enough!!!

The problem appears when the last bit [15] is a 1 while doing an LSR on the accumulator. If it's a 0, it works fine so I don't think it's a problem with the carry bit. I will have to do more testing.

I noticed this when I was trying to plot a pseudo timer value of 9.763. The 9 was messing up but not the 763 and I was using the x12, x8, and x4 barrel shifting opcodes. But then I noticed it was doing the same thing for the regular LSR too.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I need a break. I think I'll take a rest for awhile.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Sorry it's broken for you... I did test the shifts and rotates and I'm pretty sure they were working at one point, in my fork.

Ed, I believe the problem is in the ALU section... I tried multiple alu/cpu cores all the way back to when I first had success with the barrel shifting, and they all exhibit the same problem shifting the highest bit, when it's a 1, to the right. Can you confirm please, that your .a core works?
I'm in no hurry here. As I said, I'm taking a bit of a break. So just whenever you get around to it, I'd appreciate it. Just a simple test using any LSR opcode with a value of $1000 shifting multiple times.

EDIT: That would be a value of $8000, sorry.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Mmm, is it possible you've somehow implemented ASR (Arithmetic Shift Right) rather than LSR (Logical Shift Right)? Preserving the MSB during a right shift would be consistent with ASR.

EEyE:

This may not be of much help, but I think the problem you are having is not in the ALU but in the CPU of your core. I think the issue is a mis-decode of the required operation, and an issue in the the evaluation order of the CI multiplexer. (You have much more experience with this core, and I haven't attempted to set up a simulation to verify my observations. Thus, your conjecture may be correct, and my analysis may be incorrect.)

You have a signal for rotate operations:

You also have a signal for shift operations:

Clearly, the rotate signal only deals with ROR/ROL instructions. The shift signal appears to assert for both ROR/ROL and ASL and LSR. I think that shift should only assert for ASL/LSR, and rotate should only assert for ROL/ROR.

I think that the CI multiplexer is not selecting 1'b0 as the input because shift follows the rotate in the nested if-else represented by the trigraphs in the CI multiplexer specification:

If I'm not too far off, in the READ or REG states, I might rewrite the equation for CI as follows:

If the execution of the instruction takes place during the fetch cycle, then the adjustment suggested above may need to be applied to the nested if-else of the FETCH state.

Hope this helps.

_________________
Michael A.

It is the same in the 8 bit core:

The 'shift' register represents all shifts and rotates, while the 'rotate' register picks out rotate only. The comments in the definition of those signals also mention that:

it therefore makes sense that the 'rotate' test has higher priority in the subsequent instruction handling.

I think you're right. I'll focus on this now. I'm sure this is it, I already see some potential problems with my opcode decoding, particularly where they're assigned into OP_A.
But I'll re-check all the decodings concerning <shift,rotate>.

Thanks for the help all!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hmmm, I actually don't see any problems. As many times as I've gone over them, this is a good thing. Bad thing is the problem's still there.
I'll test Ed's .a core with the shift/multiply ALU next using LSR A. Unfortunately it's a work day, but I should be able to get the test done today.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Interesting observation: ROR Acc working ok with the carry set and cleared. Just LSR is muffed, which leads me again to believe the problem is inside the ALU. Not only because it looks Greek to me but because some assignments are [dw:0] and some are [dw-1:0]. The ones with the extra bit I presume allow the carry bit to propagate in.
Note that this ALU I use here is from BigEd's experiment with barrel shifts and multiply fork from the 65Org16.a core, but I stripped it of what I though was impertinent operations, like Half Carry op's and so forth. It's quite different than the one Arlet uses in his 8-bit core.
So now I will track this problem down like a rabid dog. Today I did find 1 error in the load_reg section for column 6. It did not include the INC zp or INC zp,x.
I intend to test all the LSR addressing modes tonight to see if any work. Then test all ROR addressing modes and see if any don't work.
EDIT: I take that back about the error I thought I found. Unless the INC or DEC involves an accumulator, it does not belong in the load_reg section.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I see my problem, it involves this piece of code:
The "default : E_Reg <= ADD;" is not always correct.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The following seems to have fixed the problem, although more testing is needed. The problem was in the ALU:
Changing it to:seems to be working for this simple test which was previously showing ROR to work, and the error with the LSR. Now they both work.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502