How to test a ceramic 6502 for the ROR bug?

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

http://www.willegal.net/appleii/6502mem.htm

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.

regards,

Mike Willegal

This idea is way beyond anything that I have time for. 

regards,

Mike Willegal

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:

https://youtu.be/ewtRCdwbTEw?t=265

He has also a ROM containing the 6502 ROR bug test, which can be plugged into an Apple II:

https://github.com/misterblack1/6502_ror_bug_test/blob/main/6502-bootrom.asm

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.

Hi all,

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. 

* = $0600

         CLC

         LDA #$FF

         STA $0300

         ROR A

         STA $0301

         BCS ROROK

         LDA #$FA

         STA $0302

         JMP INFLOOP

ROROK:   LDA #$01

         STA $0302

INFLOOP: JMP INFLOOP

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:

0300.0302 ENTER

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:

Regular 6502:

ROROK.jpg

Early 6502 and 6501:

RORBUG.jpg

Enjoy! :-)

Claudio.

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

ncle Bernie comments:

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.

 

You say that like its a bad thing ?

Of course I had to try it... 

IMG_3175.jpg