Hey - Apologies if I've got the wrong sub-forum, I just thought this would be the one with the most early 6502 experts ;)What is the most effective and SAFEST way to check a ceramic 6502 for the ROR bug? I don't want to put too much stress on it.Thanks,AC
Bridged chat on:
Please support the defense of Ukraine.
Credit card, bank transfer
Bitcoin, Ethereum, Polkadot, USDT
via Unclutter App for Mac
Active forum topics
No Social Media.
All Content Locally Hosted.
Two Terabytes and Growing.
Built on Free Software.
We have complied with zero government requests for information.
Do you have access to an Apple II or Apple-1 replica? Is the chip in a carrier so you can insert/remove it without damaging the legs?
Use Mike Willegal's memory test program, make sure NOT to use the one that works around the ROR bug. He has both on his website. I believe it will crash if your chip has the ROR bug.
Here is a link to the 6502 test program...
Thanks Corey! I'll have to give it a try :) I might try to cook up something to 'safely' check 6502 chips, could be a nice little project for me. Will try to make it as cheap as possible (maybe a $10 budget for components) and will create a post to list hardware components and software used - Watch this space!
According to my web site, the version of the memory test that uses ROR will hang when run on a 6502 with the ROR problem. This was found when someone tried the memory test with one of these early chips. You might want to first try the non-ROR version of the test, to verify that everything else in the system is working well. This will also give an idea of how long that the test should take, so you know that the test really hung, and isn't taking a while.
I would swap a ZIF socket into a working motherboard of some sort in order to create a test bed for checking this processor.
Hey Mike,I bought a 40-pin ZIF socket - I'm wondering if it's possible to write something for the Arduino that can run your script and give some indication if it was successful (maybe use a green LED for pass and red LED for fail), could even have a 3rd blue LED to indicate ROR bug.Have you ever done this before? I can try to gather all the hardware needed, will probably need some kind of AVR board w/ the ZIF socket pin outs connected to the different GPIO ports... Let me know your thoughts :)
This idea is way beyond anything that I have time for.
If you have a Mimeo or a Replica 1 you could add a ZIF socket and try this to check the CPU. Unfortunately, I don't have a processor that has the ROR bug so I can't test this to be sure.
0300: A9 0D LDA #$0D ; Load linefeed
0302: 20 EF FF JSR $FFEF ; display A to screen0305: A9 01 LDA #$01 ; Set up the accumulator0307: 18 CLC ; Clear the carry flag0308: 6A ROR A ; Rotate A right for the test. ; The buggy ROR doesn't rotate ; into the carry flag, or right.0309: A2 00 LDX #$00 ; Set X to success message offset030B: B0 02 BCS $030F ; If carry set, ROR works. Output that.031D: A2 03 LDX #$03 ; Set X to fail message offset030F: BD 1D 03 LDA $031D,X ; Load A with text byte at offset X0312: 20 EF FF JSR $FFEF ; display A to screen0315: E8 INX ; Increment character offset0316: C9 00 CMP #$00 ; is it the last character?0318: D0 F5 BNE $030F ; if not then recurse031A: 4C 1F FF JMP $FF1F ; Return to woz monitor031D: 4E 4F 20 52 4F 52 20 ; NO<space>ROR<space>0324: 42 55 47 00 ; BUG<EOL>
0300: A9 0D 20 EF FF A9 01 18 :6A A2 00 B0 02 A2 03 BD :1D 03 20 EF FF E8 C9 00 :D0 F5 4C 1F FF 4E 4F 20 :52 4F 52 20 42 55 47 00
Adrian Black found a white ceramic 6502 from week 52, 1975 in his e-waste. It's an early 6502 which still has the ROR bug:
He has also a ROM containing the 6502 ROR bug test, which can be plugged into an Apple II:
However, apparently the Apple II does boot fine with the stock ROM, so it does not use ROR in any of its early boot routines, or at least the bug doesn't matter. Not sure if you could manage to load anything from tape or disk though, or enter the monitor (since that might require the ROR instruction to work).
Any ideas how many of the early 6502s, where the ROR instruction is an ASL instead, were made - and how many are known to have survived?
If you happen to have an Apple-1 (or replica), I could write you a little program that will check for the bug and that you could simply type in using the Wozmon.
this topic was already discussed on the Facebook group, in particular when a member was successful in using a 6501 on his Replica.
Hope he does not mind I used the picture he took of his screen.
6501 also, as expected, does not have the ROR function implemented. ROR's opcode acts as ASL.
For everyone's convenience, here follows my post describing a super-simple test:
Okay, here it is, quick/dirty and uncertainly functioning, although I remember once having successfully tested a (not mine) ceramic 6502 affected by the ROR lack.
In a "healthy" 6502 the ROtate Right instruction (ROR) shifts all bits one position to the right.
The Carry is shifted into bit7 and the original bit0 is shifted into the Carry.
The above program loads the value $FF (11111111) into register A, then executes the ROR instruction.
At this point A should contain the value $7F (01111111), because bit7 comes from the Carry (which before had been conveniently set to zero with CLC), and bit0 should go into the Carry.
The program performs a BCS (Branch on Carry Set), so if Carry is effectively 1, the value $01 is written to location $0302.
In the case of 6502 affected by the ROR bug, the ROR will not only behave like an ASL (Arithmetic Shift Left - shifting bits to the left instead of the right), but it will also not set the Carry to 1.
If the Carry is not 1 the BCS will not be taken, and the arbitrary value $FA (stands for FAIL...) will end up in location $0302.
Code starts from $0600:
0600: 18 a9 ff 8d 00 03 6a 8d 01 03 b0 08 a9 fa 8d 02
0610: 03 4c 19 06 a9 01 8d 02 03 4c 19 06
Type it in then run with command 0600R.
It will loop indefinitely, so stop it by pressing RESET key.
Now: examine memory locations $0300 to $302 with:
With a standard 6502 you will see something like the attached picture:
$0300 contains the initial value of A ($FF, or binary 11111111)
$0301 contains the value of A after ROR ($7F, binary 01111111, if ROR has been executed - $FE, binary 11111110 if ROR has not been executed )
$0302 will contain $01 if Carry was set correctly, or it will contain $FA in case of failure.
Please keep in mind that this is not an exhaustive ROR test, there are many sources on the Internet that analyze this topic in more detail.
Examples of results:
Early 6502 and 6501:
An interesting video came out today with very strong evidence that this indeed was never a bug, but an intentionally unimplemented instruction (which happened to act like ASL by pure chance) and which was later implemented:
The 6502 Rotate Right Myth
In post #12, CVT wrote:
"... strong evidence that this indeed was never a bug, but an intentionally unimplemented instruction ..."
Uncle Bernie comments:
Among 6502 researchers / reverse engineers it was known for years that there never was a ROR "bug", and that ROR was intentionally left out from the 1st silicon.
However, neither the pre-video findings nor this new video allow a conclusion yet which of these two conjectures is right:
a) ROR was planned for the 1st silicon but taken out during the mask design process.
b) ROR was not in the original "Objective Spec" and customers pressured MOS TECHNOLOGY to add it.
As far as I am concerned I think it was a) and it was not taken out deliberately, but because they ran into some obstacle, which would have cost them too much time to move it out of the way - they had to have the 1st silicon ready for WESCON, San Francisco, beginning on September 16, 1975 , and could not afford any delay / milestone slip.
The evidence supporting a) is that there is that empty column in the instruction decode / sequencing PLA with a dangling wire into the nowhere and that there has been enough "empty" space to put the additional logic in. That additional logic could have been there and then was removed - which in the times of Rubylith masks was easy to do, by just glueing red correction tape over the unwanted devices, which makes them disappear. Peel that correction tape off, and the devices come back !
I think that b) is highly unlikely as Chuck Peddle was a very experienced microprocessor architect and having no ROR really hurts, despite you can program around it, but this is awkward and costs more CPU cycles to do the same job.
So which is it, a) or b) ?
This could be determined by a more detailed analysis of the mask patterns of the area in question on both versions of the 6502. Just saying: "look, they added all these transistors" is not enough to prove a) or b). You need to look for evidence if the transistors could have been there but were just masked out by adding tape. This boils down to comparing the metal layers for changes needed to hook the additional logic up. Not too many changes would support a) but a complete rework with lots of changes would support b)
It's always funny to see how much time is spent on analyzing a microprocessor design that was made almost half a century ago, but a similar effect can be seen with WW II electronics, people have devoted years of their life to build collections and to document / restore ancient equipment from the time. Same with 1930s radios.
A very interesting psychological phenomenon.
- Uncle Bernie
You say that like its a bad thing ?
Of course I had to try it...