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:



Here is the CUPL Code:


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:


I/O Read using the WDC:


I/O Write for the Rockwell:


I/O Write for the WDC:



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:


For the WDC:



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:


For the WDC:



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:


For the WDC:



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


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.


EDIT - Schematic updated with more labels and notes.

_________________
Bill

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

Rockwell:


WDC:


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

_________________
Bill

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

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!

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

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


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.

_________________
Bill

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.

_________________
Bill

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

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.

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

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

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

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!