Some folks are asking about the rotate *left* instruction - wouldn't that have the same problem? I forgot to mention it in the video, but the 6502's rotate left is a little weird. It just adds the number to itself, with the carry coming in and going out just like in a regular add (ADC) operation. A pipeline delay takes care of the rest.
Wow. A suit jacket. Was not expecting that. You look sharp! Great explanation that the "bug" was a feature or lack thereof. I have an old MOS kim-1 dev board with the white ceramic package in a box somewhere. Been meaning to dig that out.
Is it a bug if its intentionally masked out ? Would you find defective circuitry if its masked out ? or would you find blank spaces and tracks to nowhere if an intended instruction hadn't been resolved in time for the release date ? All fascinating stuff though.
@@garyc3476 😵💫"Though". 😵💫 The designers left out one (or many!) nice-to-have instructions, some possibly decided in the last days due to lack of space. They documented no ROR instruction. The 6502A was complete and bug-free. When a new model 6502B came out, with identical specs and behavior except that one instruction was added, that was no bug either. Compared to the 1976 model, the 1975 model looked *AS* *IF* it were the new model with a defect introduced (undefined behavior instead of ROR). Nowadays, new instructions can be added (and bugs fixed) retroactively. The BIOS chip can update the CPU microcode after-the-fact, at power-up. Undefined instructions can trigger interrupts that call routines that emulate the missing instructions.
Knowing that these first processors, already complex with thousand of transistors, were designed with big sheets by *hand* is mindblowing. Hat's off to those people.
@@kirkhamandy I wasn't this deep into it but I was a PC board layout artists in the mid 80s for a communications company. It was all done with layout tape and rub on transfer solder pads on clear mylar and then photo etched to copper clad boards. I have worked with rubylith, but that was for large scale art silk screening. The owner of the company contracted a programmer to attempt to create a PCB layout program to run on the fledgling IBM PC but he never got the "pathing" to work well enough to use it. I think that was when my eyesight started to blur. We used a lot of micro-miniature surface mount components dealing with microwave tolerances and I stupidly refused to use the desktop magnifier.
@@3DPDK I also did PCBs in the 80s. We used blue and red tape for double sided PCBs. I used to get paranoid when I had just sent off a design to be manufactured and got home to discover a bit of red or blue tape stuck to my arm!
0:51 The ubiquitous ARM microprocessor also worked the first time. Designed by a team of 4 at Acorn Risc Machines (ARM) of Cambridge UK in 1985, it took just 1 week from sketchpad to first working silicon. Really impressive.
Well said, Peter. The ARM lives on in tons of mobile devices. That initial realisation of a working design was a truly remarkable achievement by some incredibly talented people.
This is what fascinates me about history. Stories come up that dominate the reality of what actually happened. We don't even have a clear idea of what happened 50 years ago let alone 2000 years ago.
@@matthiaslipinsky501 No, we don't. We know how the climate will be in 50 years, given we do X. But the climate and the weather are two different things. To stay in the same area, we cannot predict even a single raindrop, and yet we can predict that it will rain and how much. Single raindrops are much, much harder to predict than the weather, which in turn is much, much harder to predict than the climate. Also, "climate collapse"? The climate doesn't collapse. It just changes. Ecosystems, however, can easily collapse if it changes too fast. Oh, and you're not a denier for asking questions - you're a denier (and a conspiracy theorist) if you claim that the vast majority of climate scientists are somehow lying about it.
@@KaiHenningsen according to Greta's youth, the "climate has collapsed". And yes, if we now have a strong rain flooding houses being built closed to a river or in flood areas, that is not because we reduced rivers area, but because "climate change" And sure you come up with "deniaer" to stop any discussion in lack of arguments. And yes, all "experts" say this. If they wouldnt, they wouldnt being called experts, but denialers or conspiracy theorists or Trump supporters or whatever
In the MOS manuals that came with my KIM-1, it was documented as not being available until after June 1976. An errata sheet had initially said it would be available in production quantities by May 1976. That said, my KIM doesn't have it. Back then we relied on vendor documentation and as we had no internet, I never heard this rumor.
Copy of the January 1976 manual with confirmation on p.150: archive.6502.org/books/mcs6500_family_programming_manual.pdf August 1975 data sheet which does not mention ROR: archive.6502.org/datasheets/mos_6501-6505_mpu_preliminary_aug_1975.pdf
I imagine the "confusion" is that the majority of the documentation for the 6502 shows the ROR instruction so unless you have the original then you'd think it didn't work. People are very bad at looking at notes on data sheets, and when those data sheets get used in manuals and articles its details like this that get omitted. If you've been told there is a bug in the early version people obviously didn't bother lo look for the correct data sheet to check it out.
i think people consider it a bug because the 6501 was suppose to be a drop in replacement for the MC6800. the MC6800 has ROR while the 6501 and early 6502s don't.
3:33 No. Joke. I was just reading 6502 Assembly books yesterday. And I found one that had a nice graphic that explained the difference between shift and rotate. It was a big "ah ha" moment for me. It is just funny to me to have it explained well twice within two days!
WOW! That was really cool. I can't believe that I have been working with computers since 1982 and this is the first time I have seen what the circuits look like under a microscope. And I loved the circuit diagram explaining the physical circuit. Thanks so much!
Really fun video. I recall the definition of "Bug" from my youth (the 1970s) - a bug is a feature you don't like. In this case, it's a missing feature. Thanks much for this video!
Coincidentally, many years ago I wrote a VHDL model of a microprocessor, and it actually did have a bug in the ROR instruction. It took a while to find it, because most of the code written that used the instruction didn't tickle it, but eventually I found what I thought was a bug in the program that turned out to be a bug in the microprocessor itself. I can see why the original designers didn't include it, as most of the code I've written for my own CPU rarely uses ROR in its original form. Instead, I typically force the carry bit clear in order to use the instruction as a right shift, since the instruction set didn't include shift instructions. In fact, I so rarely use ROR with the carry intact that I added a compile-time switch that effectively turns it into a logical shift right.
This was a very interesting video! Interestingly, in modern Atari 2600 programming, using unimplemented instructions is actually sometimes used to save ROM space!
Awesome deep dive. I would argue the original run of 6502s behave in an unexpected way when running the ROR instruction which is one of the definitions of a bug. (Even if the underlying reason is that the instruction isn't fully implemented in hardware.) I think this is the age old argument if a missing feature in a released product is a bug or just a "missing feature" and there are many arguments both ways. A thought experiment could be: if MOS has not marked ROR "as not working" on the original datasheet, would this problem then be considered a bug? (Supposedly ROR was listed on the original datasheet but it said it would not work until 1976) Either way, clearly it isn't a flaw in the silicon or design, and that was really cool to see.
@@TubeTimeUS correct.. it can't "fail" something it never had even if something else in the future had an instruction added it is not possible for the original to be buggy.
@@ingmarm8858- not always true. If you manufactured a product, but left out a feature that was expected to be present by the market, even if not in your specification, what would your rivals call it?
@@TubeTimeUSThe January 1976 manual listed ROR as a regular instruction with in parentheses (available after June 1976). Admitting there is a bug without admitting it...
Would have loved to share this with my dad! He was able to meet Chuck Peddle way back when in the 70s and used the 6502 in a bunch of old printers of the era.
I remember one of the undocumented instructions. Some people ended up calling it LDAX which loaded both the accumulator and the X-register with the same value.
My preferred undocumented was DCP (DCM): DEC oper + CMP oper that combined a decrement and a comparison so it was very appropriate for loop counter to zero and saved a couple cycles in a loop.
If it's true that there were no plans to implement ROR, then why is there a perfect spot in the opcode decodes for ROR, right alongside ASL, LSR, and ROL? It may not be a bug, but it's not a missing feature either. It would be a planned but unimplemented or cancelled feature.
That's simply because the opcodes were designed to use very regular bit patterns, so as to be easy to decode. So for example, the shift direction is a specific bit in all the shift instructions. Then if you have three shift instructions, two which shift left and one which shifts right, then there's an obvious place for the second right-shifting instruction, and it's free because there is no obvious other instruction that would have fit there. It's completely what you would expect.
@@KaiHenningsen There's definitely a lot of cheating going on in the instruction decoder which is why a lot of unused opcodes do things that similarly coded opcodes do. At the time, a true microcode ROM would have been as big as the CPU itself.
Great video! I remember Adrian Black talking about this ROR thing awhile back on his youtube channel, but he didn't really get into the story like you did. Always enjoy seeing one of your projects or on Curious Marc's channel lol
Next time we chat, I'm going to tell you in person what a superb job I think you did on this video...fantastic! So well done, and I learned a LOT by watching this! Thank you.
I remember knowing a guy that designed ICs he had transparencies all over and overhead projector and a microscope. Talking to him it seemed like it was as much an art as a complex puzzle. He was an interesting guy. I'll never forget going to his house and seeing these diagrams and transparencies all over his house. I wonder how many actually know how to do this today. It seems like it's a very small few that actually do this now.
It's all done on computers now, but for analog and critical digital circuits, it's drawn out by hand. Most logic is laid out with APR (automatic place and route). A lay out person could do it the old way for an old chip, but new chips have many layers and the masks are 'complicated'.
That's exactly how my house looked, back in my early R&D days. Stuff pinned to the walls, green lined code listings spread across the floor. I had a very understanding wife...
When I was 17 I wrote down all the 6502 op codes. That way I found missing assembly instructions that I immediately tried, hanging my cpu quite a lot. Fun times!
I did the same thing when I was 14! I used in built in assembler (call -151) to list the assembly instructions so I could figure out what each one did. It was so fascinating.
Oh wow, I enjoyed this quite a lot. I learned on an RCA 1802 (bc I couldn't afford an Apple ][ or Atari 400 / 800 as a kid) but graduated to the 6502 (and later 68000) a few years later. Though these days I do mostly firmware / embedded and mobile, it's _quite_ nice sometimes to travel back to the early days like this 🙂
Really fascinating video, that finally makes sense of two conflicting stories I had heard. Shame it took YT 1 year to tell me the video existed. Also thanks for the explanation of rotate left in the comments.
I was a tech at CalComp in the early '70's. They built drum and flatbed plotters. One of the test plots we would run was called "IC Mask on Strippable Film" (RubyLith)
I remember reading from the BYTE magazine back then that a reader had discovered that Microsoft BASIC floating point performance on Commodore PET (IIRC) was inferior to some other computer with the 6502. He traced it into the floating point math using seven times rotate left (or some such, forget the exact details and wont bother to get out a pen and paper) instead rotate right. When confronted with that Microsoft (small company back then) responded that some in some early 6502 chips the rotate right 'did not work correctly'. I think this can be (one) reason why or how this rumour started.
Ah, Rubylith. The reason masks in Photoshop are red. Fascinating story. Things can get missed when cutting down a complicated project in a hurry. Congratulations on your Monster 6502. Does it run fast at all? Pretty lights!
I wish you would do more videos. Sometimes, in interviews, the interviewers will talk over you just as you are about to say something interesting and they change the subject. This is not inherently terrible, it's their show they are running but I would like to see more of this type of video where you are allowed to speak everything without being interrupted and with you in full control of the topics.
It was intentional at one level (they made no effort to put it in). It was unintentional at a higher level (the market required it). The 6502 was designed to implement the minimum set of instructions that the market wanted to see in a cheap processor. On the whole, I call this a bug. If they had labelled the fixed cpu mos6503, then it was not a bug.
Way cool explanation and video. As is often joked about MS bugs 'Its a feature' When I was a teen working with the 6502 in my Atari 800, I always thought it would be somewhat simple to make a "monster 6502" out of 7400 series logic gates and wanted to make one. The closest I've come across and built was Ben Eater's 8 bit breadboard CPU/computer though my version of his project has all registers 8 bit instead of some registers only 4 bit with instruction code/operand sharing the same byte split into two 4 bit sections.
I remember working on the 6502 back in the day (circa 1983/4) and we found a bug in the chip. I don't recall the exact nature, but it involved a problem when an address was in an operand and the operand went across a page boundary. Basically, when it was fetching the third byte (so the second byte of the operand) it didn't increment the upper byte of the address, resulting in the byte being read from a page lower than where it should. Very obscure, almost impossible to spot / reproduce and I seem to recall losing weeks of development trying to track down a bug in our code, that wasn't a bug in out code! The fix was to put in a NOP or two to prevent the operand spanning the page boundary. Fun times....
"Note: If you get clocks for less than $5, buy the mcs6501 and give your purchasing agent a bonus." This ad was/is absolute gold! Sadly for my purchasing agent I still will not be paying him as the alarm clocks he buys are over $10. Not sure what alarm clocks have to do with microcontrollers... also makes me wonder why I have the same purchasing agent buying me microcontrollers and alarm clocks, could it possibly be because he is me? Nah, what would that have to do with things?
2:03 - "And at this price an enterprising young engineer" It's Woz, right? 2:21 - "That engineer was Steve Wozniak" I mean was that supposed to surprise us?
I think Woz could actually get a 6800 for free from HP as an engineer there to use even on personal projects. The Apple I board has straps that allow that processor to be used instead of a 6502, though I haven't heard of anyone actually doing that. But since he wanted other people to build his design, the price of the CPU would matter quite a bit to them.
I recall an ACTUAL silicon bug in the original 8080, possibly fixed in the 8080A, but the AI robot Overlord couldn't find any details about it: "The 8080 and 8080A microprocessors were two closely related microprocessors developed by Intel in the 1970s and 1980s. The 8080A was an enhanced version of the 8080, with some minor improvements and bug fixes. The 8080A had a faster maximum clock speed than the 8080, with a limit of 3.125 MHz compared to the 8080’s limit of 2 MHz. The 8080A also had a few additional instructions that were not present in the 8080." Also: "There was a bug in the 8086 microprocessor, which was released in 1978. The bug caused the processor to return incorrect results for certain division operations. Intel fixed the bug in later versions of the 8086." There is a very fine line between a feature and a bug, but those were bugs.
there are bugs in the 6502 that carried through the later 6510's used on the C64 such as the indirect jump bug. Electronic Arts used the X2 crash "bug" as part of their copy protection on certain games.
Has anyone done ported the reverse engineered 6502 to a modern place and route system? It'd be interesting to see how much better it could do on area. I guess you'd want to model the original process to get a fair comparison.
Like the show. I had no access to the rev A back then so I did not know about the rumor, I started with the 8080 that I bought from radio shack for under $20. My main issue was hand assembly of 6502 code, was with relitive jumps. You had to make sure it didn't cross a page boundry and you didn't necessarily know the location as you typed it. Luckily most of the linkers could catch it so as long as you were not doing by hand no problem.
I'm pretty sure relative jumps could cross page boundaries, but they could not jump further that one signed byte. Crossing a page boundary may taken an extra cycle, not sure about that.
@@ronald3836 I was referring to the NMOS version of the part. Relitive jumps did not increment the Page when reading the second byte so the jump was wrong, if it split the page boundry. I believe it was corrected with the CMOS version. If you were using an assembler with a updated linker it would not allow it to happen. You can find a better description on line. I only encountered it while hand debugging( hand assembly)
@@user-fr3hy9uh6y Interesting! My experience is with the 6510 from the C64, but that is NMOS. I thought the 6510 was essentially identical to the NMOS 6502. The C64 programmer's reference guide confirms the 2/3/4 cycles for branch not taken/taken/taken+crossing. So if relative jumps could not cross a page boundary in the early versions, I suppose it was fixed quite early on? (I doubt the 6510 really is different here, but I could be wrong.)
Good to know my mid 80's VIC20 had a non buggy processor in it! Also kudos for making such a high quality yt video explaining all these details. Liked and subscribed (and commented - anything [free] I can do to boost your channel)
I'm glad you cleared this up. I hope Adrian's Digital Basement issues an apology to Chuck Peddle for his video "This 6502 processor has a hardware bug"
Excellent video, Eric! And excellently illustrated. Especially the info about the layout process was interesting. Oh I hope that manufacturing of very small gate count, small volume custom ICs will become viable in the future and we will see people producing new 6502s and similar in tiny packages. :)
I'll never get tired with stories about this CPU. After all, as a kid I spent tons of time programming it and learning how to organize larger ideas into smaller parts encoded with these ascetic commands. What was it - only 56 commands and (impressive) 13 addr modes?
If the ROR instruction had never been added and documented, there would be no reason to call it a bug. But as it is, the very first 6502 cpus cannot run all of today's 6502 programs. For all intents and purposes, they are bugged/broken.
@@ronald3836 That's the catch -- a lot of older software relies on undocumented instructions. Since you said the first 6502's cannot run all 6502 programs --- I'm just saying modern 6502's can run all 6502 programs.
I'm not a silicon/transistor designer, just a coder with rudimentary knowledge in logic design. What I wonder is why there needs to be a copy of the carry it? If you were to design a shift register using discrete logic you would use a a D-latch for every bit. You don't need extra latches for the other bits so why you need it for the carry which is just an other latch? You just route the carry out to the first latch in, that should do it. If you want to implement a shift right, just add a mux to the input of the first latch that so that it takes in either a zero or the carry bit. Obviously with pure transistors things are slightly different but still I wonder this explanation of a 'copy of the carry' bit ... i
Indeed, if they can shift bits 0-7 into 1-7 and c in one clock, then surely the same can be done with c into 0. ROR applied to the accumulator is two clocks, and probably one is for obstruction decoding. 2 is minimum for the 6502.
6502/6510 ROR and ROL rotate carry in and rotate out to Carry, it's not direct circular as some mcu are. e.g. bit 0 to does not move to bit 7, Carry is more like the extra 9th bit. Weird that they included LSR instead of a ROR, as the LSR could been simulated with a CLC.
Why is a register called a register? Is it because of the everyday meaning where you bring two things together and adjust one to match the other, then allow them to separate keeping the information? Eg, put face to name at conference registration, match water levels in a river lock, match diagram orientation via registration marks, and therefore, match voltage levels especially similar to a river lock?
The low cost of the 6502 wasn't just due to it being barebones, it was the first of a new class of chip and manufacturing process which boosted yield nearly an order of magnitude. Just for reference: Adjusting for general price inflation $25 and $300 back in 1975 would be around $200 and $2400 today. (You could buy a Cadillac for $6000 and a commuter car for $2200)
@@ronald3836 The numbers I have are 16 mm² for the 6800 and 21 mm² for the 6502, so the latter was actually larger though it had slightly fewer transistors. In a couple of years Motorola had dropped the price enough that both were selling for the same thing.
@@jecelassumpcaojr890 originally it was 29mm2 for the 6800, according to Wikipedia. This was reduced to 16.5mm2 in 1975 in a redesign that used depletion-mode NMOS (which the 6502 used from the start). So the main advantage of the 6502 over the original 6800 (lower cost through higher yield) seems to be the result more of the new process technology that had become available and less of the design being simpler (although that will have helped, too).
Interesting, the undertone is also that it was a good candidate for a cost reduction chopping block because it had some complexity coming with it. Thanks for the explanation. I guess modern CPUs check their instructions and all have an actual illegal instruction errors (I assumes it comes witht the capability bits, ands other CPU variants)? And said instruction checking subsystem is more complex than an entire 1975 CPU?
We just started studying the NIOS II architecture designed to be run on FPGAs. This architecture has the ability to raise an exception if an instruction isn't implemented (common being multiply and divide). If the exception handling part is written properly, then the exception handler can be used to emulate the missing instruction without the original program knowing it doesn't exist. I'm not sure about other architectures though.
I'm not sure if they would have wanted to spare the bytes in those days. If you know you've got some machines that don't support ROR it's just more space efficient to code around it. Otherwise there were many machines that never used such revision of the 6502 and so it was always safe to assume it was usable
I think ROR was included in certain early documentation, hence the bug confusion. Also, It is funny how a simple ROR was initially left out (not needed in a barebones simple CPU)...but BCD was included.
At that time it was an essential functionality, as computers were mainly used for numeric calculations, and often used 7-segment displays as a user interface. CPUs were also used to build... calculators.
this brought back a memory from 2014... the minecraft mod RedPower 2 has a brilliant 6502 emulator. i was writing a full C compiler IDE (using cc65, scintilla and some direct minecraft integration) to support it. that is, until i ran into a bug with the emulator's SBC instruction mishandling a status register flag.. i even wrote some code to check the compiled C assembly for the issue and inject some extra instructions for a work-around. it worked, but unfortunately meant that some of the 8-bit branch/jump instructions also had to be changed because the extra instructions could push the destination out of 256 byte range, so they would have to be changed to long jumps... got too complicated and i gave up lol.
Growing up in the 80s, well, it was a long time ago now, but I'm pretty sure 6502 assembly language guide I had showed 2 shifts but only 1 rotate. Being something like 11 years old, I just assumed the other rotate wasn't needed. Now... I guess it was the guide was in a magazine; it wasn't exactly top quality.
OK, LSR (Logical Shift Right) could have been used instead, but if you are dividing a 16 bit number with LSR, you need extra commands getting the carry flag into the 7th bit of the lowest byte after the shift operation, so not having a ROR instruction was really an issue. It may sound strange, but LSR seems less important to me than a proper ROR instruction.
Yes the LSR could been simulated with a CLC, Simulating ROR would require BCC to skip over the ORA #$80 line, but that would be direct circular ROR that current 6502 ROR is not. So you would need to BCC before the LSR, to two different LSR sections, one that has ORA #$80.
You forgot to mention: Although 6502 programs could be written without ROR using different accommodation depending on the situation, some programmers used a standard sequence of instructions that did the same thing as ROR, probably expanded from an assembler macro named "ROR" -- it was simple to use, but bloated the machine code slightly with the unusual "multi-byte instruction". Programs that used the sequence could run on 6502A or 6502B, but were slower; programs that used the ROR instruction could run only on 6502B, but were faster. Some people pointed out a way to patch their programs, replacing the work-around code with the new instruction, to increase speed (though not reduce program size). I have not seen the ROR sequence nor the typical code that was put in its place (probably something like ROR NOP NOP NOP?). What code sequence did they use to replace ROR?
Is this also the reason the 6502 and 6510 have the instruction LSR (logical shift right) and ASL (arithmetic shift left)? The latter shifts bits into bit 7 which is the sign bit, so yes, seems to be named on purpose.
Note that LSL==ASL but ASR!=LSR. The 6502 is missing the ASR insturction, and I guess the market did not complain about it (but did about the missing ROR).
We had a lot of fun with the undocumented HCF instruction on the 6800. Named "Halt and Catch Fire" jokingly because it entered an endless loop incrementing the address lines with every opcode read. It was useful for scoping all the address and data lines. I forget the opcode byte now but I think it was close to 3F, maybe 8F.
Some folks are asking about the rotate *left* instruction - wouldn't that have the same problem? I forgot to mention it in the video, but the 6502's rotate left is a little weird. It just adds the number to itself, with the carry coming in and going out just like in a regular add (ADC) operation. A pipeline delay takes care of the rest.
Reusing the ADC path is certainly a hacky but legitimate way of building a ROL instruction and would explain why they didn't plan for the ROR.
I'm going to have to use "it's not a bug... It's a missing feature." :) Good to see you on UA-cam.
CLOSED -> WORKING AS DESIGNED.
Are you friends?
It's always fun to catch up with him on twitch!
Wow. A suit jacket. Was not expecting that.
You look sharp!
Great explanation that the "bug" was a feature or lack thereof.
I have an old MOS kim-1 dev board with the white ceramic package in a box somewhere. Been meaning to dig that out.
Yeah ... beat me to it LOL
Good explanation - if it were an implementation bug, you'd find defective circuitry, not an absence of any. Nice to get conclusive details.
Is it a bug if its intentionally masked out ? Would you find defective circuitry if its masked out ? or would you find blank spaces and tracks to nowhere if an intended instruction hadn't been resolved in time for the release date ?
All fascinating stuff though.
@@garyc3476 😵💫"Though". 😵💫 The designers left out one (or many!) nice-to-have instructions, some possibly decided in the last days due to lack of space. They documented no ROR instruction. The 6502A was complete and bug-free. When a new model 6502B came out, with identical specs and behavior except that one instruction was added, that was no bug either. Compared to the 1976 model, the 1975 model looked *AS* *IF* it were the new model with a defect introduced (undefined behavior instead of ROR).
Nowadays, new instructions can be added (and bugs fixed) retroactively. The BIOS chip can update the CPU microcode after-the-fact, at power-up. Undefined instructions can trigger interrupts that call routines that emulate the missing instructions.
Knowing that these first processors, already complex with thousand of transistors, were designed with big sheets by *hand* is mindblowing. Hat's off to those people.
Indeed! You can also say the same about old school animation.
Thanks for the hat tip dude! Thems were the days, no CAD... tape all day long!
@@kirkhamandy I wasn't this deep into it but I was a PC board layout artists in the mid 80s for a communications company. It was all done with layout tape and rub on transfer solder pads on clear mylar and then photo etched to copper clad boards. I have worked with rubylith, but that was for large scale art silk screening. The owner of the company contracted a programmer to attempt to create a PCB layout program to run on the fledgling IBM PC but he never got the "pathing" to work well enough to use it. I think that was when my eyesight started to blur. We used a lot of micro-miniature surface mount components dealing with microwave tolerances and I stupidly refused to use the desktop magnifier.
Case of chicken and egg :-)
@@3DPDK I also did PCBs in the 80s. We used blue and red tape for double sided PCBs. I used to get paranoid when I had just sent off a design to be manufactured and got home to discover a bit of red or blue tape stuck to my arm!
Kudos for talking to one of the designers. And thankful that the original source was still available.
0:51 The ubiquitous ARM microprocessor also worked the first time. Designed by a team of 4 at Acorn Risc Machines (ARM) of Cambridge UK in 1985, it took just 1 week from sketchpad to first working silicon. Really impressive.
Not only it worked the first time, it worked without power supply attached 😀
Well said, Peter. The ARM lives on in tons of mobile devices. That initial realisation of a working design was a truly remarkable achievement by some incredibly talented people.
Surely it was designed at acorn?
@@benholroyd5221 You are correct. Arm as a company did not exist until many years later.
This is what fascinates me about history. Stories come up that dominate the reality of what actually happened. We don't even have a clear idea of what happened 50 years ago let alone 2000 years ago.
History often ends up being the most popular story, not what actually happened. And if repeated enough, no one will believe any other version…
But we do know how the weather will be in 50yrs. If you dars to question it, you are climate collapse denialer
@@matthiaslipinsky501 No, we don't. We know how the climate will be in 50 years, given we do X. But the climate and the weather are two different things. To stay in the same area, we cannot predict even a single raindrop, and yet we can predict that it will rain and how much. Single raindrops are much, much harder to predict than the weather, which in turn is much, much harder to predict than the climate.
Also, "climate collapse"? The climate doesn't collapse. It just changes. Ecosystems, however, can easily collapse if it changes too fast.
Oh, and you're not a denier for asking questions - you're a denier (and a conspiracy theorist) if you claim that the vast majority of climate scientists are somehow lying about it.
@@KaiHenningsen according to Greta's youth, the "climate has collapsed". And yes, if we now have a strong rain flooding houses being built closed to a river or in flood areas, that is not because we reduced rivers area, but because "climate change"
And sure you come up with "deniaer" to stop any discussion in lack of arguments. And yes, all "experts" say this. If they wouldnt, they wouldnt being called experts, but denialers or conspiracy theorists or Trump supporters or whatever
@@matthiaslipinsky501climate and weather are different things.
I'm 65 years old and just happy to see there are still "chip" nerds! Great video!
In the MOS manuals that came with my KIM-1, it was documented as not being available until after June 1976. An errata sheet had initially said it would be available in production quantities by May 1976. That said, my KIM doesn't have it. Back then we relied on vendor documentation and as we had no internet, I never heard this rumor.
Copy of the January 1976 manual with confirmation on p.150:
archive.6502.org/books/mcs6500_family_programming_manual.pdf
August 1975 data sheet which does not mention ROR:
archive.6502.org/datasheets/mos_6501-6505_mpu_preliminary_aug_1975.pdf
I imagine the "confusion" is that the majority of the documentation for the 6502 shows the ROR instruction so unless you have the original then you'd think it didn't work. People are very bad at looking at notes on data sheets, and when those data sheets get used in manuals and articles its details like this that get omitted. If you've been told there is a bug in the early version people obviously didn't bother lo look for the correct data sheet to check it out.
i think people consider it a bug because the 6501 was suppose to be a drop in replacement for the MC6800. the MC6800 has ROR while the 6501 and early 6502s don't.
3:33 No. Joke. I was just reading 6502 Assembly books yesterday. And I found one that had a nice graphic that explained the difference between shift and rotate. It was a big "ah ha" moment for me. It is just funny to me to have it explained well twice within two days!
WOW! That was really cool. I can't believe that I have been working with computers since 1982 and this is the first time I have seen what the circuits look like under a microscope. And I loved the circuit diagram explaining the physical circuit. Thanks so much!
Really fun video. I recall the definition of "Bug" from my youth (the 1970s) - a bug is a feature you don't like. In this case, it's a missing feature. Thanks much for this video!
Coincidentally, many years ago I wrote a VHDL model of a microprocessor, and it actually did have a bug in the ROR instruction. It took a while to find it, because most of the code written that used the instruction didn't tickle it, but eventually I found what I thought was a bug in the program that turned out to be a bug in the microprocessor itself. I can see why the original designers didn't include it, as most of the code I've written for my own CPU rarely uses ROR in its original form. Instead, I typically force the carry bit clear in order to use the instruction as a right shift, since the instruction set didn't include shift instructions. In fact, I so rarely use ROR with the carry intact that I added a compile-time switch that effectively turns it into a logical shift right.
Nice mix of silicon archeology and myth busting!
This was a very interesting video!
Interestingly, in modern Atari 2600 programming, using unimplemented instructions is actually sometimes used to save ROM space!
Awesome deep dive. I would argue the original run of 6502s behave in an unexpected way when running the ROR instruction which is one of the definitions of a bug. (Even if the underlying reason is that the instruction isn't fully implemented in hardware.) I think this is the age old argument if a missing feature in a released product is a bug or just a "missing feature" and there are many arguments both ways. A thought experiment could be: if MOS has not marked ROR "as not working" on the original datasheet, would this problem then be considered a bug? (Supposedly ROR was listed on the original datasheet but it said it would not work until 1976) Either way, clearly it isn't a flaw in the silicon or design, and that was really cool to see.
the feature wasn't implemented and wasn't in the documentation. MOS announced later on that they were going to implement it.
@@TubeTimeUS correct.. it can't "fail" something it never had even if something else in the future had an instruction added it is not possible for the original to be buggy.
@@ingmarm8858- not always true. If you manufactured a product, but left out a feature that was expected to be present by the market, even if not in your specification, what would your rivals call it?
@@ingmarm8858They turned it into a bug by creating an incompatibility with the early chips.
@@TubeTimeUSThe January 1976 manual listed ROR as a regular instruction with in parentheses (available after June 1976). Admitting there is a bug without admitting it...
Would have loved to share this with my dad! He was able to meet Chuck Peddle way back when in the 70s and used the 6502 in a bunch of old printers of the era.
I remember one of the undocumented instructions. Some people ended up calling it LDAX which loaded both the accumulator and the X-register with the same value.
My preferred undocumented was DCP (DCM): DEC oper + CMP oper that combined a decrement and a comparison so it was very appropriate for loop counter to zero and saved a couple cycles in a loop.
If it's true that there were no plans to implement ROR, then why is there a perfect spot in the opcode decodes for ROR, right alongside ASL, LSR, and ROL? It may not be a bug, but it's not a missing feature either. It would be a planned but unimplemented or cancelled feature.
That's simply because the opcodes were designed to use very regular bit patterns, so as to be easy to decode. So for example, the shift direction is a specific bit in all the shift instructions. Then if you have three shift instructions, two which shift left and one which shifts right, then there's an obvious place for the second right-shifting instruction, and it's free because there is no obvious other instruction that would have fit there. It's completely what you would expect.
@@KaiHenningsen There's definitely a lot of cheating going on in the instruction decoder which is why a lot of unused opcodes do things that similarly coded opcodes do. At the time, a true microcode ROM would have been as big as the CPU itself.
Great video! I remember Adrian Black talking about this ROR thing awhile back on his youtube channel, but he didn't really get into the story like you did. Always enjoy seeing one of your projects or on Curious Marc's channel lol
Yes he incorrectly said it was a bug at the time, nice to see this video definitively dispel that myth.
I've seen that video too. And i'm pretty sure this one is a direct reaction to Arians story.
Next time we chat, I'm going to tell you in person what a superb job I think you did on this video...fantastic! So well done, and I learned a LOT by watching this! Thank you.
This is amazing. Thanks for taking us on a tour into the inmost dens of the 6502! Your statements are so well-explained. Great work!
I remember knowing a guy that designed ICs he had transparencies all over and overhead projector and a microscope. Talking to him it seemed like it was as much an art as a complex puzzle. He was an interesting guy. I'll never forget going to his house and seeing these diagrams and transparencies all over his house. I wonder how many actually know how to do this today. It seems like it's a very small few that actually do this now.
My dad just did it on computers his whole working life (80s+) designing CPUs for big blue :)
It's all done on computers now, but for analog and critical digital circuits, it's drawn out by hand. Most logic is laid out with APR (automatic place and route). A lay out person could do it the old way for an old chip, but new chips have many layers and the masks are 'complicated'.
That's exactly how my house looked, back in my early R&D days. Stuff pinned to the walls, green lined code listings spread across the floor. I had a very understanding wife...
@@BritishBeachcomber I bet she knew you had a very understanding credit line
When I was 17 I wrote down all the 6502 op codes. That way I found missing assembly instructions that I immediately tried, hanging my cpu quite a lot. Fun times!
I did the same thing when I was 14! I used in built in assembler (call -151) to list the assembly instructions so I could figure out what each one did. It was so fascinating.
Oh wow, I enjoyed this quite a lot. I learned on an RCA 1802 (bc I couldn't afford an Apple ][ or Atari 400 / 800 as a kid) but graduated to the 6502 (and later 68000) a few years later. Though these days I do mostly firmware / embedded and mobile, it's _quite_ nice sometimes to travel back to the early days like this 🙂
Really fascinating video, that finally makes sense of two conflicting stories I had heard. Shame it took YT 1 year to tell me the video existed. Also thanks for the explanation of rotate left in the comments.
You should make more videos. This was excellent.
Thank you so much for blessing us with your knowledge and insights. It's very exciting to see you post on UA-cam.
I was a tech at CalComp in the early '70's. They built drum and flatbed plotters. One of the test plots we would run was called "IC Mask on Strippable Film" (RubyLith)
Excellent presentation setting right the historical record. Thank you for sharing.
been a good while since I've had such an informative video come up. gives me more of a reason to look more into the 6502 then I already have
I remember reading from the BYTE magazine back then that a reader had discovered that Microsoft BASIC floating point performance on Commodore PET (IIRC) was inferior to some other computer with the 6502. He traced it into the floating point math using seven times rotate left (or some such, forget the exact details and wont bother to get out a pen and paper) instead rotate right. When confronted with that Microsoft (small company back then) responded that some in some early 6502 chips the rotate right 'did not work correctly'. I think this can be (one) reason why or how this rumour started.
And I would say it is simply the truth. If they had called the updated 6502 a 6503, then this issue had been avoided.
Not many UA-cam videos?
One per year!
That's why I am subscribing!
Ah, Rubylith. The reason masks in Photoshop are red.
Fascinating story. Things can get missed when cutting down a complicated project in a hurry.
Congratulations on your Monster 6502. Does it run fast at all? Pretty lights!
I wish you would do more videos. Sometimes, in interviews, the interviewers will talk over you just as you are about to say something interesting and they change the subject. This is not inherently terrible, it's their show they are running but I would like to see more of this type of video where you are allowed to speak everything without being interrupted and with you in full control of the topics.
thanks for the kind words! i'm planning to make more videos in 2024. we'll see how it goes.
Man alive. I saw an original 6502 chip for sale on eBay. They wanted $2,400 for it! Insane.
In other words: it was a bug, but they knew about it before release and decided to scrub mention of it instead of fixing it. :)
It was intentional at one level (they made no effort to put it in). It was unintentional at a higher level (the market required it).
The 6502 was designed to implement the minimum set of instructions that the market wanted to see in a cheap processor.
On the whole, I call this a bug. If they had labelled the fixed cpu mos6503, then it was not a bug.
That mega scale 6502 just earned you a new subscriber 😯
Way cool explanation and video.
As is often joked about MS bugs 'Its a feature'
When I was a teen working with the 6502 in my Atari 800, I always thought it would be somewhat simple to make a "monster 6502" out of 7400 series logic gates and wanted to make one.
The closest I've come across and built was Ben Eater's 8 bit breadboard CPU/computer though my version of his project has all registers 8 bit instead of some registers only 4 bit with instruction code/operand sharing the same byte split into two 4 bit sections.
I remember working on the 6502 back in the day (circa 1983/4) and we found a bug in the chip. I don't recall the exact nature, but it involved a problem when an address was in an operand and the operand went across a page boundary. Basically, when it was fetching the third byte (so the second byte of the operand) it didn't increment the upper byte of the address, resulting in the byte being read from a page lower than where it should. Very obscure, almost impossible to spot / reproduce and I seem to recall losing weeks of development trying to track down a bug in our code, that wasn't a bug in out code! The fix was to put in a NOP or two to prevent the operand spanning the page boundary.
Fun times....
I would have no idea what all of this means if I hadn't watched the SAP-1 (Ben Eater) set of videos, thankfully they are available nowadays
Love the cores having an ASR instruction, probably the most underused one it is :)
"Note: If you get clocks for less than $5, buy the mcs6501 and give your purchasing agent a bonus." This ad was/is absolute gold! Sadly for my purchasing agent I still will not be paying him as the alarm clocks he buys are over $10. Not sure what alarm clocks have to do with microcontrollers... also makes me wonder why I have the same purchasing agent buying me microcontrollers and alarm clocks, could it possibly be because he is me? Nah, what would that have to do with things?
Very educational and historical video and well explained! Thanks!
a early Zilog processor also left out a rotate. I don't remember which way it was, but I had to do 7 rotates the other way to send serial data.
This is fascinating, and very easy to understand. Thanks for the explanation!
2:03 - "And at this price an enterprising young engineer"
It's Woz, right?
2:21 - "That engineer was Steve Wozniak"
I mean was that supposed to surprise us?
I think Woz could actually get a 6800 for free from HP as an engineer there to use even on personal projects. The Apple I board has straps that allow that processor to be used instead of a 6502, though I haven't heard of anyone actually doing that. But since he wanted other people to build his design, the price of the CPU would matter quite a bit to them.
That certainly brightened up my day as a 6502 user in the late 70's. Great presentation and I hope your day is enjoyable too!
I recall an ACTUAL silicon bug in the original 8080, possibly fixed in the 8080A, but the AI robot Overlord couldn't find any details about it:
"The 8080 and 8080A microprocessors were two closely related microprocessors developed by Intel in the 1970s and 1980s.
The 8080A was an enhanced version of the 8080, with some minor improvements and bug fixes. The 8080A had a faster maximum clock speed than the 8080, with a limit of 3.125 MHz compared to the 8080’s limit of 2 MHz. The 8080A also had a few additional instructions that were not present in the 8080."
Also:
"There was a bug in the 8086 microprocessor, which was released in 1978. The bug caused the processor to return incorrect results for certain division operations. Intel fixed the bug in later versions of the 8086."
There is a very fine line between a feature and a bug, but those were bugs.
Wow! That explains a lot. Thanks for this clarifying video.
My favorite processor is the 6502 ❤
Great video! Now I should get back to working on the "missing features" in my projects.
there are bugs in the 6502 that carried through the later 6510's used on the C64 such as the indirect jump bug.
Electronic Arts used the X2 crash "bug" as part of their copy protection on certain games.
I remember that bug (or missing feature) - I think it was in whatever I used to learn the CPU. I don't remember any others right now, though.
Nice explanation. I appriciate your work on this.
This is one of my favorite videos
Has anyone done ported the reverse engineered 6502 to a modern place and route system? It'd be interesting to see how much better it could do on area. I guess you'd want to model the original process to get a fair comparison.
Like the show. I had no access to the rev A back then so I did not know about the rumor, I started with the 8080 that I bought from radio shack for under $20. My main issue was hand assembly of 6502 code, was with relitive jumps. You had to make sure it didn't cross a page boundry and you didn't necessarily know the location as you typed it. Luckily most of the linkers could catch it so as long as you were not doing by hand no problem.
I'm pretty sure relative jumps could cross page boundaries, but they could not jump further that one signed byte.
Crossing a page boundary may taken an extra cycle, not sure about that.
Indeed a branch instruction takes 2 clocks, 1 more if taken, still 1 more if a page boundary is crossed.
@@ronald3836 I was referring to the NMOS version of the part. Relitive jumps did not increment the Page when reading the second byte so the jump was wrong, if it split the page boundry. I believe it was corrected with the CMOS version. If you were using an assembler with a updated linker it would not allow it to happen. You can find a better description on line. I only encountered it while hand debugging( hand assembly)
@@user-fr3hy9uh6y Interesting! My experience is with the 6510 from the C64, but that is NMOS. I thought the 6510 was essentially identical to the NMOS 6502. The C64 programmer's reference guide confirms the 2/3/4 cycles for branch not taken/taken/taken+crossing.
So if relative jumps could not cross a page boundary in the early versions, I suppose it was fixed quite early on? (I doubt the 6510 really is different here, but I could be wrong.)
Aren't you thinking of the indirect jump bug? JMP ($10FF) will take the high byte from $1000 instead of $1100, and this was fixed in the CMOS version.
Fingles Law of Dynamic Negative Corollary: "If it works on the first try, there's a bug in the compiler."
Good to know my mid 80's VIC20 had a non buggy processor in it! Also kudos for making such a high quality yt video explaining all these details. Liked and subscribed (and commented - anything [free] I can do to boost your channel)
Phenomenal explanation. Thank you.
That was a great video. It clearly presented and explained the subject. I love to see more about the 6502 replica you talked about at 4:54.
I saw a video about the design of the Amiga. At first the custom chips had been implemented by hand wiring a huge circuit board.
I'm glad you cleared this up. I hope Adrian's Digital Basement issues an apology to Chuck Peddle for his video "This 6502 processor has a hardware bug"
Great video! @5:00, wait you're the Monster guy?!
Have seen videos were this is explained in great detail, haven't seen videos were they said it wasn't by design...
Amazing work, please make more UA-cam videos.
Excellent well presented video. I have been enlightened!
This is awesome, thank you for doing it!
You: The fact the circuitry is missing is proof it is not a bug.
Me: The circuitry being missing is the bug.
Every time I see you I’ll just “magic finger guy”.
Excellent video, Eric! And excellently illustrated. Especially the info about the layout process was interesting. Oh I hope that manufacturing of very small gate count, small volume custom ICs will become viable in the future and we will see people producing new 6502s and similar in tiny packages. :)
Good stuff, glad to see this broken down with all the gritty details.
Well hello! Long time Twitter follower, please do more!
I'll never get tired with stories about this CPU. After all, as a kid I spent tons of time programming it and learning how to organize larger ideas into smaller parts encoded with these ascetic commands. What was it - only 56 commands and (impressive) 13 addr modes?
If the ROR instruction had never been added and documented, there would be no reason to call it a bug.
But as it is, the very first 6502 cpus cannot run all of today's 6502 programs. For all intents and purposes, they are bugged/broken.
And modern 6502 CPUs can't run all of the OLD software --
By many definitions they are buggy. ;)
@@r3jjs modern 6502s run all programs that employ only documented instructions.
@@ronald3836 That's the catch -- a lot of older software relies on undocumented instructions.
Since you said the first 6502's cannot run all 6502 programs --- I'm just saying modern 6502's can run all 6502 programs.
It's clearly not a bug if there is no instruction!
Excellent video. Subbed, now to follow you on Mastodon.
What about the ROL instruction? The same kind of circuitry to latch it would be required there, too. Is it present in the REV A?
I'm not a silicon/transistor designer, just a coder with rudimentary knowledge in logic design. What I wonder is why there needs to be a copy of the carry it? If you were to design a shift register using discrete logic you would use a a D-latch for every bit. You don't need extra latches for the other bits so why you need it for the carry which is just an other latch? You just route the carry out to the first latch in, that should do it. If you want to implement a shift right, just add a mux to the input of the first latch that so that it takes in either a zero or the carry bit. Obviously with pure transistors things are slightly different but still I wonder this explanation of a 'copy of the carry' bit ... i
Indeed, if they can shift bits 0-7 into 1-7 and c in one clock, then surely the same can be done with c into 0.
ROR applied to the accumulator is two clocks, and probably one is for obstruction decoding. 2 is minimum for the 6502.
Instruction decoding...
very interesting, thanks eric!
6502/6510 ROR and ROL rotate carry in and rotate out to Carry, it's not direct circular as some mcu are.
e.g. bit 0 to does not move to bit 7, Carry is more like the extra 9th bit.
Weird that they included LSR instead of a ROR, as the LSR could been simulated with a CLC.
Love hearing about my first processor :-)
Why is a register called a register? Is it because of the everyday meaning where you bring two things together and adjust one to match the other, then allow them to separate keeping the information? Eg, put face to name at conference registration, match water levels in a river lock, match diagram orientation via registration marks, and therefore, match voltage levels especially similar to a river lock?
The low cost of the 6502 wasn't just due to it being barebones, it was the first of a new class of chip and manufacturing process which boosted yield nearly an order of magnitude.
Just for reference: Adjusting for general price inflation $25 and $300 back in 1975 would be around $200 and $2400 today. (You could buy a Cadillac for $6000 and a commuter car for $2200)
One reason for the improved yield must have been its small die size, which was the result of it being barebones.
@@ronald3836 The older processes were slower and had huge defect rates, like 80% was unusable waste.
@@ronald3836 The numbers I have are 16 mm² for the 6800 and 21 mm² for the 6502, so the latter was actually larger though it had slightly fewer transistors. In a couple of years Motorola had dropped the price enough that both were selling for the same thing.
@@jecelassumpcaojr890 originally it was 29mm2 for the 6800, according to Wikipedia. This was reduced to 16.5mm2 in 1975 in a redesign that used depletion-mode NMOS (which the 6502 used from the start).
So the main advantage of the 6502 over the original 6800 (lower cost through higher yield) seems to be the result more of the new process technology that had become available and less of the design being simpler (although that will have helped, too).
@@TheDuckofDoom. My conclusion is that you are fully correct.
UA-cam just recommended your videos to me, love the explanation on stuff like this! Thanks!
Adrian's digital basement had one show up. He tested it and it worked in an apple 2
Interesting, the undertone is also that it was a good candidate for a cost reduction chopping block because it had some complexity coming with it. Thanks for the explanation. I guess modern CPUs check their instructions and all have an actual illegal instruction errors (I assumes it comes witht the capability bits, ands other CPU variants)? And said instruction checking subsystem is more complex than an entire 1975 CPU?
We just started studying the NIOS II architecture designed to be run on FPGAs. This architecture has the ability to raise an exception if an instruction isn't implemented (common being multiply and divide). If the exception handling part is written properly, then the exception handler can be used to emulate the missing instruction without the original program knowing it doesn't exist. I'm not sure about other architectures though.
You could probably have coded around that missing opcode. Detect a failed ror, and compensate with some extra opcodes
I'm not sure if they would have wanted to spare the bytes in those days. If you know you've got some machines that don't support ROR it's just more space efficient to code around it. Otherwise there were many machines that never used such revision of the 6502 and so it was always safe to assume it was usable
Quick try at a ROR replacement if you don't have a ROR instruction. Accumulator version.
BCC .label
LSR
ORA #$80
BNE .label1
.label:
LSR
.label1:
@@djmips LSR A
BCC skip
ORA #$80
skip: ...
Whoops, nope nevermind. Just realised I'm totally wrong here.
@@IcyTorment Wouldn't you need to ROL eight times? With the carry bit there are 9 bits in total rolling around.
I think ROR was included in certain early documentation, hence the bug confusion. Also, It is funny how a simple ROR was initially left out (not needed in a barebones simple CPU)...but BCD was included.
The BCD functions of the 6502 where the one aspect MOS where able to completely copyright so as much as functionality it was to protect their IP
At that time it was an essential functionality, as computers were mainly used for numeric calculations, and often used 7-segment displays as a user interface. CPUs were also used to build... calculators.
@@JenslilCorner Didn't work though. Nintendo just went ahead and used a version with the BCD disabled...
@@djmips yeh they did
this brought back a memory from 2014... the minecraft mod RedPower 2 has a brilliant 6502 emulator. i was writing a full C compiler IDE (using cc65, scintilla and some direct minecraft integration) to support it. that is, until i ran into a bug with the emulator's SBC instruction mishandling a status register flag.. i even wrote some code to check the compiled C assembly for the issue and inject some extra instructions for a work-around. it worked, but unfortunately meant that some of the 8-bit branch/jump instructions also had to be changed because the extra instructions could push the destination out of 256 byte range, so they would have to be changed to long jumps... got too complicated and i gave up lol.
@@Ignat99Ignatov fascinating! thanks for sharing :)
And ROTFL is the ROtate Through Flags Left instruction that didn't work out...?
Growing up in the 80s, well, it was a long time ago now, but I'm pretty sure 6502 assembly language guide I had showed 2 shifts but only 1 rotate. Being something like 11 years old, I just assumed the other rotate wasn't needed. Now... I guess it was the guide was in a magazine; it wasn't exactly top quality.
OK, LSR (Logical Shift Right) could have been used instead, but if you are dividing a 16 bit number with LSR, you need extra commands getting the carry flag into the 7th bit of the lowest byte after the shift operation, so not having a ROR instruction was really an issue.
It may sound strange, but LSR seems less important to me than a proper ROR instruction.
Yes the LSR could been simulated with a CLC, Simulating ROR would require BCC to skip over the ORA #$80 line, but that would be direct circular ROR that current 6502 ROR is not.
So you would need to BCC before the LSR, to two different LSR sections, one that has ORA #$80.
You forgot to mention: Although 6502 programs could be written without ROR using different accommodation depending on the situation, some programmers used a standard sequence of instructions that did the same thing as ROR, probably expanded from an assembler macro named "ROR" -- it was simple to use, but bloated the machine code slightly with the unusual "multi-byte instruction". Programs that used the sequence could run on 6502A or 6502B, but were slower; programs that used the ROR instruction could run only on 6502B, but were faster. Some people pointed out a way to patch their programs, replacing the work-around code with the new instruction, to increase speed (though not reduce program size). I have not seen the ROR sequence nor the typical code that was put in its place (probably something like ROR NOP NOP NOP?). What code sequence did they use to replace ROR?
That’s nuts!
Is this also the reason the 6502 and 6510 have the instruction LSR (logical shift right) and ASL (arithmetic shift left)? The latter shifts bits into bit 7 which is the sign bit, so yes, seems to be named on purpose.
Note that LSL==ASL but ASR!=LSR. The 6502 is missing the ASR insturction, and I guess the market did not complain about it (but did about the missing ROR).
How many revision A chips were produced?
We had a lot of fun with the undocumented HCF instruction on the 6800. Named "Halt and Catch Fire" jokingly because it entered an endless loop incrementing the address lines with every opcode read. It was useful for scoping all the address and data lines. I forget the opcode byte now but I think it was close to 3F, maybe 8F.
Drop Dead - 0xDD. Though 9D would give the same effect, I believe.