65XX SBC general help and color display help needed

[GARTHWILSON]

That's where the MC145406 (same thing as the SN75C1406) triple line driver and receiver is nice if you already have ±12V for other things on the board, because you won't need any of those capacitors, since it doesn't need the charge pump.

[Michael]

Or... you could eliminate the transceiver IC and just have a header with the TTL level signals. Then simply plug in a USB-to-TTL Serial adapter or an RS232-to-TTL Serial adapter...

I still have a bag full of little circuit boards that fit inside a DB9 connector & hood for the RS232-to-TTL adapter shown below...

Cheerful regards, Mike

[GARTHWILSON]

A nice thing about the line drivers and receivers is having everything in the office compatible, that is, everything that is, or pretends to be, RS-232, plus the protection against static discharge, and the assurance that you're not going to harm anything if a line gets shorted or something like that.  The line drivers and receivers are kind of bullet-proof.  There were hand-held terminals years ago that connected by RS-232 (although usually from smaller plugs, like RJ-45, IIRC) and the hand-held unit ran off of power scavenged off the RS-232 lines so it didn't need its own batteries.  I definitely like the hardware handshaking of at least RTS & CTS.  I use DTR and DSR too, but I could go without those.

[backspace119]

Michael wrote:

backspace119 wrote:

In other news, I sourced new 1uf caps that are non polarized, but I'm probably going to switch back, because the footprints are actually larger:

If that's an RS232 level shifter IC then please note that the MAX202, ST202, or MAX232A transceivers are the same as a MAX232 transceiver but they can use 0.1-uf monolithic ceramic caps... You could install them under the IC in the open area of the machined pin IC socket...

MAX202.jpg

Thanks, I noticed that on the datasheet, but I didn't see the 232a on mouser, I'll look again though, because that could save some space.

In other news, I've been considering a monostable circuit for driving RDY low when talking to the EEPROM. My plan is to drop it for 150ns, which should be enough time for most EEPROMs (a couple take 200, but I'll stay away from those). I found this AHC series IC that seems to be right for the job. If my math is right, I'll need a 10pf cap, and a 3.3kOhm resistor to achieve 150ns. (I originally was planning >1000pf cap to keep it simple with a k factor of 1, but there's a note in there stating to be careful with large value caps, as they can damage the chip if the power supply cuts off too quickly, so instead I went for the smallest cap possible, and a k factor of 4.5)

[backspace119]

Michael wrote:

Or... you could eliminate the transceiver IC and just have a header with the TTL level signals. Then simply plug in a USB-to-TTL Serial adapter or an RS232-to-TTL Serial adapter...

I still have a bag full of little circuit boards that fit inside a DB9 connector & hood for the RS232-to-TTL adapter shown below...

Cheerful regards, Mike

I suppose the adapter is probably just as complex as what I have on the board...this may be something I need to consider, although I would like to have the port on the board, I feel like it's a more solid connection than what I could do with TTL (I'd probably use pins for something like that, because another port wouldn't save me much space over what I have going right now)

[Arlet]

I always use TTL level for my UARTs, using 3 pin Molex

[backspace119]

GARTHWILSON wrote:

That's where the MC145406 triple line driver and receiver is nice if you already have ±12V for other things on the board, because you won't need any of those capacitors, since it doesn't need the charge pump.

I may really need to look into getting -12v on the board. I saw your "non-standard power supplies" in the circuit potpourri, and I'm resistant to it only because iirc it uses a lot of discrete components (diodes I believe) that would take up quite a bit of space. Plus, having the max232 do it for me makes my job a bit easier on the design side, although as you say, the line drivers provide a layer of protection since they're mostly bullet proof.

Something I asked a while ago and just remembered it never got answered, I have the CTS and RTS connected for the USB-TTL header, through resistors like the Rx and Tx lines, my assumption was this would give me hardware handshaking on it, but I seem to remember that...Daryl's? page didn't use those lines for the usb-ttl header.

Can I use these lines? Will they provide hardware handshaking?

[backspace119]

Something I just realized is, if I use a monostable circuit for RDY generation, I can use a variable clock and be fine, since the clock won't be changing to access the EEPROM

does this sound feasible?

[Arlet]

RDY needs to be synchronized to clock, though

[backspace119]

Arlet wrote:

RDY needs to be synchronized to clock, though

It does? that's a bummer, I thought that it would just continue at the next PHI2 high transition

[Arlet]

Signals like RDY go inside the CPU and are then distributed to dozens of different flip-flops, all switching on the same clock.

If RDY is allowed to change at any time, then it could change at the same as the clock, and some flip-flops would then see it as '0' and others as '1' due to small variance in timing and thresholds.

[backspace119]

Arlet wrote:

Signals like RDY go inside the CPU and are then distributed to dozens of different flip-flops, all switching on the same clock.

If RDY is allowed to change at any time, then it could change at the same as the clock, and some flip-flops would then see it as '0' and others as '1' due to small variance in timing and thresholds.

ah, well I suppose I can still wait state on the variable clock though.

The name of the game here is saving wait states, because I don't think 2 is adequate at 20Mhz operation for 150ns eeprom, and I'd like to use only a single dual flipflop chip.

I may look at some NVRAM that has 70ns access time

[Arlet]

You could use asynchronous delay and then feed it through flip-flop to synchronize it.

[backspace119]

Arlet wrote:

You could use asynchronous delay and then feed it through flip-flop to synchronize it.

I was planning on using the circuit that's floating around here on the forum that has 2 flip flops for 2 wait states, it's asynchronous trigger but synchronous wait states to clock

[GARTHWILSON]

backspace119 wrote:

GARTHWILSON wrote:

That's where the MC145406 triple line driver and receiver is nice if you already have ±12V for other things on the board, because you won't need any of those capacitors, since it doesn't need the charge pump.

I may really need to look into getting -12v on the board. I saw your "non-standard power supplies" in the circuit potpourri, and I'm resistant to it only because iirc it uses a lot of discrete components (diodes I believe) that would take up quite a bit of space.

Yeah, it would kind of defeat the purpose. Without re-reading 24 pages of this topic, I was thinking you were using a power supply that already included a negative voltage.

Quote:

Something I asked a while ago and just remembered it never got answered, I have the CTS and RTS connected for the USB-TTL header, through resistors like the Rx and Tx lines, my assumption was this would give me hardware handshaking on it, but I seem to remember that...Daryl's? page didn't use those lines for the usb-ttl header.

Can I use these lines? Will they provide hardware handshaking?

I have one of the FTDI USB-to-RS232 adapters, and I have it set up to do the handshaking on CTS and RTS.  The FTDI unit I have is very clumsy softwarewise compared to using a real COM port on my dedicated DOS PC though.  I know BDD gave a link somewhere to a product that gives a set of RS-232 ports to modern PCs that came without them, and has the driver software.  It might have been startech.com or sealevel.com .  It probably needs a desktop PC that you can put cards into, rather than a laptop.