The 6502 Rotate Right Myth

[sark02]

https://youtu.be/Uk_QC1eU0Fg

[BigEd]

Thanks - that's an interesting video from TubeTime, and is thoughtful and analytical despite the title.

The conclusion is that the circuitry needed to implement ROR is missing from the first revisions of the chip: that's not a bug, it's a decision. And there was evidently then a reversal of the decision, to add the extra logic and implement ROR, and of course also to document it.

The conclusion is that the observation of a buggy ROR is merely the observation of unintended side effects of the logic, just like every other "undocumented opcode" or "illegal opcode".

This goes against received wisdom and I wouldn't be surprised to see some hostility to the conclusions, whatever the evidence.

We recently discussed the video over on stardot
https://stardot.org.uk/forums/viewtopic ... 41&t=26451

[fhw72]

BigEd wrote:

Thanks - that's an interesting video from TubeTime, and is thoughtful and analytical despite the title.

The conclusion is that the circuitry needed to implement ROR is missing from the first revisions of the chip: that's not a bug, it's a decision. And there was evidently then a reversal of the decision, to add the extra logic and implement ROR, and of course also to document it.

The conclusion is that the observation of a buggy ROR is merely the observation of unintended side effects of the logic, just like every other "undocumented opcode" or "illegal opcode".

This goes against received wisdom and I wouldn't be surprised to see some hostility to the conclusions, whatever the evidence.

We recently discussed the video over on stardot
https://stardot.org.uk/forums/viewtopic ... 41&t=26451

Hi Ed!

There was a rather long discussion about that topic on Forum64 (in german only unfortunately).

https://www.forum64.de/index.php?thread ... 2-ohne-ror

However the conclusion is slightly different as the schematics of the 650x dated 11/74 (before real chips were released!)
already contain the necessary change in the datapath: Addition of the latched carry flag in Bit7.

It looks like the decision to implement ROR was already made but either timing or layout space issues made the developers
stop the implementation for the Rev. A and fix/finalize it later.

[barnacle]

By chance (or the inner workings of google) youtube threw this video at me a few days ago... Having watched it, I remain convinced that if there isn't an instruction that doesn't work as advertised, there isn't a bug. Just a design decision, later corrected. I note that the earliest 6502 MS Basic code from the time use a workaround which is removed (I think) once the chip includes the instruction.

But to me this is not a bug. A bug is the TX Empty flag on the WDC65C50...

Neil

[BigEd]

fhw72 wrote:

There was a rather long discussion about that topic on Forum64 (in german only unfortunately).

Thanks for the link! Quite a long and argumentative thread... but interesting all the same. Notable for showing me a publicly-shareable scan of the Rev C schematic! (But note carefully that the two sheets of this Rev C schematic have very different dates.)

I might need to rewatch the video. Evidently there's a rev A photomicrograph which I don't think I've seen. Edit: it's here.

Edit: just to add a couple of notes...
TubeTime is also known as Eric Schlaepfer
Various notes on links found in the forum64 thread:
[*]A link to an HN comment by djmips, which links in turn to Bill Mensch's words in a video "Talking Tech with Bill Mencsh" hosted by Eric and by Bil Herd. It also links to Michael Steil's 2010 post Measuring the ROR Bug in the Early MOS 6502.
[*] A link to Chuck Peddle's oral history here. See also the previous page.
[*] A link to the undated 10 page typewritten MOS 650x Product Info which starts with "Since introduction of the MCS650X Family numerous customers have requested the addition of the ROR Instruction. This instruction is now being added to all MCS650X processors." Also within "MCS650X microprocessors incorporating the above changes will be available in sample quantities in April with production deliveries beginning in May." (Also a note that RDY didn't work well with branches, and there's a fix for that included.)

[sark02]

BigEd wrote:

This goes against received wisdom and I wouldn't be surprised to see some hostility to the conclusions, whatever the evidence.

We recently discussed the video over on stardot
https://stardot.org.uk/forums/viewtopic ... 41&t=26451

Thanks for the link, BigEd. I posted the video here precisely as I hadn't seen it discussed. The "ROR bug", as an unfortunate whoopsie, always seemed plausible given that it was later "fixed". It's interesting that, even after all this time, new information is coming out (or, at least being published) that nudges the history a bit.

[fhw72]

BigEd wrote:

I might need to rewatch the video. Evidently there's a rev A photomicrograph which I don't think I've seen. Edit: it's here.

Please note that the photograph of the Rev.A contains some errors/tearing.

[BigEd]

Indeed so! But the layout of the datapath drivers, and the big differences there from A to D, is rather a big piece of evidence, I think. (It's highlighted in Eric's video)

[VinCBR900]

Check bottom right

[kakemoms]

From wiki there is this sentence:

Quote:

At the same time, these visits invariably resulted in the engineers he (Peddle) presented to producing lists of required instructions that were much smaller than "all these fancy instructions" that had been included in the 6800.

I would think that they intended to include the ROR instruction in the original design, and that the control line is there to prove it. But compressing everything down was certainly a daunting task and someone may have had to do some thought late-stage decision to get it shipped in time. Since ASL/LSR are both there, removing ROR does seem inconsequential. Was it designed out due to a bug in the layout or space constrains? I think this sentence from "The best layout guy in the world" section of Brian Bagnall's book says it all:

Quote:

Bil Herd summarizes the situation. “No chip worked the first time,” he states emphatically. “No chip. It took seven or nine revs [revisions], or if someone was real good they would get it in five or six.”

[BigDumbDinosaur]

I think the ROR debacle (if you can call that) has been beaten to death several times over.  Why does it keep coming up?

[barnacle]

BigDumbDinosaur wrote:

Why does it keep coming up?

Surely: why does it keep coming around?

Neil (I'll get my coat...)

[BigEd]

Don't feed the trolls...

[GARTHWILSON]

BigDumbDinosaur wrote:

Why does it keep coming up?

• There's an awful lot of material here.  I think Sheep64 is the only one who came in the last few years who read the entire forum.
• I might give some grace for even old timers to forget something has been addressed.
• The phpBB search could stand to work better.  One of my beefs with it is that it kicks out a lot of words I want to search for, saying they're too common, when that's definitely not the case.
• People could stand to put a little more effort into searching, or even just reading a 5- or 10-page topic before raising an objection or question that's already been answered a couple of times.  They might think their time is too valuable to do that; but how 'bout everyone else's time to handle needlessly repeated material?

So it's a mix.  I myself have a ton of bookmarks to topics I occasionally come back to, or know I'll want to later; but I've been here since the beginning of the phpBB forum, so I have that benefit.  The most important stuff can go in stickies; but we don't want to have dozens of those like some forums where you have to do a lot of scrolling to get to the newest non-sticky-topic posts.

[BigEd]

In this case, the thread was started because of a new video. If someone isn't interested in the video, they can just move on. Then we had a short discussion. Possibly someone could have linked to a previous discussion, but in this case, the video is new so there is something new to talk about.

If it's so shocking that someone rekindled the thread some months later, perhaps the answer is that the thread could have been locked, perhaps with helpful links to previous discussions. It's not uncommon in print for an editor to declare that some correspondence is closed.

But all this talk about why things keep coming up is really a new topic. Such a topic could helpfully give advice about how to search. It could list things which have been found in the past to be repetitive or unproductive or inflammatory.

I think posting a "why" question to a thread is often a bad thing. The thread will contain its own motivation - if any of us is not interested, we should just move on. If one of us has a genuine interest in knowing why certain kinds of topics or projects are of interest, that could be a new thread. If a person tries to compose such a new thread and finds it difficult to justify their reason for asking, that suggests it's not a good question.