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

Great!

Yes, I believe it's fixed. Shifting out a value of $000F works as expected and sets the Carry flag. Time to move on! I will update Github.

EDIT: So now that the pseudo-timer value and plotting is functional. A quick test needs to be made to set the reset bit on the timer, then do a typical delay loop. Then read value and compare real and expected results!

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

I have just enough energy left to paste the code for those that would count the expected cycles for the cpu that is running @ 100MHz.

Ok so this 'Delay Loop' is at least 65536x65536 cycles:

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

As a very rough calculation: That's 4 billion, times 5 cycles for the inner loop. 20 billion cycles divided by 100 million hertz is 200 seconds.

Ok, that's too much value for the left of the decimal! I've re-thought the accuracy issue of this counter and I think I will use the A0 address line to decode in a second consecutive address that will read 4 more decimal places to the right (another 16-bit hex number). Also, I will loose the second's digit counter.
By doing this I can have 8 decimal places to the right of the decimal in order to be cycle accurate @100MHz. So the counter will look like '0.xxxxxxxx seconds'.

It's intriguing to me for a computer to know how fast it is.

By Tues I should be done with the timer, and finally be able to test the direct translation of Daryl's Bresenham Circle Algorithm. I was looking over it today. It is very nice and clean.
I would like to start testing, by using the JSR's to jump to the plot routine. Then another test without the JSR's and insert the plot routine itself for every JSR and spec the timing difference. We know every cycle counts and eliminating the JSR's is only a starting point. I have 15 other accumulators at my disposal, to maximize speed!

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

Alright I got it working, now I have to subtract the cycles necessary to hold the counter, i.e. LDA #$4000, STA $C00000000.
Arlet, since this question involves a derivative of your core, for instruction 'INY', this is a 2 cycle instruction? DECODE, then REG?

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