Page 1 of 1
Question About Absolute, X Timing
Posted: Wed Mar 01, 2017 8:04 pm
by CitizenSnips
Referring to
this manual, I'm currently studying the timing of absolute, X addressing for read-modify-write instructions (section A. 4.4.). In cycles 3 and 4, the address bus has the exact same values, but data is only fetched in cycle 4. The address bus is marked with "(discarded)" in T3. Why is this? I would think that the extra cycle, T4, would only be needed if a carry was generated out of adding BAL and X, in order to increment ADH, similar to how other types of instructions in this mode handle page crossing.
Re: Question About Absolute, X Timing
Posted: Wed Mar 01, 2017 8:12 pm
by BigEd
I vaguely recall there are some anomalies in this area: some instructions always use the extra cycle. As you say, it's not strictly necessary. You could think of it as a performance bug.
This might help:
Unfortunately, this is not always documented correctly, as some 65C02 documentation mistakenly assumes that DEC and INC have the same timing as ASL, LSR, ROL, and ROR; namely that INC abs,X and DEC abs,X take 6 cycles when a page boundary is not crossed, which is, once again, incorrect. DEC abs,X and INC abs,X always take 7 cycles.
From Bruce Clark's
"65C02 Opcodes"
Re: Question About Absolute, X Timing
Posted: Wed Mar 01, 2017 8:31 pm
by CitizenSnips
Very interesting. Thanks!
Re: Question About Absolute, X Timing
Posted: Wed Mar 01, 2017 10:01 pm
by White Flame
I would think that a descriptive solution to why this cycle is always there merits a trip through visual6502. See how the paths starting from the micro-operation dispatch table differ between extra-cycle-when-page-crossed and the always-take-an-extra-cycle instructions like these. The 6502 is very compact and clever, and if some things just didn't fall into the optimization model they chose, it's either tear it apart and lose simplicity and reusable optimizations, or live with a sometimes-extra cycle on your RMW abs,X instructions.
Re: Question About Absolute, X Timing
Posted: Wed Mar 01, 2017 10:07 pm
by BigEd
Fair point: not so much a bug, as a wrinkle, which couldn't be ironed out within the constraints of the implementation (they had a hard limit on how big the chip could be, and did cut things out, and also had a tight timescale.) [I speak of the NMOS 6502 - the CMOS 6502s had different constraints and could perhaps have got everything "right" if they'd noticed every detail of what they'd designed.]
Re: Question About Absolute, X Timing
Posted: Thu Mar 02, 2017 12:16 am
by Dr Jefyll
I vaguely recall there are some anomalies in this area:
Yes. And the 'C02 fixed the problem... but, curiously,
for some but not all of the RMW instructions.
Moreover, the documentation fails to accurately describe this! See dclxvi's thread,
A 65C02 bug?
- Table 7-1 excerpt (original).gif (6.04 KiB) Viewed 8498 times
indexed addressing raises the possibility of a page crossing, which means an extra cycle may be required prior to the memory access. But for some indexed Read-Modify-Write instructions an NMOS chip will always include an extra cycle, even when no page crossing occurs. [...]
Table 7-1 of the WDC datasheet claims this issue has been corrected for the CMOS version, but in fact that's only true regarding ROL ROR ASL and LSR. INC and DEC are also Read-Modify-Write instructions, but the fix does not apply. Table 7-1 should read as shown below.
Re: Question About Absolute, X Timing
Posted: Mon Aug 20, 2018 12:33 pm
by BigEd
I vaguely recall there are some anomalies in this area:
Yes. And the 'C02 fixed the problem... but, curiously,
for some but not all of the RMW instructions. :!: Moreover, the documentation fails to accurately describe this! See dclxvi's thread,
A 65C02 bug?
Aha - I just had a lightbulb moment of my own. I noticed Jens' "true cycle" core is intended for use in an Apple II disk application - where cycle-accurate timing is everything. I wonder if the unimproved instructions, the ones which apparently have some unoptimised logic and take one more cycle than they need to, were used by Apple's 8 bit code, and for compatibility purposes had to be left as-is?
Re: Question About Absolute, X Timing
Posted: Mon Aug 20, 2018 1:03 pm
by Dr Jefyll
I wonder if the unimproved instructions [...] for compatibility purposes had to be left as-is?
Interesting idea, Ed!
The context is 65C02, but I'm reminded of another thread which mentions the 65816 getting its evolution reversed because that's what Apple wanted.
If WDC wanted Apple to use the '816, WDC would have to redesign the chip. They did.
Detailed summary
here.
-- Jeff
Re: Question About Absolute, X Timing
Posted: Mon Aug 20, 2018 1:13 pm
by BigEd
Aha - we'd already solved the puzzle, more or less!
Re: Question About Absolute, X Timing
Posted: Mon Aug 20, 2018 2:52 pm
by Dr Jefyll
It was you, Ed, who suggested Apple's (possible) influence. Which is just a theory, but a plausible one, IMO. I can't think of a better explanation for why the 'C02 fix is so puzzlingly incomplete.
I'd be interested to know whether it can be confirmed that Apple's disk controller relies on the NMOS timing for INC and DEC with Absolute, X mode.
Re: Question About Absolute, X Timing
Posted: Mon Aug 20, 2018 3:05 pm
by BigEd
I'd be interested too!
Re: Question About Absolute, X Timing
Posted: Mon Aug 20, 2018 7:24 pm
by BigDumbDinosaur
It was you, Ed, who suggested Apple's (possible) influence. Which is just a theory, but a plausible one, IMO. I can't think of a better explanation for why the 'C02 fix is so puzzlingly incomplete.
I'd be interested to know whether it can be confirmed that Apple's disk controller relies on the NMOS timing for INC and DEC with Absolute, X mode.
...and then there's the undocumented double-read with
<addr>,X that the 65C02 does, much to the chagrin of anyone trying to configure an NXP UART using that addressing mode.
