One of the things which isn't really obvious to me is what happens in the hardware when a page boundary is crossed in the 6502 processor for the INC instruction. I get that we do an initial fetch on the address bus as if the page boundary hadn't been crossed, but I don't get what exactly the hardware does to inform itself that the page boundary has been crossed, and thus, needs to correct the high-byte on the address bus.

I began looking at this with the absolute indexed INC instruction (7 cycles). From what I can tell from the visual6502 simulation, starting from when we get the low-byte in DL (2nd cycle of executing INC), we:

1. Put DL -> BI (low byte), put IX/IY -> AI, increment PC and update AB to read next byte; Add the two together (1 cycle; Carry output (I'm assuming) is signal for future cycle to need to correct the high byte).
2. Put DL -> ABH (high byte), ADD -> ABL (low byte), DL -> BI, 0 -> AI, Add w/ carry (increment) AI/BI -> ADD; Basically this is acting as-if we didn't cross the page boundary, but preparing for if we did.
3. Here is where I get confused. Looking at the data, we shove ADD (which is our incremented high byte) into AI, and then add by BI which we set to FF probably using the inverter (-1). Within the first half-cycle, it appears that if ABH needs updated because of the low-byte carry, it is then updated. (Makes sense when this is happening, because the busses are busy on the second phase of the clock cycle because of precharge MOSFETs.)

My question is this:
I don't see any timing control change between an absolute indexed INC either crossing or not crossing the page boundary (DPControl doesn't differ, plaOutputs doesn't differ, the only thing that differs is the values in the adder [obviously], the output of the carry [obviously], and the high byte is corrected [obviously]). I don't understand how this is implemented in the hardware. Is this basically a special case, and somewhere in Random Logic Control there is a flip-flop that stores whether or not we want to take the high byte?

Furthermore, why can't INC be optimized for not crossing a page boundary if some of other instructions are? Is it simply to reduce complexity?

Provided, you can find a spreadsheet of the visual6502 simulation output for both crossing and not crossing a page boundary with INC, with the cycle that is confusing me highlighted in yellow.
https://docs.google.com/spreadsheets/d/ ... sp=sharing

Any help understanding this would be much appreciated.

Welcome, TrentoReedo

It's a basically a bug (albeit a benign one -- all it does is waste a cycle). You're right -- INC using Absolute Indexed can potentially be optimized, and a "fix" regarding similar optimizations was included when the NMOS 6502 was superseded by the CMOS 65C02.

Curiously, even the fix was somewhat buggy! Bruce (aka dclxvi)'s thread here deals with an investigation of the subject, and the latest post in the thread is a summary/recap.

I don't think there's any authoritative info on how these specific bugs occurred, but generally speaking the process of laying out an IC (especially back in the 20th century) was much less perfect and theoretical than one might suppose. Maybe it was just a simple boo-boo.

Or not! Designers of the NMOS 6502 in particular were under severe pressure to limit the chip area (and thus cost). This resulted in some fairly drastic hacks of the layout late in the design process. It's conceivable that they knowingly introduced and were prepared to tolerate some minor misbehaviors in order to meet their target. (But IMO that fails to explain why the 'C02 fix is flawed! )

cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks for the information Dr Jefyll, that clears up the mysterious extra cycle in INC/DEC - next up is how the hardware actually decides not to take the modified upper byte as the effective address. I'm going to go ahead and assume the bug is that Random Control Logic, instead of modifying the timing state to skip the unneeded effective address change, instead flips a toggle between either taking or not taking the value on ADH bus (ADH/ABH from the block diagram). I notice that these signals (ADL/ABL, ADH/ABH) aren't present in the visual6502 simulator, so maybe this is what is causing the confusion for me.

Is this something that is maybe easy to find and add to the simulator? Should I have a look at the GitHub and see if I can figure it out? Thoughts?

EDIT: Also, thanks for the welcome message!

By any chance are you using terminology from the well-known 6502 block diagram that's in circulation? (I forget the name of diagram's creator. ) Anyway, I'm pretty sure that terminology is different from the terminology used in the visual6502 simulator. (Regarding the visual6502 simulator, others here can advise you better than I. My own focus is on behavior from an external POV.)

I hope it's clear the extra cycle is always present, whether it's needed or not. So, the word "decide" seems a little out of place here. Just checking!

You're welcome -- nice to have you with us!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yes, I am speaking of Hanson's Block Diagram of the 6502 (https://projects.ncsu.edu/wcae/WCAE1/hanson.pdf), I read elsewhere (http://visual6502.org/wiki/index.php?ti ... imUserHelp) that many of the names for DPControl signals come from this diagram.

It is clear to me that the extra cycle is present, I'm not questioning that - judging by the data in the visual6502 simulator, the incremented high byte is always present (regardless of whether or not we cross the page boundary) on ADH for this cycle, however if we inspect the address bus the value is either taken or not (always doing the correct thing to get the right effective address). So when I say "decide" I mean something is toggling some DPControl whether or not the ABH register is written to or not, and that is not being reflected in the DPControl output anywhere for the visual6502 simulator.

If you refer to my spreadsheet, I have highlighted in red this "decision" that I am talking about. My issue is that 6502 always ends up doing the right thing, but the DPControl is never different, and we don't skip the correction state, so how does it know whether or not to take the value that it populates on ADH? I'm basically questioning if an important control signal for a case like this is missing in the simulator for understanding the effective address resolution.

Alright, I'm out of my depth here -- can't answer you. But I'm sure a forum member more knowledgeable on this subject will eventually speak up.

Meanwhile, maybe you'd like to consider a post in the Introduce yourself thread. No pressure, though.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks for helping with the extra cycle issue! I made a post on the Introduce Yourself thread, and will wait for others to comment here about my other questions.

Hi Trent
welcome, and thanks for writing your intro over in the introduce yourself thread.

good question you have there: the answer lies in part with node 821, aka ADH/ABH, as you can see in this simulation:
http://visual6502.org/JSSim/expert.html ... 21,ADH/ABH

That is, the new possible value for address bus high is generated in the ALU and placed on the internal ADH, bus, but that value is only accepted by the flops behind the address bus pins when the enable signal ADH/ABH is high.

You can see one of those flops here
http://visual6502.org/JSSim/expert.html ... &zoom=12.4

If we look at the driver for this control signal we see that it, and node 639 ADL/ABL, should perhaps have been counted as datapath control signals along with all the others driven from that row of drivers. My mistake! In my defence, those two signals don't control the datapath as I think of it, being the regular structure in the south of the chip, but logically their job could be considered part of the datapath.

http://visual6502.org/JSSim/expert.html ... &zoom=10.4

It might be, thinking about it, that I can squeeze them into the set of DPC signals by giving them aliases - quite a few signals have multiple names.

Thanks BigEd!

So it is as I thought, I appreciate the confirmations on this. I won't do anything more unless it is asked of me here, but my 2 cents is that it'd be clearer - especially given the case where some RMW operations waste a cycle - to display the ADL/ABL and ADH/ABH as DPC signals. (Though I agree in normal, expected cases this would not be needed, probably best to opt to include all-or-none, up to you!)

I appreciate the swift responses!

Done now (you may need to force-reload to get the new code)
See
https://github.com/trebonian/visual6502/issues/50
and
http://visual6502.org/JSSim/expert.html ... ,DPControl

Thanks BigEd!