Thanks for clarifying!

Interesting point that the dummy reads actually cost something if they are sent to slow memory.

I think Michael's core may manage without dummy reads, although I'm not certain.

Cheers
Ed

Dummy reads can be removed, at the cost of some extra resources. This may slow down the max attainable clock speed, but if you intend to attach the CPU to slow memory like SDRAM, it's probably worth it.

Are you thinking of a VMA-like signal, or actually removing the 'dead cycles' altogether?

I know a few that can be removed altogether, but I haven't studied it closely enough to say that all of them can be removed. Adding a VMA-like signal could be a useful first step. That's a lot easier to do, and at least solves the problem of invoking slow memory cycles.

I see the 'dummy reads' when using indirect Y addressing mode. Is this the only addressing mode with this issue?

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

No, absolute indexed also has a dummy cycle when a page boundary is crossed (it first reads from the wrong page), just as branches. To avoid these cycles, you'd need a 16 bit adder so the carry from the LSB can be propagated in the same cycle. I would have to check more carefully to see if there are any more cases.

I'm surprised I never came across this issue before. Maybe I did and I didn't know what was happening. With the simulator I can clearly see the problem now when certain addresses incorrectly trigger the address decoder for a 'read from address' when I'm trying to do a 'write to address' using indirect Y addressing... I'm re-familiarizing myself with the MOS Hardware Manual, I never really studied the Appendix A.

So the objective would be to discard the first address output in these cases, since the second address output is the corrected one?
I don't think correcting branch opcodes would be an issue for address decoding though, or would it?

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

The simplicity of the 6502 memory interface is part of the problem. With a single direction/operation pin, i.e. RnW, the decode logic can only operate on Phi2, the address, and the direction pin, RnW. One thing that I have done, and which could be added to the Verilog-6502 and 65Org16 cores, is separate read and write strobes. The dummy cycles can be left in the instruction sequence, but the read and write strobes are only asserted when truly required. Further, most memories and peripheral devices not 6502-compatible expect separate read and write strobes.

I eliminated the dummy cycles, as Arlet states, only by adding additional hardware. It increases the size of my core, and most likely contributes to the decrease in overall clock speed I experienced when I put together the M65C02 processor implementation.

_________________
Michael A.

An interesting suggestion. Thanks for joining the discussion!

I used a TFT, in an earlier project which had an ASIC video controller, namely the Solomon Systech SSD1963.
The IC had a pin to switch from 80xx mode or 68xx mode (65xx mode same thing). In 80xx mode it did have the separate RD & WR pins for controlling data to the 1MB internal RAM.
It's surprising to me that since the way desktop computers have evolved from this 80xx architecture, that the pinout of memory devices did not follow with these separate RD & WR pins.

EDIT:The separate RD & WR do remind me of dual port RAMs though.

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

Yes, but since you can't "discard the address", this would involve the extra RD signal. So, for instance, in the indirect Y mode, the state machine goes INDY2->INDY3 or INDY2->FETCH. In the first case, there's a dummy read in INDY2, so you should deassert RD in INDY2 when it's followed by INDY3. Alternatively, you can remove the INDY3 state altogether, and do a 16 bit address calculation instead. The extra cycle comes from the fact that the 8 bit ALU needs two cycles to calculate the address.


The branches should be fixed in the same way. When BRA1 is followed by BRA2, don't assert RD during BRA1. Or, do a 16 bit address calculation when adding PC to branch offset.

My preference would be to try to add 16 bit address calculation. It's a simpler solution, and performance may not suffer too badly because there will be a dedicated adder in the address path, rather than using the ALU.

Note that on 65org16 you need to do a 32 bit address calculation rather than a 16 bit one.

I don't think an adder would hurt too much either and I follow you on your state machine modifications. In the interest of quick progress, what would the address calculation look like, something like add $0000FFFF?

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

Looking at the code again, there's no need for a 16 bit add, since the LSB has already been added. For example, to change absolute indirect, the current code for the ABSX1 state does:

DIMUX is the 2nd operand byte that we read, and is now present on the DI bus. It is the MSB of the address. The ADD is the result of the ALU calculating LSB + X in the previous cycle, and is correct. All we need to do is add the carry out to the MSB:

The ABSX2 state should be removed, and the state machine should become:

In the ABSX1 state, we no longer need the ALU, so all the alu_op/AI/BI/CI values can be changed to 'x'.

Wow, this is great if it'll work! I'm ready to test it and see how to do something similar with the INDY2 & INDY3 states.


Do you mean for the AI/BI/CI mux's to the alu, to just comment those states, i.e. ABSX0, ABSX1, out?

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

You could, but you may get better results if you assign x's to the output, just like for the DECODE/ABS1 states. That gives the tools maximum flexibility to optimize the expression.

Excellent! I'll try it out today. I have a few errands to complete first.

Are you going to change your core and try Klaus' test suite?

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