I just had a board made up that does not work as intended. Not sue where to start with this, but I sure would appreciate hearing from folks that have gotten W65C02S machines working.

Let me see if I can give you some starting information.

The board works fine with NMOS 6502s or with Rockwell 65C02s. No issue. I have one 6502B running at 5mHz and the R65C024Ps will run happily at 4.7 mHz. However, if I put a W65C02S in it, it will not run properly at any speed (even tried 100kHz). I put a jumper block on Pin-1 to either connect it to ground for older chips or let it float for the WDC chip and PIN 36 (BE) is tied high. RDY, NMI, IRQ and SO are held high with 10k resistors.

The board is a 4 layer board and .1uF and .01uF bypass capacitors are used for each chip. Care was taken to ensure the integrity of the ground and Vcc planes as well as keeping all traces as short as possible. Traces on the CPU side of the buffers are kept under 8cm and traces on the I/O side are under 7cm. I have tried it with LS, HCT and ACT support logic with no change in results.

The same W65C02S chips will run just fine and dandy in my old OSI superboard (which has bus traces measuring over 40cm, bypass capacitors once in a while and no ground planes) or in my Apple IIE.

Is there some obvious thing I have overlooked? Is there a know incompatibility with EhBASIC an the WDC chip? I'm confused.

My schematic is attached. If you have any questions for me I'll be happy to answer them. I'd just like to figure out why I can't get these WDC chips working.

_________________
Bill

At a first glance I couldn't find something wrong with your schematic. And because the NMOS and the Rockwell parts are running finde, perhaps it is something on the soft side.

Can you specify how "not run properly" looks? No action at all? Or frequent restarts? Is there a monitor program and does it respond?

I'm not saying that this is a factor in why the board is DOA, but 10k is too high for those inputs. You may be getting enough noise there to trigger spurious conditions. 3.3k is the usual recommended value for those pullups. Ditto for reset's pullup.


I'm not aware of any incompatibility between the 65C02 and EhBASIC.

This is just a WAG on my part, but your DOA condition may be due to clocking matters. You should note that WDC does not recommend the use of the PHI1O and PHI2O outputs to clock other devices in the system. Excerpted from page 10 of the data sheet:

3.8 Phase 2 In (PHI2), Phase 2 Out (PHI2O) and Phase 1 Out (PHI1O)

Phase 2 In (PHI2) is the system clock input to the microprocessor internal clock...The Phase 2 Out (PHI2O) signal is generated from PHI2. Phase 1 Out (PHI1O) is the inverted PHI2 signal. An external oscillator is recommended for driving PHI2 and used for the main system clock. All production test timing is based on PHI2. PHI2O and PHI1O were used in older systems for system timing and internal oscillators when an external crystal was used.

Furthermore, on page 26 in the data sheet (below the timing diagram), WDC states that the lag from PHI2 to PHI2O/PHI1O is not tested on production parts and is not specified. The bottom line is using PHI2O/PHI1O to clock other hardware in your system will introduce some unknown amount of phase shift relative to the 65C02's internal clock, which is driven from PHI2.

Not knowing what the logic is in the GAL, the following may also be a WAG. I don't see a clock input to the GAL, but I do see RWB driving one of its inputs and a /WE assigned to one of its outputs, that apparently ending up at an SRAM (?). The /WE should be gated by Ø2 so it is only asserted when Ø2 is high. This is because during part of Ø2 low the data bus will be in an indeterminate state and depending on the characteristics of the SRAM, it may not properly behave while the data bus is settling.

Regarding the use of the '245 bus transceivers, data and address connections on devices such as the 65C61, SRAM and ROM should be attached directly to the 65C02's data and address buses. The 65C02 has more than enough drive to handle the load, given reasonably good construction methods (a four-layer PCB should work fine—my POC units are four-layer and will run at 12.5 MHz without any stability issues). Also, 65xx I/O silicon must have chip selects and RWB valid before the rise of Ø2, else the device will not function.

In a first step to troubleshoot this unit, I would suggest inserting a NOP generator in place of the ROM, power up and then observe for system activity with your logic probe or scope. A good point to watch is SYNC, which toggles as each opcode is fetched. If the 'C02 will execute NOPs then you will need to examine your general design for logic and timing accuracy.

Can you please post the logic code for the GAL? There could be something in there that is being a problem as well.

Lastly, in an all-CMOS design there is no reason to employ 74ACT/74HCT logic. For most devices, the 74*CT version will be somewhat slower and more vulnerable to noise than the 74*C equivalent. That said, 74AC should be used with care in wirewrapped systems or systems built on perf board, due to the very fast output transition times.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, BDD might be right being suspicious about the clock. Perhaps you can bridge p37 and p39 (bending p39 aside) and check whether something changes?

I had all sorts of weird issues with my W65C02 system until I switched everything to use phi2 as a clock source. At the very least you should do the same

So I should drive the system Phi-2 line directly from the oscillator? I'll try it.

What I mean by not working correctly is that once I do the system initialization (which all goes well), then do a cold start on EhBASIC it goes as far as asking for memory size. Hitting return then causes the W65C02S to execute the memory check then it will enter a loop through the reset vector for a short while, then it just stops - dead. No activity (clocks are still there, but no activity on any other lines).

So these are the things I will try and in this order:

1) Use the oscillator output to drive Phi-2

2) Change the 10K resistors to 3.3K

Notes:
I tried other logic families without improvement. I use ACT logic to limit propagation delay. The short buses and the 4 layer construction should make the use of fast logic viable.

Phi2O does go to the GAL (code attached) for the specific purpose of qualifying the RAM write signal.

One of the 245s is used strictly as a buffer an is locked in one direction and always enabled. I use a 245 instead of a 244 for routing ease.

The data bus 245 should only be enabled when reading or writing to the I/O bus.

Timing on the 65C51 is good and this does not seem to be causing the issue as it is not even being access when things fly off the rails.

It is intended to be a mixed logic environment, at least on the I/O bus, hence the reason for 'T' logic.

The only ACT chip the processor 'sees' is the data bus 245, and only for reads from I/O.

The buffers are being used to keep traces and nets sort and to isolate the processor and memory from the junk that might find it's way onto the I/O bus.


Thank you everyone, your input is highly valued. I will make those 2 changes and see how things work, but wont be able to do it for a few days. I will let y'all know how things go.

_________________
Bill

Coming in to this thread late and only at the last few posts in it, but have you checked that you're not encountering one of the two opcodes on the W65C02S that I expect would result in the behavior you're describing: WAI, or STP. It sure does sound as if the processor ends up seeing one of these two instructions. I suppose this could happen due to noise, but it could also occur if the ROM is not correctly programmed, or if one of the transceivers is turned off early relative to the active edge of Phi2. Since you have designed for minimum delay, one or more of your transceivers or even the decode logic may be too fast for the memory, and the system is not providing the correct hold time on the data during instruction reads.

These two opcodes, 0xCB and 0xDB, are composed mostly of ones, and are awfully similar to the unprogrammed state of an EPROM. I used to test my discrete 8051 designs with unprogrammed EPROMs because the instruction ADD A,R7 would simply cycle through the addresses.

_________________
Michael A.

(Oops, I see Michael posted about this already.)
Ordinarily $CB or $DB would never get executed. For that to happen there'd have to be some sort of anomaly or problem beforehand, and I can't guess what that might be. But a Rockwell chip will recover ($CB and $DB are one-cycle NOP's), whereas a WDC chip will freeze just as you describe.

It'd be helpful if you could probe the CPU address lines after the freeze has occurred. Is it the same address every time? Then see if it's possible a $CB or $DB resides at the preceding address.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I wonder, does WAI/STP freeze the clock output of a W65C02?

For not too much outlay, you could capture and analyse the bus activity.
See viewtopic.php?f=4&t=4963

The WAI (WAIt for interrupt) instruction halts the WDC 65C02 by stopping the internal clock. The 'C02 restarts when any hardware interrupt occurs.

The STP (SToP) instruction is similar to WAI, except the 'C02 will only respond to a low on the reset input.

In both cases, the PHI1O/PHI2O outputs will continue to generate a clock signal while the 'C02 has halted.

The same behavior applies to the 65C816.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just to note, in some experiments with Dave aka hoglet, we found a case where a CMOS 6502 in an Acorn BBC Micro would almost work, and the failure was very specific:

I'm pretty sure we decided this was some kind of internal timing problem, and fairly sure that tweaking or slugging the clock fixed it. I'll ping Dave, as his recollection will be better. (I think we decided that the operand coming from RAM was arriving just too late relative to the clock, so it was an external timing violation with a very specific internal effect.)

Looking at RDY might also be helpful, as RDY will be pulled low by the 'C02 if accidentally executes a WAIt—assuming something isn't trying to drive RDY high.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ahh fair enough. In either case a telltale sign will be no activity on the SYNC pin

Yes, this was when changing the processor in a BBC Model B from an NMOS SY6502A to a CMOS R65C02P2 (both genuine!)

There was a thread over on Stardot about this:
http://www.stardot.org.uk/forums/viewto ... =3&t=14465

This post is showing the likely cause:
http://www.stardot.org.uk/forums/viewto ... 46#p193146

In summary, the RAM read timing on the BBC Micro is very marginal, and changing to a R65C02 makes this worse by about 10ns. This is seen by the 6502 as a hold time violation, and it most affects the longest path, which is through the ALU and into the carry flag. What we were observing in the Dormann tests was the carry flag failing to update correctly.

This related thread was also quite interesting. On an Acorn Atom the 60Hz VSYNC signal is asynchronous to the 6502 clock. It's possible to write a program that will fail after maybe an hour due to metastability propagating through the 8255 and on to the 6502.

http://www.stardot.org.uk/forums/viewto ... 9&p=200632

Dave