My search-fu is poor today; I know I've seen one of these for a NMOS 6502 (though I can't currently find it!) but I'm curious to know what happens when reading some of the indexed mode. I recall that some of these did two read cycles of the target address in the NMOS version but I'm unsure if it was fixed in the wdc65c02 - the data sheet rather hints that it does but it's unclear.

My potential issue is reading a CF card in ISA 8-bit mode; grabbing data requires (iirc) 256 sequential reads, so I don't want to have accidental unexpected reads.

Neil

IIRC, the "wasted" read comes from the following instruction, not the ill-formed operand address. I'm link-challenged ATM.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I'm not aware of that sort of document for the 65C02. The 65816 datasheet does document the cycle-by-cycle behaviour, and that looks similar enough to what I remember of the NMOS 6502 that I'll believe the 65C02 will be the same. Instructions like LDA abs,X will have an extra cycle that reads from the wrong page if adding X to the address crosses a page boundary. STA abs, X always has the extra cycle: it will read from an address that has X added to the low 8 bits, then write to the final address. INC abs, X will have an extra read (possibly from the wrong page), then the real read, then write the old data, then write the new data.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks BDD. I have two other data sheets for the wdc65c02, and neither include that table... which answers my question.

Neil

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm not very sure how to read these datasheets. But in the table you cited, it looks to me like section 3a applies to the situation for STA $8000,X and note (1) applies to the PC+2 cycle and note (1) says "Add 1 cycle for indexing across page boundaries, or write. This cycle contains invalid addresses." Where is the page boundary? I can't tell if this note applies or even be sure I am reading the right section of the datasheet table, but if $8000 to $8002 is considered to cross a page boundary, it seems like the invalid address is documented? Actually, reading it again, it says "or write" so maybe this invalid address happens for every STA?!

I failed to reproduce the situation in my cycle by cycle trace - the extra cycle occurs, but the address being read is the address being written to. The bus state is being captured and printed at on the rising edge of Φ2.



(edit) I had a bug where my code doesn't know TAX requires two cycles and so the STA was decoded a cycle early and a spurious instruction was shown. Fixed in this edit. Still, focus on the left side of the output which is cycle count, address, RWB, data bus, (ascii for data bus if A-Z a-z) before the long gap to the disassembler's version of the trace. The text on the right is from the disassembler and not from the bus.

That extra read at the write address is probably because there's an optimized core in the WDC chip.

IIRC the 65816 as originally planned was faster in terms of cycles than the 6502 - but this broke the Apple II disk controller when they wanted to use the 816 in the Apple II gs, so some extra cycles had to be reintroduced. Thanks, Woz!

This could be one such occasion. The original 6502 would have probably always read the unmodified operand address ($8000 here) before accessing the updated one. The 65816 originally was that one cycle faster, but had to be 'fixed'. But they probably just added a read from the [edit: not 'final address' but] PC address instead of reintroducing the access to the wrong address.

The W65C02 could have at some point just inherited that from the more modern 65C816 core.

Note: this is deduced from what I remember without consulting any datasheet, and more or less pure speculation, so take with a grain of salt.

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I should have read John's answer more carefully. He describes the situation perfectly I think - the address arithmetic is being done piecemeal and results in the wrong high byte on the read and an invalid access as a result. My attempt to reproduce is a bit confusing though:

Why do the extra read cycles happen at the PC? Arguably this is better behaviour in *both* scenarios, so if this is a "fix" why not fix it all the time?

That's the behavior I was clumsily hinting about in my post above. You seem to have explained it better (i.e. more accurately), but your question adds an extra twist that may not have an easy answer. Perhaps this is a detailed peek at the "Woz factor" in action.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Are you talking about the two fetches of $9d from $ff03? The first actually belongs to the TAX, which is a two cycle instruction. Every 6502 instruction starts with a fetch of the byte after the opcode: the opcode has only just been latched so decoding hasn't taken place, the next cycle has to do something, and the next byte is a useful default as most instructions have at least one byte of operand.
So it's more like


Oh, or are you talking about the second and third STAs, which read from $ff08/$ff0b in cycle 13/18? That one I can't explain. I'm fairly sure the NMOS 6502 would have read from $8000/$8001 there.

My earlier description was speculation regarding the 65C02, as I wasn't aware of any documentation about it and wasn't able to pull out a board and experiment at the time (I hope my post made that clear). I'm fairly confident on the NMOS 6502 behaviour though - what STA does across page boundaries is the sort of thing I'd have been interested in when I had a logic analyser hooked up to one.

Not this one - this is a result of an ongoing bug in my disassembly display in the monitor where I am not using the right value for the cycle time required for tax in the output. As you say this read is just the bus state while TAX executes before the real fetch of 9d.This. The oddball thing to me here is that when the addition crosses page boundaries it reads from the PC, but when it doesn't it reads from the correctly computed destination of STA. I still argue that always reading from the PC would be better behaviour in both scenarios, so if they fixed the old NMOS behaviour by doing it this way (to avoid reading the wrong address from the prior page whose effects could be quite unpredictable) they should have fixed it in the non-page boundary case too (because even in this case a read from a hardware register before a write might be undesirable).