Hi guys

I'm thinking of moving away for the standard wdc w65c51 (mostly due to the xmit bug). Looking around, people seem to like the NXP SC26C92 and, looking at it, it seems to be a very versatile chip.

Are there any particular gotchas that anyone knows when using it with a wdc w65c02s?

The things I've picked up so far:
- Reset is active high, so RESB will need to be inverted
- There are separate Write and Read pins, with both being active low, so RWB needs to be invertered for read (RDN)
- INTRN is active low and open drain (so no change there)
- This is a CMOS only chip so any inputs interfacing TTL only needs a pull up (including the oscillator if one is used). Should be fine for most WDC devices apart from the N versions.

Here's my ciruit:



I've outputed the IP and OP pins to headers for the moment

I think the SC26C92 will be fine sending from TXDA and TXDB (CMOS to TTL) and I *think* the MAX232 is CMOS compatible so should be ok going back to RXDA and RXDB, but not 100% sure.

[edit] typo corrections

Very similar is the 28L92, which there is a specific tutorial on interfacing and driving, linked in the first post in this thread.

Thanks . I've downloaded the docs and am looking through them at the moment.

[edit] Just realised that the SC26C92 is no longer manufactured and as I only have one of them in my box o' bits I think I'll skip it. Instead, I'm looking at NXP SC16C2552B.

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

I also recommend going with the SC28L92, which will be on my next SBC as well.

Referring to your schematic, a couple things:
1- I would qualify the /RD and /WR lines withe the Phase 2 clock of the CPU.
2- You have the second serial port going through the level shifter to RTS and CTS. Are you redefining the connector or just an oversight?

As for getting the code written with the W65C02, take a read through this link, as an extra read (indexed addressing) results in the Mode register(s) not getting setup correctly:
viewtopic.php?f=2&t=4992

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

Like this, for example:

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

Thanks for the recommendation, guys. I'll have a good read of the SC28L92 datasheet, but given what you've said I strongly suspect I'll go for it.
With regards read & write signals: I'm using an ATF1502AS CPLD to do my decoding and have a /WR pin and /RD pin already as outputs so qualifying them with PHI2 is noty an issue (unless I run out of product terms - it's doing bank switching and IRQ handling as well).

Something else I've been mulling over (and only slightly related): Instead of driving PHI2 though a D type flip flop I can route the oscillator into one of the CPLD pins and out of another. This might give me a square wave, but without halving the clock, albeit at just over 4V. I'll qualify decoding, /WR, /RD, etc. from the internal feedback from the PHI2 output pin. I'll have to check what the ATF1504AS driving can support though...

If all you need is to sharpen the clock edges, use a Schmitt Trigger buffer or inverter. That won't do anything for duty cycle, though, whereas a clock divider would.

I've got very little real estate PCB-wise so trying to minimise ICs, but you make a good point about the duty cycle.

Sorry, flooby, I didn't address your second question. yes, it was on oversight. I've corrected the diagram accordingly.

So, here's my circuit design for the serial interface:



A couple of things I need to look into:

- How to use DACKN
- How to use IACKN
- Do I still need DTR connected to V+ on the MAX232

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

You don't.


You don't


Have you read the attached? It should answer your questions.

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

Got some ATF1504AS so will do. I'd also just realised that TTL output issue with them as well ( ) which surprised me a little. That also leads me to an issue with any signals running from the CPLD to the SC28L92 as we're going TTL output to CMOS input so it looks like I'm going to have to use pullups on those (I usually use 1k but should I use 470R as suggested on the X1 input if using TTL clock source? Seems a bit low, though...).

Speed-wise I'm planning to run at higher speeds so the flip flop is probably still a good idea. Good call on SOIC - I have no problems with soldering them as long as I have my magnifier (as with you, my eyesight is not so good these days, sad to say).

OK time for bed as it's 1am and my brain doesn't do well without its beauty sleep .

[Just spotted your other answers - many thanks! I have started making my way through them, but stopped when I realised I'd need to find a different chip. Anyhooo, off to bed.]

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

I had assumed that this port was for connection to a terminal, but now that I see this I'm not sure.

If the port is for connection to a terminal that will control the board (i.e., you are DCE), you shouldn't assert or deassert DTR; that's controlled by the other end to tell you whether it's "alive" or not. (You might just ignore this and assume that the other end is always there.) You should also probably assert CTS when you're ready to receive data. (And, again, maybe even when you're not, if you don't care about data loss.)

If the port is for connection to a modem or other thing you're controlling (i.e., you are DTE), you should assert DTR when you're wanting to use that device. You may or may not deassert it when you're not using the device. It's probably a good idea to assert RTS, too, when you want to send data.

Wikpedia has a decent summary of the control signals. Many systems might not care, but it can be annoying when you plug into one that does and it refuses to send data because you've not asserted an appropriate signal.

_________________
Curt J. Sampson - github.com/0cjs