Hi all!

I want to test some W65C816S and W65C02S I purchased -- PLCC version, so no breadboarding possible Thus I soldered a PLCC socket with a few extra components, little more than:

-A socketed oscillator can, presently running at 2 MHz.
-The mandatory '573 and '245 as per the 65C816 datasheet recommendation.
-NOP opcode ($EA) hardwired into the databus, via the '245.

...in order to get the CPU on free-run and check with the 'scope the address lines counting at diminishing frequencies. I'm aware that, generally speaking, both WDC microprocessors are not pin-compatible, but I was wondering if for this limited, specific application they would do. According to the datasheet naming and PLCC pin numbering, the differences are:

Pin 8: VPA ('816) or SYNC ('02), both outputs -- not used and unconnected on my circuit

Pin 42: MX output ('816) or SOB input ('02) -- not connected on my circuit. Not sure if this has a pull-up like RDY, but in case the 65C02 get this low (ie, active) it will just set the overflow bit, without any effect on the NOP-driven run, am I wrong?

Pin 43: VDA ('816) or PHI2O ('02) outputs -- not used and unconnected on my circuit

Pin 4: ABORTB input ('816) or PHI1O output ('02) -- this has to be kept high on the 65C816 for normal operation, but in order not to interfere with the corresponding 65C02 output, I connected it thru a 22K pull-up.

So, I think a W65C02S should work on my circuit, originally intended for testing the '816. But while my five units of PLCC 65C816 tested fine on it, tried a 65C02 but didn't work... nor did a second unit At first glance I though about some lost connection on the circuit (I have to admit it is lousy ) but put back another 65C816 and it worked fine as always.

I think it's unlikely that both '02s are defective -- don't want to try the remaining three, just in case my circuit is killing them! But I don't know how could it be possible...

Any ideas would be greatly appreciated. Thanks a lot in advance,

_________________
---
Carlos J. Santisteban
IES Turaniana
Roquetas de Mar, Almeria (Spain)

As described, your circuit appears to have a few problems:

• The '254 and and '573 are not required with the '816 unless you are intending to use 24 bit addressing. From the 'C02's point of view these bus chips are probably getting in the way and should be taken out of the circuit. Try connecting the MPU's data bus directly to a hardwired NOP generator.

• You didn't say how you are applying your Ø2 clock to either MPU. On the WDC version of the 'C02, Ø2 should be applied to pin 41, which is the same as on the '816.

• The BE (bus enable) signal, pin 40, must be pulled up to Vcc with a 3.3K resistor, as must IRQB, NMIB and RDY. Unlike the '816, the 'C02 does not have an internal pullup, requiring that an external one be provided. Unless you've done this, RDY is floating on the 'C02 and is most likely appearing to be low to the MPU core.

Try making these changes and see if it gets your 'C02s going.

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

Well... it was the RDY line! Despite WDC's datasheet clearly stating that the W65C02S does have an active pullup on it, it seems that it really doesn't Once I put +5 V there, all my '02s checked out great... Many thanks for your directions!

Problem solved, but here are some additional results for the sake of completeness:

Yes, but I was afraid of some bus contention between the '816 is putting the bank address on the data bus and the hardwired NOP... anyway, at 2 MHz the 74HC245 shouldn't get much in the way, so the first experiment was to remove the (certainly meaningless for this purpose) '573 -- to no avail, although the '816s were still doing great without it.

Sorry! I was centered on the differences and forgot to tell about the common pin connections... the output of my oscillator can goes directly (≈1 inch of wire) to the MPU's pin 41, as expected. There's another wire coming from the can's output to an inverter for the 573/245 pair. But the received clock signal seems good in my rather limited oscilloscope.

Mixed feelings here... I had BE directly to +5 V, and had a 5-pin, 4-resistor pack (22k) as pull-ups for the lines: ABORTB/PHI1O, IRQB, NMIB and RESET -- the latter with a 100n capacitor to ground. But none on RDY...

Indeed it was -- the 'scope said once I probed it. Now I've learned that... and to never trust a datasheet

WDC makes great chips but... so much for their datasheets!

Thanks again!

_________________
---
Carlos J. Santisteban
IES Turaniana
Roquetas de Mar, Almeria (Spain)

An excerpt from the W65C02S data sheet dated October 19, 2010:

3.10 Ready (RDY)
A low input logic level on the Ready (RDY) will halt the microprocessor in its current state...The RDY pin no longer has an active pull up. It is suggested that a pull up resistor be used on this pin when not being used. The RDY pin can still be wire ORed.

You must have been looking at an older data sheet, as at one time, RDY did have an internal pullup. WDC removed it for unknown reasons, but most likely to reduce the MPU's power consumption. The 65C816 still has it, though. Go figure!

By the way, don't connect RDY directly to Vcc. Always use a resistor. The reason is that when the MPU executes the WAI instruction it pulls RDY low to signal external hardware that it is waiting for a hardware interrupt. Needless to say, the MPU will have a short life if it tries to sink your power supply through the RDY pin.


22K pull-ups are much too high, especially on IRQB. Always use the lowest value that is consistent with the sinking strength of the weakest device in the circuit. 3.3K is the most often used value when Vcc = 5 volts.

The rationale is that after one of these signals is pulled low and then released, distributed capacitance in the circuit has to be charged through the pull-up resistor, which, of course, takes time. An unnecessarily high pull-up value causes the resulting RC time-constant to be too long, causing unpredictable results.

In the case of IRQB, a long time-constant can result in a spurious interrupt because too much time elapses from when the interrupt service routine (ISR) clears the interrupt source to when the MPU actually sees the low-to-high transition. If IRQB is below about Vcc x 0.7 volts when the ISR has finished, the MPU will think it is still being interrupted and the ISR will be executed again, only to discover that none of the expected interrupt sources are active. If high speed, interrupt-driven asynchronous data processing is involved, errors may occur from spurious interrupts or the MPU simply won't keep up with the interrupt rate because the circuit can't handle it.


When you go to build a working computer please take a look at the Maxim DS1813 reset generator. I have one in my POC unit and it works like a charm. What it does is hold RESETB low for about 250 milliseconds after power is applied and then releases it. While you can achieve something similar with a simple RC circuit, the DS1813 has the advantage of being voltage level sensitive. Hence the 250 msec time delay doesn't start until Vcc reaches about 80 percent of the nominal 5 volt level. Also, if you ground RESETB the DS1813 will maintain the ground for 250 msec and then release it, thus debouncing your reset push button (of which you will get plenty of use as you develop your initial firmware). I also have a DS1813 connected to NMIB to debounce it. It works like a charm.


There has been ongoing discussion around here about errors and omissions in WDC data sheets. Several of us have submitted corrections to WDC that were later integrated into updates. The current set of data sheets is maintained at WDC's website. I keep local copies here on my server and there are copies right here.

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

When you set about to designing an '816 powered computer you must qualify the address bus with VDA and VPA. During the intermediate steps of some instructions the '816 generates undefined address bus states, which can confuse some hardware. In summary, the address bus cannot be considered valid unless VDA | VPA is true (| meaning logical OR). In the current version of my POC unit, I use (of course) an OR gate to generate a VADR (valid address) signal to qualify the address bus for RAM and I/O accesses.

A little more explanation about VDA and VPA may be useful. VDA means "valid data address" and VPA means "valid program address." When VDA alone is asserted (high) it means the MPU has placed the address of a data location on A0-A15. For example, if the instruction is LDA $1234 and VDA is asserted and VPA is not asserted, it means the address bus contains $1234. If VPA alone is asserted, then it means the instruction's address, that is, the address of the LDA opcode, is on A0-A15.

If both are asserted, the '816 is in the process of fetching the opcode itself, which information may be used to implement a single-step feature. In this state, the '816 is emulating the behavior of the 'C02 when the latter's SYNC signal is high.

Ignoring VDA and VPA was the only design mistake I made in my first generation POC unit. It came back to bite me.

Another caveat is to qualify all write operations with the Ø2 clock. In the 'C02, D0-D7 are invalid when Ø2 is low. In the '816, D0-D7 will have the A16-A23 address component when Ø2 is low and VDA | VPA is true. You will get optimum performance with either MPU if address setup occurs as soon as the address bus is stable and write operations are deferred until Ø2 goes high, even though RWB goes low about halfway through Ø2 low on the final instruction cycle.

Qualifying writes with Ø2 is especially important with the '816 because, even if not used, the MPU always places A16-A23 on D0-D7 during Ø2 low of the final stage of an instruction that performs memory or I/O access. There's no telling what might happen if writing is enabled on a device and the data abruptly changes in mid-stream, so to speak. Reads should also be qualified with Ø2 to avoid bus contention during Ø2 low when the '816 is emitting the A16-A23 address component. In the WDC data bus reference circuit, the 74x245 takes care of that requirement. If you aren't using the bus drivers (which aren't necessary for a basic circuit), you should wire all chip output-enable pins to an /RD line that is low only when both RWB and Ø2 are high.

Something that I have seen in some circuits is the use of Ø2 to qualify chip selects. My opinion is doing so is bad practice, as it needlessly reduces the maximum speed at which the circuit can run. On both the 'C02 and '816, the address bus becomes valid approximately midway through Ø2 low. If chip selects do not occur until Ø2 goes high, part of the valid address bus time is lost and as the clock speed is increased, eventually a point is reached where chip setup timings are violated, even though the clock rate is well within the MPU's specs. As both MPUs can be run at up to 20 MHz in a properly designed circuit, the delay of chip select until Ø2 is high becomes a significant source of timing errors—Ø2 high is only 25 nanoseconds at 20 Mhz. Even at 10 Mhz, with its 100 ns bus cycle, problems will develop with chips in which 50 ns of setup time is inadequate. You should note that the 65C22's design requires that chip select be valid before the rise of Ø2. Obviously, qualifying chip selects with Ø2 violates that requirement.

BTW, I suggest the use of 74ABT and/or 74AC logic instead of the older and slower 74HC.

There are lots of other hardware design tips around here, so you should be able to find out everything that you need. Look especially at Garth Wilson's writings on the subject.

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

Remind me, BDD, in what way did your POC suffer from not using VPA and VDA? You've brought this point up before, but it seems over-cautious to me: in principle these signals should be superfluous in straightforward designs.
Cheers
Ed

I thought they were superfluous as well, until I tried to write to the DUART's registers with STA <ADDR>,X code during the configuration stage of system reset, which was failing. It was due to the MPU placing a false address on the bus during the fourth cycle of the instruction, and then changing it to the right address in the fifth and final cycle. The abrupt change from one address to another was causing improper internal chip selects to be generated, resulting in the write operation touching the wrong register. Once I patched the board to qualify chip selects with VDA and VPA the trouble vanished and I had stable operation at 12.5 MHz.

What lead me to this diagnosis was an obscure caveat in the DUART's data sheet where one of the registers, which happened to be the target of the STA <ADDR>,X instruction, required that at least three X-clocks elapse between successive accesses (read or write), where X-clock is the 3.6864 MHz baud rate generator frequency. At any speed higher than one MHz, the '816 would violate that requirement without proper address bus qualification, because the address was changed between cycle number four and cycle number five, and the application of a chip select during that period constituted a double register access. Subsequently, when I was developing the SCSI host adapter I learned that the 53C94 controller could also be confused by false address bus states.

The '816 data sheet identifies a number of instructions where false addresses will be generated during intermediate instruction cycles. So it really isn't a case of being over-cautious. Good design practice with the '816 is to qualify chip selects with VDA and VPA to avoid any undocumented side-effects from false address bus states. The circuitry to do so is not complicated (basically an OR gate).

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

Ah yes, thanks, I remember the discussion now.
viewtopic.php?p=9838#p9838

My concern now is as it was then: that somehow the situation and choices should be explained to the newcomer or beginner without it being 'scary' - really you had a special case where the invalid accesses from indexed addressing happened to be important. Your experience is interesting, and it's good that you found a fix, but I don't find it compelling that these two signals should always be brought into play. (The pins don't exist on the '02 and one can get along fine without them.)

I respect that your opinion on this is different!

Cheers
Ed

BigEd wrote:

Ah yes, thanks, I remember the discussion now.
[url=http://forum.6502.org/viewtopic.php?p=9838#p9838[/url]

My concern now is as it was then: that somehow the situation and choices should be explained to the newcomer or beginner without it being 'scary' - really you had a special case where the invalid accesses from indexed addressing happened to be important. Your experience is interesting, and it's good that you found a fix, but I don't find it compelling that these two signals should always be brought into play.

There's nothing scary about anything if properly understood. In my opinion, the fallacy in glossing over VDA and VPA, due to a fear that a beginner may shy away from use of the '816, is that it does the would-be builder a disservice. Any discussion we have about hardware implementation should attempt to cover the bases and build on our experiences so someone new to the hobby doesn't trip over what is thought to be a part defect, when in fact it is a failure to correctly use the part.

The '816's data sheet admonishes the user to qualify addresses with VDA and VPA. From page 52:

7.5 VDA and VPA Valid Memory Address Output Signals
When VDA or VPA are high and during all write cycles, the Address Bus is always valid. VDA and VPA
should be used to qualify all memory cycles. Note that when VDA and VPA are both low, invalid addresses
may be generated. The Page and Bank addresses could also be invalid. This will be due to low byte
addition only. The cycle when only low byte addition occurs is an optional cycle for instructions which read
memory when the Index Register consists of 8 bits. This optional cycle becomes a standard cycle for the
Store instruction, all instructions using the 16-bit Index Register mode, and the Read-Modify-Write
instruction when using 8- or 16-bit Index Register modes.

Not saying anything about VDA and VPA to someone who is trying to use the '816 for the first time, or telling that bloke that those signals are not important, is, in effect, telling them to not pay attention to caveats within the data sheets. I believe that is the wrong message to send to someone who is trying to learn.

Quote:

(The pins don't exist on the '02 and one can get along fine without them.)

You're comparing apples (no pun intended) and oranges.

The NMOS 6502 has some hinky behavior with certain instructions, especially absolute indexed ones, in which bogus addresses are briefly generated if indexing causes a page boundary crossing—usually not a problem with RAM or ROM. Also, the R-M-W instructions perform two writes on the same location, which can cause unpredictable behavior if applied to an I/O device. Programmer beware!

The 65C02, unlike the '816, never generates false address bus states and also fixes the NMOS R-M-W double write behavior. There is no need to qualify the address bus with this MPU and therefore no need for signals like VDA and VPA.

Quote:

I respect that your opinion on this is different!

Thanks! I'm merely trying to make my experience available to others so the next individual who scratch-builds a '816 gadget doesn't have to reinvent the debugging wheel. It's very discouraging when power is applied and nothing good happens because a seemingly obscure part feature was ignored in the design.

——————————————————————————————————————————
Edit: Fixed a grammatical boo-boo that I spotted while replying to BigEd.

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

Thanks - these two points do indeed change the picture. Although in a slightly unhappy way, because they support what I still feel to be an over-complex solution! In our different ways we are both trying to help the mythical beginner - I'm trying to leave more of the gory details to footnotes and appendices and you'd prefer to bring it to the front of the book.

In summary, my preferred view (of leaving VPA and VDA out of the picture) makes the '816 more like a drop-in for the NMOS '02, which does have quirks. And it's possible that those quirks could cause some head-scratching and a visit to this forum.

Cheers
Ed

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

Wow! After a few hard days at work, this thread has turned into a very interesting one! Thanks a lot!

Well, my datasheet was from August 4, 2008... that explains everything: design and specifications subject to change without notice Thanks for the link to newer ones!

Some more thoughts for this brainstorming, in no particular order:

•VPA and VDA are definitely interesting signals -- just not needed for a simple MPU testing device. My ultimate goal is to connect a very synchronous 65C816 to an asynchronous VME-like bus, thus the aforementioned lines are great candidates for getting the required Address Strobe. There was some discussion here about this, but unfortunately the links are dead I think I got the way to do it, but would love to compare strategies anyway.

•Qualifying writes via ø2 is absolutely essential, of course. But now I find that qualifying reads is as important -- it will avoid several contention causes (see below) and anyway it's needed for interfacing with Intel-style peripheral chips (16C550, HD6445...). Tying such ¬RD signal to all ¬OE's out there is a brilliant idea. I think that would make unnecessary the '245 on the C816 databus (on the low phase of ø2 all the remaining outputs will be disabled, no problem with putting the bank address on the bus then) further reducing propagation delays etc.

•When more than one address bit is to change, because of slight timing differences it may go thru several anomalous, unrelated addresses temporarily -- Gray code wasn't developed just for the sake of it! In my previous designs (never actually built...) I kept the decoders permanently enabled in order to get the correct address as soon as possible. As long as all databus outputs (and inputs!) are disabled (should be so until ø2 goes high) I find no problem even if some devices get momentarily selected, but no operation enabled. Or am I missing something?

•Also got interest on connecting a 65C02 to my asynchronous bus... but this one has no VDA/VPA signals A quick and dirty way to obtain the ¬AS would be from ø2... but as already commented, such approach wastes some precious access time (between the address properly formed after tADS and the rising edge of ø2) -- probably not an issue for the slowest clock speeds (2? 4 MHz?) but a real problem when trying to go fast... perhaps a fixed delay from the falling edge of ø2 might generate this signal OK, but that would make difficult to switch speeds and/or MPUs

•My current MPU-tester device (let's call it Tommy) had RDY directly tied to Vcc because of convenience, and it wasn't goint to execute a WAI -- I find little to no use for it, especially since the active pull-up has been deleted on the '02. On my full system it would connect to the wait states generating circuitry anyway.

•Ditto for the rather weak pull-ups -- no changes are to be expected on those lines, and the 22K pack-of-four was what I had at hand I am aware (thanks to this site) of the issues with a weak pull-up on ¬IRQ because of the sluggish rise time.

•That DS1813 looks convenient. My (final) system will use automatically generated NMIs, besides those invoked by the user pushing the button... will the DS1813 debounce the button without interfering the other NMI sources? I know, a single gate is all that is needed for that, but they're sometimes so inconvenient...

•74AC, ABT (or even faster?) are definitely the way to go when the MHz rise... but for my 2 MHz tester, HC is enough. I am however trying to make the real thing as low-power as possible, so I prefer staying with some sort of CMOS technology. I've read about GALs and the like, but I'm amazed by the static Icc, even those in CMOS I understand that these are convenient but far from optimized solutions, and with tons of unused gates switching uselessly, dynamic power consumption is going to be high. But, unless internal pull-ups/pull-downs are used, CMOS gates should draw almost no power when staying on a fixed level... I don't understand what happens with these.

•Speaking of power consumption... these oscillator cans are trouble-free, but they are power hungry! No one ever made a less-thirsty version of these? Don't want them drawing more power than the rest of the computer together!

Cheers,

_________________
---
Carlos J. Santisteban
IES Turaniana
Roquetas de Mar, Almeria (Spain)

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

Not to be misinterpreted though, they have a Φ2 input and will never put their data out on the bus before Φ2 rises. They will of course output it in a full read cycle, even if that cycle is not needed by the processor, which is the kind of thing that caused some very difficult-to-troubleshoot problems in the early days of the NMOS 6502 when an I/O IC's status register or timer would get read, changing the status (usually meaning clearing an interrupt) accidentally.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yer right on that. I was thinking of the olden days when most of the MOS Technology peripheral silicon didn't work worth a hoot (especially the 6551) and seemed to randomly toss bytes onto the data bus. One of my first hardware projects way back when was interfacing a Motorola 6850 UART to the 6502 bus. It was a bit of a headache, I recall, but it worked very well at speeds up to 38.4 Kbps. The only thing hinky about it was it (the 6850) doesn't have a reset input, so I simulated one with a totem pole arrangement triggered by /RESET. When /RESET went low, Vcc to the 6850 was cut off and that was its "reset." Genuine monkey engineering but it did work.

As usual, carefully read the data sheets and timing diagrams. It can be tedious at times but can save a lot of time that wasn't expended troubleshooting DOA or misbehaving hardware.

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