R65C02 in a Beeb

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
BigEd
Posts: 1967
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: R65C02 in a Beeb

Post by BigEd » Sat Feb 03, 2018 6:12 pm

It's not totally surprising that the CMOS part is a bit marginal, especially with the unusually fast edge rates, but it's a major surprise to me that it would affect SBC and nothing else!

An excellent adventure.

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

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 6:30 pm

This is my current hypothesis as to what's happening here.

I think it's to do with the setup time margin when the CPU is sampling the read data from the DRAM.

First let's look at the R6502A. Here's a scope plot showing the CPU's Phi2 (pin 37) at the top and the DRAM CAS0 at the bottom:
IMG_1228.JPG
What you can just make out from the cursors is the time from the falling edge of CAS0 to the falling edge of Phi2 is 108ns.

I've chosen Phi2 as that is the 6502's timing reference (for all the timing diagrams in the data sheet).

So is this good or bad?

What has to fit into that 108ns is:
- the DRAM read from CAS: HM4816A-3 DRAM tCAC=55ns max
- the delay through IC14: 74LS245 tPD=8ns typ, 12ns max
- the read data setup time of the R6502A: tDSU=50ns

Worst case timing: 55ns + 12ns + 50ns = 117ns, which gives a setup time margin of -9ns. A negative margin is not good!

And it's possibly worse... because the delay through IC14 may be greater than 12ns, as the Beeb data bus has ~18 TTL loads, which would be ~90pF which is twice what the 74LS245 is specified at.

But hey, it works doesn't it?

So now let's look at the R65C02P2. Again, here's a scope plot showing Phi2 at the top and CAS0 at the bottom:
IMG_1229.JPG
The timings are actually identical: falling edge of CAS0 to falling edge of Phi2 is 108ns.

So let's repeat the above calculation:
- the DRAM read: HM4816A-3 DRAM tCAC=55ns max
- the delay through IC14: 74LS245 tPD=8ns typ, 12ns max
- the read data setup time of the R65C02P2: tDSU=60ns (this value is 10ns more that the R6502A)

Worst case timing: 55ns + 12ns + 60ns = 127ns, which gives a setup time margin of -19ns. Definitely not good.

Now, by adding a small capacitor to slow down Phi0, the falling edge of Phi2 is also shifted out, increasing the setup time margin a bit. For example, 47pF shifts Phi2 by 6ns. Not much, but that seems to be enough to make it reliable again.

I knew the Beeb timing was "tight" but it's rather a shock just how bad it is!

Unless of course my Beeb has a fault that makes these timings much worse than is typical.

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

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 6:56 pm

So this seems to be the answer, though I was mislead slightly by the menu-driven tests. I tried adding a 47pF cap across pins 37 to 1 on top of the 65C02 and rather than selection of failures I was getting before I was getting one specific failure:
20180203_181011.jpg
Then I tried 100pF but that didn't improve the test outcome. Given that the address 58B4 did seem to match a check within the listing I had for the test I checked what was on the test disk and tried running +.65C02 directly from the command line which has now passed a few times. It looks like the menu is running the 6502 (NMOS) test despite detecting a 65C02 so maybe that's failing due to the corrected ZP wrap-around bug.

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

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 7:04 pm

Coeus wrote: I tried adding a 47pF cap across pins 37 to 1 on top of the 65C02 and rather than selection of failures I was getting before I was getting one specific failure.
That still looks like the same SBC related failure. Might be worth trying a 100pF cap.

To avoid confusion, do try using the disc image I posted in the opening post of this thread. The listing for that is here:
https://github.com/hoglet67/6502_65C02_ ... /D6502.lst

The Dormann 6502 test exercises the instructions that are common to both the 6502 and 65C02. The Dormann 65C02 test exercises the additional 65C02 specific instructions. So on a 65C02 you should be running both suites.

On my disk images, with a Rockwell 65C02, you should run the following two programs:
- *D6502
- *D65C11

Dave

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

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 7:51 pm

I've just measured a second Beeb with a different processor: a SY6502A. The time from CAS0 to Phi2 (Pin 39) is 109ns, so only 1ns different. So I think we can rule out any timing peculiarities with my specific Beeb.

Also the RAM seems to be significantly faster than 55ns, more like 35ns in practice, so the CPU setup time is just being met.

Dave

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 8:17 pm

hoglet wrote:Also the RAM seems to be significantly faster than 55ns, more like 35ns in practice, so the CPU setup time is just being met.
Wasn't there a thread a few days back where it was mentioned that the memory address multiplexers were critical in the sense that, while officially available from more than one supplier, in practice only one supplier's part actually worked? Or am I mis-remembering.

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 8:24 pm

hoglet wrote:To avoid confusion, do try using the disc image I posted in the opening post of this thread. The listing for that is here:
https://github.com/hoglet67/6502_65C02_ ... /D6502.lst
Ok with your disk image it reliably fails at PC=717E. If I hit C to continue there are more failures at the same address. All together:

A=01, PS=31
A=81, PS=31
A=C1, PS=71 (twice)
A=81, PS=31 (again, twice this time)
A=81, PS=B1

This is with the 100pF.
Last edited by Coeus on Sat Feb 03, 2018 8:30 pm, edited 1 time in total.

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

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 8:29 pm

Coeus wrote: Wasn't there a thread a few days back where it was mentioned that the memory address multiplexers were critical in the sense that, while officially available from more than one supplier, in practice only one supplier's part actually worked? Or am I mis-remembering.
FYI, here's the DRAM data sheet:
http://stardot.org.uk/mirrors/www.bbcdo ... HM4816.pdf

I don't think the address multiplexers are actually on the critical timing path for data coming out. But if they are two slow, the wrong address in the DRAM will be read.

You might be remembering this post from Mark:
http://www.stardot.org.uk/forums/viewto ... 37#p190237

IC14, the 74LS245, is indeed a critical component, and now we can see from a timing perspective just why.

Dave

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

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 8:35 pm

Coeus wrote: Ok with your disk image it reliably fails at PC=717E. If I hit C to continue there are more failures at the same address. All together:

A=01, PS=31
A=81, PS=31
A=C1, PS=71 (twice)
A=81, PS=31 (again, twice this time)
A=81, PS=B1
PC=717E on the stack corresponds to the jsr report_error at 717C, which is the flag test after a SBC immediate:
https://github.com/hoglet67/6502_65C02_ ... lst#L17553

In the error dumps, zero page location 57 shows the expected flag value (a mask of C3 is applied so only NV----ZC are compared).

That's just about the same as what I was seeing before I added the capacitor.

Did you try a larger capacitor? 100pF or 220pF?

Dave

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 8:46 pm

hoglet wrote:Did you try a larger capacitor? 100pF or 220pF?
This was with 100pF. i don't have anything bigger. It is an improvement over my results in the previous thread, though. According to http://www.cpu-world.com/info/id/Rockwe ... ation.html the 3 at the end of R65C02P3 means a 3Mhz processor so faster than the 2Mhz version I think you have been testing. I assume the way this capacitor slows down the clock edge is by being an RC network with the output resistance of the chip so would a faster chip have a lower o/p resistance and need more capacitance to slow the edge enough?

So does that mean the 4Mhz version might not be a fake after all but even more affected by this marginal timing the point it is obviously unreliable?

Then, looking at the ZP values carry it only ever set when it should be clear, never the other way round. There was one case where carry was correct and the N flag was wrong:
20180203_210408.jpg
Last edited by Coeus on Sat Feb 03, 2018 9:13 pm, edited 1 time in total.

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

Re: R65C02 in a Beeb

Post by hoglet » Sat Feb 03, 2018 9:10 pm

Coeus wrote:This was with 100pF. i don't have anything bigger. It is an improvement over my results in the previous thread, though. What does the P2, P3 or P4 on the end of the part number signify?
It signifies a 2MHz, 3MHz or 4MHz speed part.

I've just tried my R65C02P4, and the 47pF capacitor is not sufficient to fix the Dormann test failures.

(Edit: But 100pF is)

On the scope the delay from CAS0 to Phi2 has reduced to 96ns (it was 108ns with the P2 part).

The timing margin is now:
- 96ns
- less the DRAM read: HM4816A-3 DRAM tCAC=55ns max
- less the delay through IC14: 74LS245 tPD=8ns typ, 12ns max
- less the read data setup time of the R65C02P4: tDSU=30ns
= -1ns

So this should work better than the P2, but doesn't.

Then again, the part is more than likely a fake, so the timings could be anything!
Coeus wrote: So looking at the ZP values carry it only ever set when it should be clear, never the other way round. There was one case where carry was correct and the N flag was wrong:20180203_210408.jpg
I'm seeing exactly the same.

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

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sat Feb 03, 2018 9:35 pm

hoglet wrote:So this should work better than the P2, but doesn't.

Then again, the part is more than likely a fake, so the timings could be anything!
Interesting. It seems like there may be some merit in trying bigger values so I will see what I can get tomorrow. I would try the 47pF in parallel with the 100pF but I can no longer find the 47pF.

User avatar
AlanD
Posts: 241
Joined: Fri Jan 09, 2009 8:30 pm
Contact:

Re: R65C02 in a Beeb

Post by AlanD » Sun Feb 04, 2018 9:03 am

Hello Dave
I had to fit a 74ALS245 to get my beeb to work with a 65C02

AlanD

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

Re: R65C02 in a Beeb

Post by hoglet » Sun Feb 04, 2018 9:27 am

AlanD wrote: I had to fit a 74ALS245 to get my beeb to work with a 65C02
Interesting. There is also mention of that here, together with a slightly more involved modification.
http://www.sprow.co.uk/bbc/howto.htm#cmosupgrade

Dave

SteveBagley
Posts: 155
Joined: Sun Mar 15, 2015 8:44 pm
Contact:

Re: R65C02 in a Beeb

Post by SteveBagley » Sun Feb 04, 2018 1:30 pm

Coeus wrote:Wasn't there a thread a few days back where it was mentioned that the memory address multiplexers were critical in the sense that, while officially available from more than one supplier, in practice only one supplier's part actually worked? Or am I mis-remembering.
Furber directly describes this problem on one of his Computerphile videos on YouTUBE — with the 81LSxx chips iirc.

Steve

Coeus
Posts: 900
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: R65C02 in a Beeb

Post by Coeus » Sun Feb 04, 2018 8:08 pm

200pF from 37 to 1 (VSS) seems to have done the trick on the 3Mhz R65C02 - it now passes the Dormann tests. (5 out of 5) as well as the extended opcode test.

dominicbeesley
Posts: 588
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: R65C02 in a Beeb

Post by dominicbeesley » Mon Feb 05, 2018 12:03 am

Out of interest did you (please could you) measure how much this:

a) shifts phi1/phi2 relative to the ram clock*
b) shifts the databuffer enable relative to the ram clock

I suspect they might be shifted by different amounts due to the CMOS part having different thresholds?

* I'm not sure what to use as the benchmark timing edge? Maybe pin 5 of IC30?

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

Re: R65C02 in a Beeb

Post by hoglet » Mon Feb 05, 2018 10:15 am

dominicbeesley wrote:Out of interest did you (please could you) measure how much this:

a) shifts phi1/phi2 relative to the ram clock*
b) shifts the databuffer enable relative to the ram clock

I suspect they might be shifted by different amounts due to the CMOS part having different thresholds?

* I'm not sure what to use as the benchmark timing edge? Maybe pin 5 of IC30?
Here's some measurements of PHI2, CAS0 and IC14 EN (Pin 19) with a R65C02P2 fitted.

I'm running the following code:

Code: Select all

P%=&2000
[SEI:JMP&2001
CALL&2000
First, with no capacitor fitted:
IMG_1235.JPG
Next, with a 220pF capacitor fitted:
IMG_1238.JPG
So adding a 220pF capacitor moves:
- the falling edge of CAS0 from to -107.6ns to -137.6ns (i.e. back by 30.0ns)
- the rising edge of CAS0 from +22.6ns to -7.6ns (i.e. back by 30.2ns)
- the falling edge of IC14EN from -247.6ns to -265.1ns (i.e. back by 17.5ns)
- the rising edge of IC14EN from -17.6ns to -15ns (i.e. forward by 2.6ns)

You can see it also changes the mark-space ratio of Phi2 quite a bit.

I would say on my system 220pF is probably too large.

Dave

dominicbeesley
Posts: 588
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: R65C02 in a Beeb

Post by dominicbeesley » Mon Feb 05, 2018 12:37 pm

Thanks for measuring that, the IC14 signal doesn't seem to have moved that much relative to the phi2 edge so it looks like its that relationship between the memory clocks and phi2?

I'll have a try of my stock of cmos parts tonight if I get a chance

D

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

Re: R65C02 in a Beeb

Post by 1024MAK » Mon Feb 05, 2018 12:44 pm

Most of the DRAM controls (including the data transceiver) are derived from the clock outputs of the videoproc (2MHz, 4MHz and 8MHz outputs). So would not be greatly affected by the CPU phase 1 clock being tweaked.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

dominicbeesley
Posts: 588
Joined: Tue Apr 30, 2013 11:16 am
Contact:

Re: R65C02 in a Beeb

Post by dominicbeesley » Mon Feb 05, 2018 1:56 pm

No but the cpu might be affected by trying to read data from RAM before it is ready!

D

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

Re: R65C02 in a Beeb

Post by 1024MAK » Mon Feb 05, 2018 3:49 pm

dominicbeesley wrote:No but the cpu might be affected by trying to read data from RAM before it is ready!

D
Yes, of course the timing relationship between the DRAM and the CPU is important. And that is the likely reason that the type of address multiplexers is critical, and that IC14 (74LS245 data transceiver) has to work well within it's spec.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

Post Reply