so an early 6502 microprocessor has been imaged! the first versions from 1976 lacked a ROR (rotate right) instruction, so let's dig in and see what changed. 🧵
they look very similar at first glance. on the left is the 1976 revision A, and on the right is a later revision D (mfg by Rockwell, in this case).
here they are, imported into GIMP, and roughly overlaid. there are a few pads that have been moved around (mostly on the left) and the pad structures have changed.
the most obvious place to start looking for functional differences is the instruction decode ROM array.
unfortunately the rev A image has a bunch of gnarly stitching artifacts. this makes analysis a lot harder.
after careful study, i could only find four bits that were added, highlighted in red in the image below.
checking the Visual 6502, this corresponds with the op-ror net!
in the rev A 6502, it was just never decoded. this whole column never goes active. but it appears that it goes somewhere...
so it goes...nowhere? it's hard to trace because there are tons of stitching artifacts. the first little vertical branch is just polysilicon that ends and isn't used. the longer part disappears into some logic.
zooming in, take a look at the trace (rev A on the left, rev D on the right). they've repurposed it in rev D but they left the contact via behind (center).
in rev D, that disconnected contact is called node 182.
in the schematic that net has something to do with branches. i don't know why that would have been brought out of the instruction ROM in the original--it was clearly not decoded anyway.
hard to tell but that old trace also connected to (or seems to have been involved with) op-T3-branch. so it was some unused branch logic.
what's clear from this brief investigation is...
THIS IS NOT A BUG
the original, first revision 6502 did not have a "bugged" ROR instruction. it simply had no ROR instruction at all! the logic to implement it did not exist. the corresponding ROM decode line was dead logic for some unused branch instruction variant.
all of this lines up with my various conversations with Bill Mensch. apparently Chuck Peddle thought a ROR wasn't necessary and they didn't include it in the original design. it wasn't until later, when customers demanded it, that they added the instruction.
so if you tried to run an ROR instruction on a rev A 6502, what you got was...a partially decoded instruction, just like the other weird ones that typically didn't do anything, halted the CPU, or had marginally useful results.
later on, for the CMOS 65C02, Bill decoded those "extra instructions" to NOPs. chip designers sure don't like undefined behavior.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
digging through the IBM BIOS for the PS/2 Model 77, i found this interesting bit of code that tests if it is running on a 16-bit 8086/8088 or a 32-bit 286+.
while running in real mode, the BIOS tries to execute the MOV EAX,0xffaa0055 instruction. even though EAX is a 32-bit register, this is possible to run in real mode using the segment override prefix, which in this case is the 0x66 byte.
unless of course you happen to be running on a 16-bit 8088/8086, in which case the 0x66 op code aliases to the 0x76 op code, which is JBE (jump if below or equal). since a previous instruction left the zero flag set, it branches to the target.
ever wonder where these lone traffic cones come from? out of place; out of context, often with a stencil that doesn't match your city's public works department? 🧵
this cone has a buddy. they're different, but they perform the same function. who or what is TBC anyway?
despite the fact that most people treat traffic cones as shared property, they very much have owners!
some projects start with a breadboard--others start with a bare wooden plinth.
this one is a bit quick and dirty, so the parts (at least for this version) are 3d printed in a hurry.
here's a quick test fit. the two coil forms at the bottom turned out pretty nice, but i think i'll redo the other parts. brass would be a good look, i think.