I used the original 6502 core from Arlet Ottens in a number of projects and had great fun with this core.

Recently I was working on a project where I was implementing some DMA where I needed to pause the 6502 CPU core (via the RDY signal) while transfer took place from DMA to memory, in which I discovered an edge case.

The code in question is as follows:



This register FD0B is something I implemented to initiate a DMA transfer when bit 2 is set. When the 6502 core from Arlet Ottens assert the WE signal for the write to register FD0B for the code above, I have some logic that assert the RDY signal of the 6502 after two clock cycles.

Now, when I eventually de-assert the RDY signal the Arlet Ottens core seems to have skipped the JMP opcode (aka code 4c) and tries to interpret the first byte from the JMP instruction as the instruction opcode.

This is not major issue and I can get pass this by just adding one or more NOP's before the JMP instruction.

Is this a known issue with using RDY signals on this 6502 core?

btw, I think overall the core from Arlet Ottens is overall a great core.

Can you attach some screenshots of waveforms?

Here are the simulation waveforms.

As can be seen when RDY becomes zero, it is as if the a9 (which is an LDA) is discarded. When RDY becomes one again in the other waveform, the system assumes 20 is the opcode (which is an actual fact the operand of the LDA), being a JSR. One can also see resemblance of this with the writes that happens to the stack.

Yes, the A9 is discarded, because the RDY is deasserted. This is as designed. A normal use of RDY is to add wait states to interface slow memory. This means that the CPU core should wait to grab DI until RDY is asserted again, giving the memory system some extra time to produce the correct data.

In this case, you should also feed the RDY signal into the memory system, so it will either hold the FE50 value of the address bus, or the A9 value of the data bus while RDY=0.

@Arlet Thanks for the explanation. Everything make sense now