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.

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

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.)

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.

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

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)

Check bottom right

From wiki there is this sentence:
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:

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

Surely: why does it keep coming around?

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

Don't feed the trolls...

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.