6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:15 am

All times are UTC




Post new topic Reply to topic  [ 50 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Thu Jun 14, 2018 5:21 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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:
Attachment:
Vixen.jpg
Vixen.jpg [ 453.28 KiB | Viewed 4383 times ]



Here is the CUPL Code:
Code:
/* *************** 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:
Attachment:
R-IOR.jpg
R-IOR.jpg [ 90.02 KiB | Viewed 4431 times ]


I/O Read using the WDC:
Attachment:
W-IOR.jpg
W-IOR.jpg [ 73.31 KiB | Viewed 4431 times ]


I/O Write for the Rockwell:
Attachment:
R-IOW.jpg
R-IOW.jpg [ 112.11 KiB | Viewed 4431 times ]


I/O Write for the WDC:
Attachment:
W-IOW.jpg
W-IOW.jpg [ 73.77 KiB | Viewed 4431 times ]



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:
Attachment:
R-ROMR.jpg
R-ROMR.jpg [ 70.39 KiB | Viewed 4431 times ]


For the WDC:
Attachment:
W-ROMR.jpg
W-ROMR.jpg [ 70.75 KiB | Viewed 4431 times ]



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:
Attachment:
R-RAMR.jpg
R-RAMR.jpg [ 50.34 KiB | Viewed 4431 times ]


For the WDC:
Attachment:
W-RAMR.jpg
W-RAMR.jpg [ 51.9 KiB | Viewed 4431 times ]



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:
Attachment:
R-RAMW.jpg
R-RAMW.jpg [ 92.61 KiB | Viewed 4431 times ]


For the WDC:
Attachment:
W-RAMW.jpg
W-RAMW.jpg [ 73.33 KiB | Viewed 4431 times ]



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
Attachment:
W-RAMW2.jpg
W-RAMW2.jpg [ 71.25 KiB | Viewed 4431 times ]


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.
Attachment:
W-CHIPS.jpg
W-CHIPS.jpg [ 78.84 KiB | Viewed 4431 times ]


EDIT - Schematic updated with more labels and notes.

_________________
Bill


Last edited by BillO on Fri Jun 15, 2018 12:01 am, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 14, 2018 5:43 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
Here are a couple more ROM Read timings: Yellow=Phi2 (system clock), Blue= ROM CE, Red=/OE, Green=DB

Rockwell:
Attachment:
R-ROMR.jpg
R-ROMR.jpg [ 56.45 KiB | Viewed 4430 times ]


WDC:
Attachment:
W-ROMR.jpg
W-ROMR.jpg [ 54.94 KiB | Viewed 4430 times ]


Here the data hold time seems much better with the WDC. Go figure...

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 14, 2018 6:30 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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.


Top
 Profile  
Reply with quote  
PostPosted: Thu Jun 14, 2018 11:17 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 6:36 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
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!


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 1:02 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 2:03 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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).
Attachment:
W-OSC-RAMW.jpg
W-OSC-RAMW.jpg [ 67.13 KiB | Viewed 4343 times ]


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.
Attachment:
W-OSC-RAMW2.jpg
W-OSC-RAMW2.jpg [ 64.61 KiB | Viewed 4339 times ]

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 2:27 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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.
Attachment:
IMGP9712.JPG
IMGP9712.JPG [ 69 KiB | Viewed 4334 times ]

Attachment:
IMGP9714.JPG
IMGP9714.JPG [ 85.84 KiB | Viewed 4334 times ]

Attachment:
IMGP9716.JPG
IMGP9716.JPG [ 121.09 KiB | Viewed 4334 times ]

_________________
Bill


Last edited by BillO on Fri Jun 15, 2018 2:52 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 2:47 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
If you use a WDC CPU and "forget" to set J5 accordingly - does that change anything at moderate speed (4MHz) ?


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 2:56 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 4:35 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 4:38 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
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.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 5:00 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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.

_________________
Bill


Last edited by BillO on Fri Jun 15, 2018 5:04 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 5:01 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Jun 15, 2018 5:26 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
BillO wrote:
I'd like to see the schematics for the system clocks of some working projects.

Attachment:
File comment: Two-Phase Ø2 Generator
clock_gen_2phase.GIF
clock_gen_2phase.GIF [ 16.88 KiB | Viewed 4314 times ]

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!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: