Another semi-fail - again with the W65C02

For discussing the 65xx hardware itself or electronics projects.
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Another semi-fail - again with the W65C02

Post by BillO »

HI All,

This one really has me scratching my head.

This is a different design than before. A much simpler and smaller system with a different intent. It kind of go it's start with a discussion on these boards about a minimal system for running EhBASIC and morphed into a minimal but versatile system. In any case, I'll get into more detail on that when I can get this thing running with the W65C02.

Here is the behavior. It runs absolutely fine with and NMOS or old Rockwell CMOS CPU. In fact, it behaves well over clocked with either of those.

With the W65C02 (for which I implemented the 'lessons learned' from the previous project) it sort of works. It will boot and run the EhBASIC initialization to the READY prompt. From there I can load or enter and edit programs. It will execute the LIST command with or without arguments and it will execute the PRINT command, but only without arguments.

I have tried different ways to select RAM (with and without a short delay on A15) as well as different ways to implement /OE on both the RAM and ROM chips (tied to ground, tied to /CE or tied to !R/WR [inverted R/WR]) to no avail. Delaying the A15 line for RAM select make matter worse. The other changes make no difference.

Any help would be appreciated.



Here is the schematic:
Vixen.jpg

Here is the CUPL Code:

Code: Select all

/* *************** INPUT PINS *********************/
PIN  1  =   XTL_1                 ; /*XTAL                             */ 
PIN  2  =   A14                   ; /*                                 */ 
PIN  3  =   A15                   ; /*                                 */ 
PIN  4  =   A13                   ; /*                                 */ 
PIN  5  =   A12                   ; /*                                 */ 
PIN  6  =   A11                   ; /*                                 */ 
PIN  7  =   A10                   ; /*                                 */ 
PIN  8  =   RW                    ; /*                                 */ 
PIN  9  =   A9                    ; /*                                 */ 
PIN  10 =   A8                    ; /*                                 */ 
PIN  11 =   Phi2                  ; /*                                 */ 
PIN  13 =   D3SEL                 ; /*                                 */ 


/* *************** OUTPUT PINS ********************/
PIN 14  =   R                     ; /*Low=Read, High= Write !(R/W) */
PIN 15  =   DD                    ; /*Data Direction - off-board expansion buffer */ 
PIN 16  =   DEV_1                 ; /*Device select 1 - active low */
PIN 17  =   ROM_CE                ; /*ROM Select - active low */ 
PIN 18  =   DEV_2                 ; /*Device select 2 - active low */ 
PIN 19  =   DEV_3                 ; /*Device select 3 - selectable */ 
PIN 20  =   DEV_0                 ; /*Device select 0 - active low */
PIN 21  =   RQW                   ; /*High=Read, Low=Phi-2 qualified write*/ 
PIN 22  =   OND                   ; /*Oscillator node*/  
PIN 23  =   XTL_2                 ; /*XTAL and oscillator out*/  


/* Intermediate values */
a = A10 # A11 # A12 # A13 # A14;
b = !A15 # a;						/* Low = valid I/O address */
d3 = b # !A8 # !A9;

/* Output definitions */
R = !RW;
DD = !b & RW & (A8 # A9);						/* High = read from expansion bus I/O.  Low all other times */
RQW = !(Phi2 & !RW);
ROM_CE = !A15 # !a;

DEV_0 = b # A8 # A9;
DEV_1 = b # !A8 # A9;
DEV_2 = b # A8 # !A9;
DEV_3 = D3SEL & d3 # !D3SEL & !d3;

OND = !XTL_1;
XTL_2 = !OND;
Here are some timing diagrams.

Here are I/O timings. The traces are as follows: Yellow=Phi2 (system clock), Blue= I/O CE, Red=qualified R/W, Green=DB

I/O Read using the Rockwell:
R-IOR.jpg
I/O Read using the WDC:
W-IOR.jpg
I/O Write for the Rockwell:
R-IOW.jpg
I/O Write for the WDC:
W-IOW.jpg

The following are ROM Read timings. The traces are as follows: Yellow=Phi2 (system clock), Blue= ROM CE, Red=/OE, Green=DB

For the Rockwell:
R-ROMR.jpg
For the WDC:
W-ROMR.jpg

The following are RAM read timings. The traces are as follows: Yellow=Phi2 (system clock), Blue= RAM CE, Red=/OE, Green=DB

For the Rockwell:
R-RAMR.jpg
For the WDC:
W-RAMR.jpg

The following are RAM Write timings. The traces are as follows: Yellow=Phi2 (system clock), Blue= RAM CE, Red=Qualified R/W, Green=DB

For the Rockwell:
R-RAMW.jpg
For the WDC:
W-RAMW.jpg

This is an additional view of the WDC RAM Write timing. The traces are as follows: Yellow=/OE, Blue= RAM CE, Red=Qualified R/W, Green=DB
W-RAMW2.jpg
And this final one if a general view of all the Chip Selects when running the WDC chip - just to ensure that no two devices are selected at the same time. The traces are as follows: Yellow=ROM CE, Blue= RAM CE, Red=Qualified R/W, Green=I/O CE.
W-CHIPS.jpg
EDIT - Schematic updated with more labels and notes.
Last edited by BillO on Fri Jun 15, 2018 12:01 am, edited 2 times in total.
Bill
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

Here are a couple more ROM Read timings: Yellow=Phi2 (system clock), Blue= ROM CE, Red=/OE, Green=DB

Rockwell:
R-ROMR.jpg
WDC:
W-ROMR.jpg
Here the data hold time seems much better with the WDC. Go figure...
Bill
User avatar
GaBuZoMeu
Posts: 660
Joined: 01 Mar 2017
Location: North-Germany

Re: Another semi-fail - again with the W65C02

Post by GaBuZoMeu »

Quote:
With the W65C02 (for which I implemented the 'lessons learned' from the previous project) it sort of works. It will boot and run the EhBASIC initialization to the READY prompt. From there I can load or enter and edit programs. It will execute the LIST command with or without arguments and it will execute the PRINT command, but only without arguments.
I think I don't understand what it means - PRINT does work, but only without arguments? So a PRINT "Hello World" would print nothing or went into the weeds?
Sorry if this question appears stupid to you.
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

GaBuZoMeu wrote:
Quote:
With the W65C02 (for which I implemented the 'lessons learned' from the previous project) it sort of works. It will boot and run the EhBASIC initialization to the READY prompt. From there I can load or enter and edit programs. It will execute the LIST command with or without arguments and it will execute the PRINT command, but only without arguments.
I think I don't understand what it means - PRINT does work, but only without arguments? So a PRINT "Hello World" would print nothing or went into the weeds?
Sorry if this question appears stupid to you.
Yes, it goes off into the weeds if you employ an argument whether a variable, expression or fixed string. The CPU keeps running, but I just can't determine what it is running. If it's looping, it is a long loop. Basically it does exactly the same thing as typing "RUN". You get a new line then - nothing more - and it will not respond to Ctrl-C.

Without an argument it prints a new line, then displays READY again.
Bill
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Another semi-fail - again with the W65C02

Post by BigDumbDinosaur »

I'm not getting a warm and fuzzy feeling seeing that raggedy Ø2 clock signal, plus I'm wondering why you choose to generate Ø2 the way you did.

Aside from being asymmetric (not a deal-killer at lower Ø2 rates), Ø2 has got a bit of noise and ringing riding on it. WDC MPUs are noted for being somewhat fussy about clock quality and you may well be perturbing the MPU with the signal it is getting.

WDC strongly recommends the use of an oscillator to generate Ø2, not a crystal circuit. I've got a suspicion your clock is your culprit.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

A lot of the ringing comes from scope grounding issues, but it is worse on the clock. I can use a function generator (or even hack in an Oscillator instead) to run the clock. I have tried using the function generator, through the GAL, to supply a symmetric signal - this did not help. However that effor did not 'clean' up the ring on the clock signal.

My next effort will be to hack in an oscillator.
Bill
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

Using an Oscillator didn't help. Still the same behavior - won't run a program, won't execute PRINT with an argument.

However, it did clean up the clock signal. You can see from the following scope shot that the ring is no worse than /QW (red) or the data bus (green).
W-OSC-RAMW.jpg
I'm fairly sure most of the remaining ring is in the scope grounds as all the fast signals have about the same amount. The RAM /CE signal (blue) has a much lower slew rate which I believe will reduce (but obviously not eliminate) the amount of ringing.


EDIT:

Okay, I went ahead and scrounged up one of those little spring pig-tail grounds for my best scope lead and used that on the clock. You can see in the following scope shot the clock is nice and clean.
W-OSC-RAMW2.jpg
Bill
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

BigDumbDinosaur wrote:
... plus I'm wondering why you choose to generate Ø2 the way you did.
To reduce chip count and real estate consumption. However, I have determined that, if I can get the other things working, I can used a smaller GAL and (barely) fit a 1/2 can oscillator. I am trying hard to keep all the components through-hole. It is supposed to be an easy, minimal, do-it-yourself project that still has some useful expansion capabilities. Think plug on boards - ala Arduino.

EDIT: Here are a picture of an early prototype and a couple of mock-ups of the application concept.
IMGP9712.JPG
IMGP9714.JPG
IMGP9716.JPG
Last edited by BillO on Fri Jun 15, 2018 2:52 pm, edited 1 time in total.
Bill
User avatar
GaBuZoMeu
Posts: 660
Joined: 01 Mar 2017
Location: North-Germany

Re: Another semi-fail - again with the W65C02

Post by GaBuZoMeu »

If you use a WDC CPU and "forget" to set J5 accordingly - does that change anything at moderate speed (4MHz) ?
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

GaBuZoMeu wrote:
If you use a WDC CPU and "forget" to set J5 accordingly - does that change anything at moderate speed (4MHz) ?
Yes, the behavior is more pronounced. It won't even make it through the memory check.

For NMOS or Rockwell chips the position of J5 has no appreciable effect.
Bill
User avatar
GaBuZoMeu
Posts: 660
Joined: 01 Mar 2017
Location: North-Germany

Re: Another semi-fail - again with the W65C02

Post by GaBuZoMeu »

Well, I scanned the WDC65C02 (an old one, 2004) data sheet for "compatible" and "replacement" - no finds. Perhaps they knew better ;)

But if using PHI2out make things worse then using an oscillator can for PHI2 for the GAL and delay that PHI2_GAL by one or two buffers and fed it into the µP should make things better - I hope. The GAL signals then are slightly earlier than the "nominal" (=PHI2_µP qualified) signals.
User avatar
floobydust
Posts: 1394
Joined: 05 Mar 2013

Re: Another semi-fail - again with the W65C02

Post by floobydust »

Interesting thread... in my last two 65C02 boards, I used WDC for the CPU. In the first board setup, I used the Ph2 clock output from the CPU to drive the clock in on 65xx support chips and also some NAND gates to qualify memory write for RAM and EEPROM. On my most recent board (which uses an Atmel AT22V10CQZ) I used the same (half-size can) clock oscillator to drive the CPU and the CLK in line on the CPLD (single glue logic).

One other difference with my latest board (CPLD glue chip) is I have it heavily bypassed. The main differences between our chip count is I use a NXP UART, a TI TL7705B reset chip and a Maxim DS1813 for a NMI trigger... plus the WDC CPU, an Alliance 32KB static RAM and an Atmel 32KB EEPROM (28C256). I have 12- 0.1uF bypass caps and 3- 68uF decoupling caps. The AT22V10CQSZ has a 0.1uF and a 68uF cap right at the power pin. I recall reading an application note sometime ago about the CPLD requiring more dedicated bypassing to keep the noise down. In my case, the CPLD consumes over 80% of the current drawn by the board running at 6MHz.

You might want to try tacking some additional bypass caps directly to the chip pins to see if it helps.... just a thought.
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

GaBuZoMeu wrote:
Well, I scanned the WDC65C02 (an old one, 2004) data sheet for "compatible" and "replacement" - no finds. Perhaps they knew better ;)

But if using PHI2out make things worse then using an oscillator can for PHI2 for the GAL and delay that PHI2_GAL by one or two buffers and fed it into the µP should make things better - I hope. The GAL signals then are slightly earlier than the "nominal" (=PHI2_µP qualified) signals.
I think I know what you mean. /QW will be a tad earlier - and I was thinking, looking at the signals that /QW seemed borderline. The thing is, have other people had this problem too? I'd like to see the schematics for the system clocks of some working projects. However, I'll not get a chance to try this until Sunday. I'm a trombonist these days and I have dance tonight and a big rehearsal (8 hours) tomorrow for a special concert.
Last edited by BillO on Fri Jun 15, 2018 5:04 pm, edited 1 time in total.
Bill
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

floobydust wrote:
Interesting thread... in my last two 65C02 boards, I used WDC for the CPU. In the first board setup, I used the Ph2 clock output from the CPU to drive the clock in on 65xx support chips and also some NAND gates to qualify memory write for RAM and EEPROM. On my most recent board (which uses an Atmel AT22V10CQZ) I used the same (half-size can) clock oscillator to drive the CPU and the CLK in line on the CPLD (single glue logic).

One other difference with my latest board (CPLD glue chip) is I have it heavily bypassed. The main differences between our chip count is I use a NXP UART, a TI TL7705B reset chip and a Maxim DS1813 for a NMI trigger... plus the WDC CPU, an Alliance 32KB static RAM and an Atmel 32KB EEPROM (28C256). I have 12- 0.1uF bypass caps and 3- 68uF decoupling caps. The AT22V10CQSZ has a 0.1uF and a 68uF cap right at the power pin. I recall reading an application note sometime ago about the CPLD requiring more dedicated bypassing to keep the noise down. In my case, the CPLD consumes over 80% of the current drawn by the board running at 6MHz.

You might want to try tacking some additional bypass caps directly to the chip pins to see if it helps.... just a thought.
I'm fairly sure there is enough bypassing, but I can have a look for any ground bounce. It would not be hard to add more if I find nay bad bounce - but not until Sunday.
Bill
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Another semi-fail - again with the W65C02

Post by BigDumbDinosaur »

BillO wrote:
I'd like to see the schematics for the system clocks of some working projects.
Two-Phase Ø2 Generator
Two-Phase Ø2 Generator
Above is what is in my POC units. I don't actually use the PHI1 output—I illustrate it for anyone who might need it.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Post Reply