R65C02 in a Beeb

discuss both original and modern hardware for the bbc micro/electron
User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

R65C02 in a Beeb

Post by hoglet » Fri Feb 02, 2018 5:39 pm

Hi all,

I'm wondering if anyone else is running an R65C02 in their Beeb? I have a couple of these:
- a R65C02P2 date code 8424 that I think is original
- a R65C02P4 date code 1145 that is probably a fake

I've been trying to capture some logic analyzer traces from these for testing the 6502 protocol decoder. But I'm having some rather unusual stability issues...

Both seem very stable in the Beeb under normal operation. For example I can leave Elite running for ages with no problem.

However, as soon as I try to run the Beeb Dormann 6502 tests, I'm seeing failures. They are not 100% consistent, but it seems like the wrong flag coming out of a SBC (decimal mode off).

What's interesting is that my 6502 protocol decoder also flags a failure at the same point, and it seems to be correcting C to 1.

Code: Select all

713E : F0 03    : BEQ 7143       : 3 : A=00 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=1 C=1
7143 : 28       : PLP            : 4 : A=00 X=54 Y=FF SP=FD N=0 V=1 D=0 I=0 Z=1 C=0
7144 : 08       : PHP            : 3 : A=00 X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=1 C=0
7145 : A5 54    : LDA 54         : 3 : A=00 X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=1 C=0
7147 : 8D 12 32 : STA 3212       : 4 : A=00 X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=1 C=0
714A : A5 53    : LDA 53         : 3 : A=3A X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=0 C=0
714C : 20 11 32 : JSR 3211       : 6 : A=3A X=54 Y=FF SP=FA N=0 V=1 D=0 I=0 Z=0 C=0
3211 : 69 00    : ADC #00        : 2 : A=3A X=54 Y=FF SP=FA N=0 V=0 D=0 I=0 Z=0 C=0
3213 : 60       : RTS            : 6 : A=3A X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=0
714F : 08       : PHP            : 3 : A=3A X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=0 C=0
7150 : C5 55    : CMP 55         : 3 : A=3A X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=1 C=1
7152 : F0 03    : BEQ 7157       : 3 : A=3A X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=1 C=1
7157 : 68       : PLA            : 4 : A=30 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
7158 : 29 C3    : AND #C3        : 2 : A=00 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=1 C=1
715A : C5 57    : CMP 57         : 3 : A=00 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=1 C=1
715C : F0 03    : BEQ 7161       : 3 : A=00 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=1 C=1
7161 : 28       : PLP            : 4 : A=00 X=54 Y=FF SP=FD N=0 V=1 D=0 I=0 Z=1 C=0
7162 : 08       : PHP            : 3 : A=00 X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=1 C=0
7163 : A5 58    : LDA 58         : 3 : A=FF X=54 Y=FF SP=FC N=1 V=1 D=0 I=0 Z=0 C=0
7165 : 8D 15 32 : STA 3215       : 4 : A=FF X=54 Y=FF SP=FC N=1 V=1 D=0 I=0 Z=0 C=0
7168 : A5 53    : LDA 53         : 3 : A=3A X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=0 C=0
716A : 20 14 32 : JSR 3214       : 6 : A=3A X=54 Y=FF SP=FA N=0 V=1 D=0 I=0 Z=0 C=0
3214 : E9 FF    : SBC #FF        : 2 : A=3A X=54 Y=FF SP=FA N=0 V=0 D=0 I=0 Z=0 C=0
3216 : 60       : RTS            : 6 : A=3A X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=0
716D : 08       : PHP            : 3 : A=3A X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=0 C=1 prediction failed
716E : C5 55    : CMP 55         : 3 : A=3A X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=1 C=1
7170 : F0 03    : BEQ 7175       : 3 : A=3A X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=1 C=1
7175 : 68       : PLA            : 4 : A=31 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
7176 : 29 C3    : AND #C3        : 2 : A=01 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
7178 : C5 57    : CMP 57         : 3 : A=01 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
717A : F0 03    : BEQ 717F       : 2 : A=01 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
717C : 20 DF 73 : JSR 73DF       : 6 : A=01 X=54 Y=FF SP=FA N=0 V=0 D=0 I=0 Z=0 C=1
73DF : 08       : PHP            : 3 : A=01 X=54 Y=FF SP=F9 N=0 V=0 D=0 I=0 Z=0 C=1
73E0 : 48       : PHA            : 3 : A=01 X=54 Y=FF SP=F8 N=0 V=0 D=0 I=0 Z=0 C=1
73E1 : 8A       : TXA            : 2 : A=54 X=54 Y=FF SP=F8 N=0 V=0 D=0 I=0 Z=0 C=1
73E2 : 48       : PHA            : 3 : A=54 X=54 Y=FF SP=F7 N=0 V=0 D=0 I=0 Z=0 C=1
73E3 : 98       : TYA            : 2 : A=FF X=54 Y=FF SP=F7 N=1 V=0 D=0 I=0 Z=0 C=1
73E4 : 48       : PHA            : 3 : A=FF X=54 Y=FF SP=F6 N=1 V=0 D=0 I=0 Z=0 C=1
73E5 : D8       : CLD            : 2 : A=FF X=54 Y=FF SP=F6 N=1 V=0 D=0 I=0 Z=0 C=1
73E6 : A2 00    : LDX #00        : 2 : A=FF X=00 Y=FF SP=F6 N=0 V=0 D=0 I=0 Z=1 C=1
73E8 : AD B8 74 : LDA 74B8       : 4 : A=0A X=00 Y=FF SP=F6 N=0 V=0 D=0 I=0 Z=0 C=1
73EB : 20 A0 74 : JSR 74A0       : 6 : A=0A X=00 Y=FF SP=F4 N=0 V=0 D=0 I=0 Z=0 C=1
74A0 : 20 EE FF : JSR FFEE       : 6 : A=0A X=00 Y=FF SP=F2 N=0 V=0 D=0 I=0 Z=0 C=1
FFEE : 6C 0E 02 : JMP (020E)     : 6 : A=0A X=00 Y=FF SP=F2 N=0 V=0 D=0 I=0 Z=0 C=1
E0A4 : 48       : PHA            : 3 : A=0A X=00 Y=FF SP=F1 N=0 V=0 D=0 I=0 Z=0 C=1
E0A5 : 8A       : TXA            : 2 : A=00 X=00 Y=FF SP=F1 N=0 V=0 D=0 I=0 Z=1 C=1
The JSR 73DF is the Dormann test report_failure subroutine. Here's the same point in the source:
https://github.com/hoglet67/6502_65C02_ ... lst#L17553

Both R65C02's behave in a similar fashion in two different Beebs. But what's really interesting is that neither fail in the Atom, running the same Dormann tests at the same speed (2MHz). So I'm guessing this is down to the fact the Beeb's data bus is very heavily loaded, coupled with possibly different logic thresholds of the CMOS 6502.

If anyone else is running a R65C02 in their Beeb, would they mind trying the Dormann tests:
dormann.ssd
(200 KiB) Downloaded 30 times
There are two programs to try:
- *D6502 tests the normal instructions
- *D65C11 tests the additional C02 instructions

I'd be very interested to see if:
- other people see failures of either of these tests
- whether those failures are consistent, so please try running it a few times

Dave

User avatar
1024MAK
Posts: 9906
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: R65C02 in a Beeb

Post by 1024MAK » Fri Feb 02, 2018 6:01 pm

A while ago I did a basic test of some 65C02 CPUs (that I had bought earlier in the year) in one of my model B machines (issue 7 board). I only checked that they started up okay and ran a simple BASIC test program. But they all appeared to work okay.

I also tried them on a 6502 SBC where I could measure the supply current on the +5V rail. One "65C02" consumed far more current than a CMOS chip should, so I concluded that it was a remarked NMOS 6502. The rest all had a low supply current consistent with CMOS parts.

Mark

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Fri Feb 02, 2018 6:04 pm

This recent thread is quite interesting as well: Fake, too slow, of just defective?

The fact the same Dormann tests pass in the Atom makes me think this is somehow environmental.

Dave

dp11
Posts: 1095
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: R65C02 in a Beeb

Post by dp11 » Fri Feb 02, 2018 6:18 pm

Can't say why but It might be worth looking at the SO pin 38?

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: R65C02 in a Beeb

Post by BigEd » Fri Feb 02, 2018 6:40 pm

It feels like the PHP is perhaps pushing the wrong value of C - as opposed to C being wrong as the result of SBC. If you put in a

Code: Select all

   BCC skip
   NOP
skip:
just before the PHP, you'd see whether C is set or not at that point. Is that useful to know? I'm not sure.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Fri Feb 02, 2018 6:49 pm

That's a nice idea Ed - I'll try it tomorrow.

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: R65C02 in a Beeb

Post by flynnjs » Fri Feb 02, 2018 6:56 pm

hoglet wrote: I'm wondering if anyone else is running an R65C02 in their Beeb? I have a couple of these:
- a R65C02P2 date code 8424 that I think is original
I'm running a R65C02P2 date code 8426 and have had it since brand new.
I'll try to run some tests this weekend.

dominicbeesley
Posts: 1013
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: R65C02 in a Beeb

Post by dominicbeesley » Fri Feb 02, 2018 8:07 pm

Could it be marginal write hold times or other timing issues...it's what I'm battling with at the moment along with limits for the relationship between phi0/phi2 for stable operation.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Fri Feb 02, 2018 8:56 pm

dominicbeesley wrote:Could it be marginal write hold times or other timing issues...it's what I'm battling with at the moment along with limits for the relationship between phi0/phi2 for stable operation.
It's all a bit peculiar. If it was an external timing issue, I would expect more of the Dormann test cases would provoke it, not to mention playing normal games. I also tried a load of freezer spray on the 65C02, and that didn't seem to change anything. It seems very specific to the carry out of SBC. Anyway, Ed's suggestion earlier will shed some light on this. As will Jason trying the tests's on hist 65C02.

Dave

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Fri Feb 02, 2018 10:26 pm

BigEd wrote:It feels like the PHP is perhaps pushing the wrong value of C - as opposed to C being wrong as the result of SBC. If you put in a

Code: Select all

   BCC skip
   NOP
skip:
just before the PHP, you'd see whether C is set or not at that point. Is that useful to know? I'm not sure.
OK, here's that code added, with bus cycles as well:

Code: Select all

0 28 1 1 1
1 08 0 1 1
2 30 0 1 1
3 73 0 1 1
7161 : 28       : PLP            : A=00 X=54 Y=FF SP=FD N=0 V=1 D=0 I=0 Z=1 C=1
0 08 1 1 1
1 a5 0 1 1
2 73 0 0 1
7162 : 08       : PHP            : A=00 X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=1 C=1
0 a5 1 1 1
1 58 0 1 1
2 e0 0 1 1
7163 : A5 58    : LDA 58         : A=E0 X=54 Y=FF SP=FC N=1 V=1 D=0 I=0 Z=0 C=1
0 8d 1 1 1
1 15 0 1 1
2 32 0 1 1
3 e0 0 0 1
7165 : 8D 15 32 : STA 3215       : A=E0 X=54 Y=FF SP=FC N=1 V=1 D=0 I=0 Z=0 C=1
0 a5 1 1 1
1 53 0 1 1
2 2c 0 1 1
7168 : A5 53    : LDA 53         : A=2C X=54 Y=FF SP=FC N=0 V=1 D=0 I=0 Z=0 C=1
0 20 1 1 1
1 14 0 1 1
2 30 0 1 1
3 71 0 0 1
4 6c 0 0 1
5 32 0 1 1
716A : 20 14 32 : JSR 3214       : A=2C X=54 Y=FF SP=FA N=0 V=1 D=0 I=0 Z=0 C=1
0 e9 1 1 1
1 e0 0 1 1
3214 : E9 E0    : SBC #E0        : A=4C X=54 Y=FF SP=FA N=0 V=0 D=0 I=0 Z=0 C=0
0 60 1 1 1
1 c3 0 1 1
2 4d 0 1 1
3 6c 0 1 1
4 71 0 1 1
5 32 0 1 1
3216 : 60       : RTS            : A=4C X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=0
0 90 1 1 1
1 01 0 1 1
716D : 90 01    : BCC 7170       : A=4C X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=0 prediction failed
0 ea 1 1 1
1 08 0 1 1
716F : EA       : NOP            : A=4C X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=0
0 08 1 1 1
1 c5 0 1 1
2 31 0 0 1
7170 : 08       : PHP            : A=4C X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=0 C=1 prediction failed
0 c5 1 1 1
1 55 0 1 1
2 4c 0 1 1
7171 : C5 55    : CMP 55         : A=4C X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=1 C=1
0 f0 1 1 1
1 03 0 1 1
2 20 0 1 1
7173 : F0 03    : BEQ 7178       : A=4C X=54 Y=FF SP=FB N=0 V=0 D=0 I=0 Z=1 C=1
0 68 1 1 1
1 29 0 1 1
2 6c 0 1 1
3 31 0 1 1
7178 : 68       : PLA            : A=31 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
0 29 1 1 1
1 c3 0 1 1
7179 : 29 C3    : AND #C3        : A=01 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
0 c5 1 1 1
1 57 0 1 1
2 00 0 1 1
717B : C5 57    : CMP 57         : A=01 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
0 f0 1 1 1
1 03 0 1 1
717D : F0 03    : BEQ 7182       : A=01 X=54 Y=FF SP=FC N=0 V=0 D=0 I=0 Z=0 C=1
0 20 1 1 1
1 e1 0 1 1
2 31 0 1 1
3 71 0 0 1
4 81 0 0 1
5 73 0 1 1
717F : 20 E1 73 : JSR 73E1       : A=01 X=54 Y=FF SP=FA N=0 V=0 D=0 I=0 Z=0 C=1
The inputs into SBC seem to be:
- C = 1
- A = 0x2C
- operand = 0xE0

So I think the outputs should be
- C = 0 (indicating a borrow has occurred)
- A = 0x4C

But from the BCC branch not being taken it looks like C = 1, which is later confirmed by the PHP

(The emulator could correct C when it detect the prediction failed on the BCC, it doesn't currently do this, but does on PHP)

Dave
Last edited by hoglet on Fri Feb 02, 2018 10:46 pm, edited 2 times in total.

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: R65C02 in a Beeb

Post by BigEd » Fri Feb 02, 2018 10:37 pm

Hmm, and that's a different SBC from last time... Is SBC tested before ADC? Is it always an SBC which fails? I wonder if there's some pattern sensitivity such that the E9 opcode is more problematic than the 69 opcode?? I'm supposing - not sure why - that the opcode is affecting the reliability of reading the operand.

Could you arrange that A is written to memory so we can see that part of the result of the computation too?

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Fri Feb 02, 2018 10:49 pm

BigEd wrote:Hmm, and that's a different SBC from last time... Is SBC tested before ADC? Is it always an SBC which fails? I wonder if there's some pattern sensitivity such that the E9 opcode is more problematic than the 69 opcode?? I'm supposing - not sure why - that the opcode is affecting the reliability of reading the operand.

Could you arrange that A is written to memory so we can see that part of the result of the computation too?
Yes, it's definitely not consistent. I'll add some more debugging tomorrow.

After the SBC, the order of checking is:
- test the accumulator (against location 55)
- test the flags (against location 57)

It appears the result of the SBC is always correct (which suggests the operands were read correctly).

I've extended the above trace snippet so you can see this.

Dave

User avatar
BigEd
Posts: 2996
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: R65C02 in a Beeb

Post by BigEd » Sat Feb 03, 2018 8:59 am

That is odd. If SBC is tested first, it might be worth reversing that to see if ADC ever fails. If ADC is already tested first and never fails, that's a datapoint.

dp11
Posts: 1095
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: R65C02 in a Beeb

Post by dp11 » Sat Feb 03, 2018 10:36 am

Maybe worth adding a little more decoupling. Also might be worth looking at the clock signal .

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 10:43 am

BigEd wrote:That is odd. If SBC is tested first, it might be worth reversing that to see if ADC ever fails. If ADC is already tested first and never fails, that's a datapoint.
It iterates through the various input values, and for each it tests ADC first and the SBC.

I'm not sure at the moment whether ADC is ever failing.

Bruce Clark's full BCD tests work correctly, so it seems like a binary mode issue only.

Dave

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 10:44 am

dp11 wrote:Maybe worth adding a little more decoupling. Also might be worth looking at the clock signal .
I'll check this out.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 11:08 am

hoglet wrote:
dp11 wrote:Maybe worth adding a little more decoupling. Also might be worth looking at the clock signal .
I'll check this out.
I added some extra decoupling between pins 1 and 8, and that made no difference.

The clock input on pin 37 looks perfect; it goes up to 3.5V, with minimal undershoot and overshoot, and no evidence of glitches.

Dave

dp11
Posts: 1095
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: R65C02 in a Beeb

Post by dp11 » Sat Feb 03, 2018 11:48 am

try tieing pin 38 directly high e.g. to pin 8.

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: R65C02 in a Beeb

Post by flynnjs » Sat Feb 03, 2018 11:49 am

hoglet wrote: I added some extra decoupling between pins 1 and 8, and that made no difference.
When I bought my R65C02, over the counter at Solidisk, the technician told me an extra
capacitor may be needed across an IC. This was way before I'd studied any electronics so I
was just following instructions. I do remember the additional ceramic disc caps being fitted.

Now, my memory is dim of this so I just lifted the lid and there are no signs of soldering
to the pins on the CPU. There are however additional disc caps across IC29 and IC37 both
on pin 11 to ground.
IC29 pin 11 is PHIin to the CPU.
IC37 pin 11 is PHI1 out of the CPU.

This seems to support the argument that the clocking must be fiddled with to support a
65C02.

Jason

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 12:02 pm

dp11 wrote:try tieing pin 38 directly high e.g. to pin 8.
That doesn't seem to change anything. There is a 3.3K pullup on this pin anyway, and so it's already at 4.97V.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 12:21 pm

flynnjs wrote:
hoglet wrote: I added some extra decoupling between pins 1 and 8, and that made no difference.
Now, my memory is dim of this so I just lifted the lid and there are no signs of soldering
to the pins on the CPU. There are however additional disc caps across IC29 and IC37 both
on pin 11 to ground.
IC29 pin 11 is PHIin to the CPU.
IC37 pin 11 is PHI1 out of the CPU.

This seems to support the argument that the clocking must be fiddled with to support a
65C02.
Can you see what value they are?

Have you managed to try the Dormann test (it's *D6502 that is failing randomly for me).

Coeus
Posts: 1496
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 1:16 pm

flynnjs wrote:This seems to support the argument that the clocking must be fiddled with to support a
65C02.
Anything to do with the clock stretching for the 1Mhz bus? Does the test suite disable interrupts? If not I wonder if it would run successfully if they were disabled. I am thinking the ISR will access 1Mhz things whereas the rest of the test suite probably won't.

User avatar
hoglet
Posts: 9110
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 1:21 pm

After some experimentation with various small capacitors, here's a bit more data.
- A capacitor between pin 37 (Phi0In) and ground is most effective and this alone fixes the problem
- A capacitor between pin 3 (Phi1Out) and ground made little or no difference, even going as high as 820pF

Here's the effect of various capacitors on the falling edge of Phi0In:
- no capacitor (just scope probe) the falling edge time is 8ns, and 5 runs of the Dormann tests all fail (5,4,12,10,11 errors)
- a 47pF capacitor increases the edge time to 14ns, and 5 runs of the Dormann tests all pass (0,0,0,0,0 errors)
- a 100pF capacitor increases the edge time to 22ns, and 5 runs of the Dormann tests all pass (0,0,0,0,0 errors)

The biggest difference between the a R6502A and an R65C02P2 on the scope is the rise time of Phi1:
- R6502A - risetime (10% to 50%) is 55ns
- R65C02P2 - risetime (10% to 50%) is 14ns

So I can easily understand, given how tight the timing is on the Beeb, why the capacitor is having an effect.

Looking at the delay of 2MHzE wrt Phi0In (measured at 2V), the 100pF capacitor doesn't make a massive difference
- R6502A: falling edge delayed by 55ns, rising edge delayed by 43ns
- R6502P2: falling edge delayed by 37ns, rising edge delayed by 30ns
- R6502P2 + 100pF: falling edge delayed by 40ns, rising edge delayed by 31ns

So it's possible it's having an effect in another way, but the clocking on the Beeb is very complicated to understand.

Dave
Last edited by hoglet on Sat Feb 03, 2018 4:49 pm, edited 1 time in total.

dominicbeesley
Posts: 1013
Joined: Tue Apr 30, 2013 12:16 pm
Contact:

Re: R65C02 in a Beeb

Post by dominicbeesley » Sat Feb 03, 2018 1:52 pm

This is bringing back memories now of my trials with getting a 65816 to work. I think its not just that the timings are changed but that the CMOS parts are more sensitive to clock transitions and translate the slow and noisy clock into several far too fast clocks which cause incorrect behaviour. Your cap might be smoothing out some noise? maybe trying a schmidtt trigger buffer on phi0 might work?

I never did get my 65816 attempts working reliably in the cpu socket but it worked first time on the TUBE. If you get to the bottom of this I'll be interested!

D

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: R65C02 in a Beeb

Post by flynnjs » Sat Feb 03, 2018 2:20 pm

I'll have a closer peek at the cap values and run the tests tonight.

crj
Posts: 846
Joined: Thu May 02, 2013 5:58 pm
Contact:

Re: R65C02 in a Beeb

Post by crj » Sat Feb 03, 2018 3:43 pm

I've no idea of the specifics, here. But I will note that, because of the extra inverter, it would be very plausible for SBC to be the critical path in a 6502 implementation, and therefore the instruction most susceptible to clock/power supply tolerance issues.

Coeus
Posts: 1496
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 4:10 pm

hoglet wrote:...A capacitor between pin 37 (Phi0In) and ground is most effective and this alone fixes the problem.
I assume this is pin 37 of the 65C02? That looks like something I should try. Referring to my previous thread mentioned above, after the first experience of mutton dressed as lamb, when the second "R65C02" failed to work I, perhaps too quickly, concluded that eBay is just full of junk and this was just another variation on that theme. I'll see if I can find some small capacitors and see how I get on. The malfunction I experienced was not quite the same, but it is still worth a try.

cmorley
Posts: 1242
Joined: Sat Jul 30, 2016 8:11 pm
Location: Oxford
Contact:

Re: R65C02 in a Beeb

Post by cmorley » Sat Feb 03, 2018 4:41 pm

The problem is likely that all the 6502 timing for NMOS or CMOS is relative to phi2. Acorn used phi1 as the main computer clock source...

phi1 doesn't have identical relationship to phi0 (or phi2) between NMOS & CMOS. phi1 rising lags the phi2 falling edge on NMOS. It can lag or lead on a Rockwell CMOS chip.

The cap on pin 37 presumably skews the timing enough to make the phi1 kinda work again - especially as phi0 is fed into IC25 (with phi1 inverted) to generate the RAM buffer IC14 enable.

Why Acorn didn't use phi2 I have no idea. I'd love to know!

R6502
R6502.png
R65C02
R65C02.png

User avatar
flynnjs
Posts: 831
Joined: Tue Jul 06, 2010 10:33 pm
Contact:

Re: R65C02 in a Beeb

Post by flynnjs » Sat Feb 03, 2018 5:43 pm

The caps are both marked 22K. I assume that's 22pF with some type of tolerance code, not 22nF.

I'll try the test after dinner.

User avatar
1024MAK
Posts: 9906
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: R65C02 in a Beeb

Post by 1024MAK » Sat Feb 03, 2018 5:52 pm

flynnjs wrote:The caps are both marked 22K. I assume that's 22pF with some type of tolerance code, not 22nF.
Yep, most likely to be 22pF. And "K" means 10%.
This site is useful for capacitor values :wink:

Mark

Post Reply

Return to “8-bit acorn hardware”