Could I use a 65c22 to drive an EIA232 interface?
Could I use a 65c22 to drive an EIA232 interface?
I've got a solderless breadboard kit computer with a w65c02s CPU and w65c22s for I/O (http://www.apatco.com/products.php). There isn't much room leftover on the board to add more chips and no way to transfer data on or off the system (other than manual entry).
So, I'm wondering if anyone has managed to use the w65c22s as a serial interface driver. I would settle for bit-banging at 300 bits per second across a serial port. If so can you point me to some hints or directions?
So, I'm wondering if anyone has managed to use the w65c22s as a serial interface driver. I would settle for bit-banging at 300 bits per second across a serial port. If so can you point me to some hints or directions?
- GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
#1. WDC's 6502's are too fast to be using in a solderless breadboard. The big loops of wire give you antennas and inductors all over the place; and the groundbounce, ringing, crosstalk between lines, etc. wreak havoc. There's a rather narrow range of conditions under which the thing will work at all with a solderless breadboard.
The kit manufacturer should know that well enough to not be subjecting their customers to the many inevitable related problems and frustrations that many if not most of them will have. Merely Slowing down the clock speed won't fix that, because the part's outputs will still have the fast rise and fall times that cause the problems. It's not WDC's fault at all, but rather a gross mis-match of technologies.
I would recommend wire-wrapping instead, with the parts close together so all the wires are as short as practical, especially with perfboard that has a ground plane, and then use the solderless breadboard for analog projects. I use both a lot (solderless breadboards and wire-wrap, not to mention making real multilayer PC boards), but each one has its place.
#2. If the LCD is truly RS-232 (timingwise anyway, even if you don't need the negative voltage, let alone higher voltages like +/-12V), you can still send it data with the 6522's shift register, as mentioned in my Tip of the day, #6 at viewtopic.php?t=342 . You'll probably need to use two consecutive frames to get enough bits (unless 6 bits plus start and stop bits is enough), and the left-over part of the second frame is simply left as extra stop bits, called "marking". This is much easier than actually bit-banging and trying to keep the timing requirements of RS-232. Remember however that the 6522's SR sends and receives bits forward, ie msb first, whereas RS-232's bit order is backward, ie, lsb first, so you'll have to turn them around.
You won't be able to receive RS-232 with the shift register however. That gets even more complicated if you really want to do it with the 6522. The best way will probably be to set up T1 as a free-running timer, preferably interrupting on every time-out, and then watch for the start bit and write to T1 at that time to synchronize it. The initial value you'll write to the T1 latches will be only 1/2 to 3/4 of the bit time for the first bit so you sample the input bit before the next change, then write the full bit time to it after that and leave it alone for the rest of the frame. Repeat for each frame.
Most LCDs have a parallel interface however, and that's easier to deal with through the 6522 since there aren't any strict timing requirements that way.
I have a graphics LCD here in front of me however that is synchronous serial, actually SPI. That's not RS-232 at all. Is there any chance that's what you have? SPI is much, much easier than RS-232 to handle with a 6522.
If you really do have RS-232 and want to interface to it through a 6522, bit-banging SPI to an SPI UART like the MAX3100 would be an easier way to get there. So the processor will go through the 6522 to get to the UART, which handles the actual RS-232 signals and timing.
The kit manufacturer should know that well enough to not be subjecting their customers to the many inevitable related problems and frustrations that many if not most of them will have. Merely Slowing down the clock speed won't fix that, because the part's outputs will still have the fast rise and fall times that cause the problems. It's not WDC's fault at all, but rather a gross mis-match of technologies.
I would recommend wire-wrapping instead, with the parts close together so all the wires are as short as practical, especially with perfboard that has a ground plane, and then use the solderless breadboard for analog projects. I use both a lot (solderless breadboards and wire-wrap, not to mention making real multilayer PC boards), but each one has its place.
#2. If the LCD is truly RS-232 (timingwise anyway, even if you don't need the negative voltage, let alone higher voltages like +/-12V), you can still send it data with the 6522's shift register, as mentioned in my Tip of the day, #6 at viewtopic.php?t=342 . You'll probably need to use two consecutive frames to get enough bits (unless 6 bits plus start and stop bits is enough), and the left-over part of the second frame is simply left as extra stop bits, called "marking". This is much easier than actually bit-banging and trying to keep the timing requirements of RS-232. Remember however that the 6522's SR sends and receives bits forward, ie msb first, whereas RS-232's bit order is backward, ie, lsb first, so you'll have to turn them around.
You won't be able to receive RS-232 with the shift register however. That gets even more complicated if you really want to do it with the 6522. The best way will probably be to set up T1 as a free-running timer, preferably interrupting on every time-out, and then watch for the start bit and write to T1 at that time to synchronize it. The initial value you'll write to the T1 latches will be only 1/2 to 3/4 of the bit time for the first bit so you sample the input bit before the next change, then write the full bit time to it after that and leave it alone for the rest of the frame. Repeat for each frame.
Most LCDs have a parallel interface however, and that's easier to deal with through the 6522 since there aren't any strict timing requirements that way.
I have a graphics LCD here in front of me however that is synchronous serial, actually SPI. That's not RS-232 at all. Is there any chance that's what you have? SPI is much, much easier than RS-232 to handle with a 6522.
If you really do have RS-232 and want to interface to it through a 6522, bit-banging SPI to an SPI UART like the MAX3100 would be an easier way to get there. So the processor will go through the 6522 to get to the UART, which handles the actual RS-232 signals and timing.
Huh?
I've never had any trouble using WDC's 65xx in a solderless breadboard...even at 25 MHz, but typically lower than 14.
Garth, do your comments apply to new chips or do you believe your advice still stands on chips from, say, 5 years ago?
Not trying to argue (too much) just saying.
Thanks.
--Steve
Garth, do your comments apply to new chips or do you believe your advice still stands on chips from, say, 5 years ago?
Not trying to argue (too much) just saying.
Thanks.
--Steve
Thanks for playing.
-- Lord Steve
-- Lord Steve
GARTHWILSON wrote:
#1. WDC's 6502's are too fast to be using in a solderless breadboard. The big loops of wire give you antennas and inductors all over the place; and the groundbounce, ringing, crosstalk between lines, etc. wreak havoc. There's a rather narrow range of conditions under which the thing will work at all with a solderless breadboard.
1) NEVER think about using anything but a pre-built, all-in-one, 4-pin metal-canned clock oscilators for the CPU's clock. Anything less will be too slow for the CPU on the breadboard (each strip in the breadboard adds capacitance, and each wire, as Garth says above, adds inductance, all contributing to the reduction of the clock's slew rate. When WDC says that slew must be 5ns or less, they mean it. Anything else runs the risk of intermittent and bizarre behavioral malfunctions).
2) You should be able to drive the CPU at least up to 4MHz on a solderless breadboard without issues. Probably even 5MHz. I wouldn't go much farther than this, however. Robert Grossblatt has driven 8086 CPUs up to 4.77MHz without a hitch. I've used a 65816 at 4MHz.
3) Short and sweet. This is your new mantra -- you want to keep your wires as short and loop-free as possible. Otherwise, you'll get ringing literally everywhere, which could potentially cause cross-talk on your bus signals, leading to data loss.
Quote:
Merely Slowing down the clock speed won't fix that, because the part's outputs will still have the fast rise and fall times that cause the problems. It's not WDC's fault at all, but rather a gross mis-match of technologies.
Again, pay very careful attention to detail.
Re: Could I use a 65c22 to drive an EIA232 interface?
Lost wrote:
I've got a solderless breadboard kit computer with a w65c02s CPU and w65c22s for I/O (http://www.apatco.com/products.php). There isn't much room leftover on the board to add more chips and no way to transfer data on or off the system (other than manual entry).
So, I'm wondering if anyone has managed to use the w65c22s as a serial interface driver. I would settle for bit-banging at 300 bits per second across a serial port. If so can you point me to some hints or directions?
So, I'm wondering if anyone has managed to use the w65c22s as a serial interface driver. I would settle for bit-banging at 300 bits per second across a serial port. If so can you point me to some hints or directions?
In software, transmitting can be accomplished by driving the "TX" pin low (the start bit), delay, drive TX pin high/low (data bit 0), delay, etc., up through the stop bit. It doesn't matter if there's idle time between bytes. Receiving can be similarly accomplished by waiting for a falling edge (the beginning of the start bit), delay, sample data bit 0, delay, sample data bit 1, etc. (The start and stop bits can also be sampled, but this is usually not necessary.)
To keep the math simple, let's assume that there are 100 cycles per bit (i.e. clock frequency / baud rate = 100). After the falling edge, the start bit will last 100 cycles, the data bit 0 will last 100 cycles, etc. You should sample in the middle of the bit; in other words, data bit 0 should be sampled 150 cycles after the falling edge.
Often times, one sample per bit is sufficient. In a noisy environment, you can use a majority-rules scheme. Take an odd number of samples (3 or 5) and whichever value there is more of (zeros or ones) is the value that bit has. (Because there is an odd number of samples, there can't be a tie). You may find that in most cases, it will be unanimous (i.e. all 3 or 5 samples are the same).
The nice thing with this approach is you don't have to set up timers, or deal with interrupts; all you need is one pin set up as an output and one as an input. You'll also have a lot of flexibility with which pin to use, the baud rate, the parity scheme (if any), the number of data bits, stop bits, etc, since this is all in software. The downside is that the 6502 will be completely tied up during communcation (which may not be an issue).
If I recall correctly, 100 cycles per bit is enough time to handle transmission and reception (even with 3 samples per bit majority rule), so at 2 MHz, the standard 19200 baud rate is feasible.
Here's a big tip: get the cycle counts exact. If it's 100 cycles per bit, make sure you code takes exactly 100 cycles (not 99 or 101) per bit regardless of whether the bit is a zero or a one. It may seem like extra work, but it will save you a lot of trouble later on. (I have an old 8085-based EPROM programmer that bit bangs RS-232 communication and it works correctly at 4800 baud, but not 9600 baud.) It's helpful to write a "delay N cycles" assembler macro that generates NOPs, delay loops, etc. for you.
I've written this bit-banging software before (for the PIC) so feel free to follow up if you have questions. I may even have some 6502 code sitting around somewhere (that I may or may not have tested) too. I haven't done this specifically with a 6522, but I can't see any reason why it wouldn't work.
There also some example 6502 assembly code (albeit lightly documented) in Gforth:
http://www.complang.tuwien.ac.at/forth/ ... 6.2.tar.gz
in the file:
gforth-0.6.2/arch/6502/softuart.fs
Finally, I would recommend that you plan for the possibility of a faster communications rate than 300 baud, even if you don't start out with a faster speed. 300 baud was a standard speed back in the day because it was possible for a person to read text that was displayed as it was recieved. At 10 bits (1 start bit + 8 data bits + 1 stop bit) per byte, that's 30 bytes per second. For programs of any signficant length, you may eventually find loading/saving at 300 baud to be frustratingly slow.
There's this which never struck me as a particularly good idea.
This is for the C64 user port but would, I presume, work with a 65C22.
The reason I don't think it's a particularly good idea is because it
apparently relys on the protection diodes to clamp the inputs
within VCC-ground +-diode drops and the RS232 drivers to limit
the current.
RS232 is supposed to be current limited and short circuit proof (iirc),
but I wouldn't want to count on that.
I've never tried this circuit, supposedly it works ok.
There used to be another one that was essentially the same but used
discrete transistors in place of the 7404 (which would be better)
I searched for it breifly, but didn't find it.
The letters on the left are the C64 user port designations,
they go to a 6526 which is sort of a suped up 6522.
(and a 6522 is used for the user port in other CBM computers)
I don't know if the 6522 bugs will cause problems.
(I don't think it's set up to use interupts but I don't remember
the details and I don't know if a 65C22 would have the bugs)
This circuit can be found numerous places on the net.
===================================
This is for the C64 user port but would, I presume, work with a 65C22.
The reason I don't think it's a particularly good idea is because it
apparently relys on the protection diodes to clamp the inputs
within VCC-ground +-diode drops and the RS232 drivers to limit
the current.
RS232 is supposed to be current limited and short circuit proof (iirc),
but I wouldn't want to count on that.
I've never tried this circuit, supposedly it works ok.
There used to be another one that was essentially the same but used
discrete transistors in place of the 7404 (which would be better)
I searched for it breifly, but didn't find it.
The letters on the left are the C64 user port designations,
they go to a 6526 which is sort of a suped up 6522.
(and a 6522 is used for the user port in other CBM computers)
I don't know if the 6522 bugs will cause problems.
(I don't think it's set up to use interupts but I don't remember
the details and I don't know if a 65C22 would have the bugs)
This circuit can be found numerous places on the net.
===================================
Code: Select all
RS-232C Interface for C64/C128 with RTS/CTS support
---------------------------------------------------
Using the below schematics, flow control of rts/cts can be used instead
of xon/xoff. With this dropping character problems can be minimized. Currently
it's hard to access 2400bps on a C64 and 9600bps on a C128 with this adaptor.
The schematics belongs to Walter Wickersham ( shadow@connected.com ).
user port RS232 DB25 DB9 description
--------- ---------- --- -----------
A & N------------------------+-----------1 & 7 5 ground
_____ I
B & C----------------[2 7]-+
[ ]
M------------------[3 1]-------------3 2 rx
[ ]
2------------------[14 4]-------------2 3 tx
[ ]
D------------------[5 8]-------------4 7 rts
___[6 11]___
|___[9 12]___|
[ ]
K------------------[10 13]-------------5 8 cts
[_____]
note: IC 7404's pins 6 and 9 are connected eachother. Similarly 11 and 12.
Part List
---------
7404 IC (you can easily find it)
DB25 male connector (or DB9 male)
User Port connector
2m. 2 line shielded cable. (you don't need this if your modem has the cable)
Connector Views (looking at the front faces)
---------------------------------------------
user port DB25 DB9
1 1 1 1
1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 1 2 3 4 5
1 2 3 4 5 6 7 8 9 0 1 2 \-----------------------------/ \-------------/
- - - - - - - - - - - - \ . . . . . . . . . . . . . / \ . . . . . /
- - - - - - - - - - - - \ . . . . . . . . . . . . / \ . . . . /
A B C D E F H J K L M N ------------------------- ---------
1 1 1 1 1 1 2 2 2 2 2 2 6 7 8 9
4 5 6 7 8 9 0 1 2 3 4 5
Ilker Ficicilar
filker@newton.physics.metu.edu.tr
e068214@narwhal.cc.metu.edu.tr
---
GARTHWILSON wrote:
#1. WDC's 6502's are too fast to be using in a solderless breadboard. The big loops of wire give you antennas and inductors all over the place; and the groundbounce, ringing, crosstalk between lines, etc. wreak havoc. There's a rather narrow range of conditions under which the thing will work at all with a solderless breadboard.
I've put in all the sample programs that come with the kit and written a few of my own. None of them have had the sort of problems I associate with crosstalk or groundbounce. They were all programming errors (and one error in wiring on my part).
GARTHWILSON wrote:
#2. If the LCD is truly RS-232 (timingwise anyway, even if you don't need the negative voltage, let alone higher voltages like +/-12V), you can still send it data with the 6522's shift register, as mentioned in my Tip of the day
dclxvi wrote:
If you just want to load/save programs via RS-232 (e.g. a PC's serial port), and you're willing to devote 100% of the processor time to communications during loading/saving, and only either transmit or recieve at a time (i.e. not do both simultaneously) then the hardware and the software is very simple. All you'll need for hardware is a level shifting IC for converting 0-5V signals to RS-232 voltage levels, e.g. Maxim's MAX232, and a few external capacitors as required by that IC (the MAX232 requires 4 external capacitors for the charge pump, if memory serves). The IC documentation has this information.
I've got (roughly) enough room to add one 40-pin DIP. Any suggestions as to what would be the best chip to use?
My comment of 300 baud was related more to express "anything is faster than what I have to do now" than a desire for a very slow interface. I'm hoping for around 9600 bits per second. I was expecting that when I use the serial port, the send/receive would be the only thing happening (unless I can squeeze a uart or buffer in there).
Quote:
I want the serial port to communicate with a PC to load/save programs to/from memory.
at using the parallel port (the printer port).
It'd probably be faster and simpler. you don't have to serialize and
deserialize, you don't need special drivers with funny voltages.
The tricky bit would be getting the PC to talk to your breadboard that way
but I would expect that what you want has already been done, although
I can't say I know of any specific instance.
- GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Quote:
I've never had any trouble using WDC's 65xx in a solderless breadboard...even at 25 MHz, but typically lower than 14.
Garth, do your comments apply to new chips or do you believe your advice still stands on chips from, say, 5 years ago?
Not trying to argue (too much) just saying.
Garth, do your comments apply to new chips or do you believe your advice still stands on chips from, say, 5 years ago?
Not trying to argue (too much) just saying.
The only 6502 computer I've made with solderless breadboards was back when 4MHz was the fastest available, and I used 2MHz parts. The ringing I've seen on the oscilloscope on home-made computers doesn't look good, but so far all of mine have worked. It is encouraging that someone has gotten a modern WDC part going on a solderless breadboard. It doesn't seem possible, but I'm glad to hear it is, because it means my next effort, at 3-4 times the speeds I've been working at, done with what we call "good engineering practice" should be well in the territory of dependable operation.
Quote:
and I don't know if a 65C22 would have the bugs)
I did run into a difference in operation between CMD and Rockwell 65c22's, described in Tip of the Day #20 at viewtopic.php?t=342&start=20 . It involves the "ready" status of the shift register.
Quote:
There's this which never struck me as a particularly good idea.
This is for the C64 user port
This is for the C64 user port
Quote:
The reason I don't think it's a particularly good idea is because it apparently relies on the protection diodes to clamp the inputs
First, let me say I agree with every thing you said.
The RS-232 specification requires transmitters to send 1's and 0's as at least -5V and +5V respectively, which a 7404 definitely cannot achieve. Receivers must recognize 1's and 0's as being down to -3V and +3V respectively. A 7404 might work in a few situations where the specification is not being strictly followed-- but you cannot count on it.
I phrased that poorly.
I should have said this strikes me as a particularly lousy idea, but the
three or four people I've talked to who actually tryed it said it worked
great and they never had any problems.
I have heard that it's not at all uncommon for RS232 to respond to
essennially TTL levels. My recollection is that that's what the 1489s do
Under some conditions you may get latch-up. In the case of CMOS input-protection diodes, I've read from Dr. Howard Johnson, who lectures on high-speed digital design, that they are not made to handle more than the occasional small static discharge, and that if subjected to regular use in input clamping with any significant current, they won't last. You'd think they're just regular small diodes that are made to carry current and last indefinitely at room temperature, but I guess they're not. I couldn't tell you from experience about the latter, but I have had Rockwell and maybe CMD 65c22's latch up from voltage spikes on the I/O pins, causing a temporary non-op condition (until the power is cycled) and a very hot 65c22!
My recollection is that the Farchild app notes claim their HC to withstand
~40ma thru the protection diodes at room temperature before latch up
occurs.
IIRC RS232 is supposed to be limited to a 500ma short circuit current
but the 1488 driver chips are limited to around 10ma and I think the
MAX232 charge pumps were only good for about 20ma total.
But latchup is just the most dramatic thing that can occur.
Putting current through the protection diodes is liable to get it into odd
places where it causes more subtle problems.
Some external Schottky clamps might be all you'd need though
But I think the circuit is intended to use TTL
GARTHWILSON wrote:
Quote:
There's this which never struck me as a particularly good idea.
This is for the C64 user port
This is for the C64 user port
I should have said this strikes me as a particularly lousy idea, but the
three or four people I've talked to who actually tryed it said it worked
great and they never had any problems.
I have heard that it's not at all uncommon for RS232 to respond to
essennially TTL levels. My recollection is that that's what the 1489s do
GARTHWILSON wrote:
Quote:
The reason I don't think it's a particularly good idea is because it apparently relies on the protection diodes to clamp the inputs
~40ma thru the protection diodes at room temperature before latch up
occurs.
IIRC RS232 is supposed to be limited to a 500ma short circuit current
but the 1488 driver chips are limited to around 10ma and I think the
MAX232 charge pumps were only good for about 20ma total.
But latchup is just the most dramatic thing that can occur.
Putting current through the protection diodes is liable to get it into odd
places where it causes more subtle problems.
Some external Schottky clamps might be all you'd need though
But I think the circuit is intended to use TTL
Lost wrote:
I've got (roughly) enough room to add one 40-pin DIP. Any suggestions as to what would be the best chip to use?
If you have a PAL programmer (or access to one), you could probably come up with your own minimal design in a smaller package. Without having worked it out, I would guess that using standard discrete logic ICs (e.g. something like a 74LS74 flip-flop or a latch for the TX output) would, after accounting for any necessary additional address decoding, probably wind up taking more breadboard space than the 65C22.
Lost wrote:
I'm hoping for around 9600 bits per second.
bogax wrote:
have heard that it's not at all uncommon for RS232 to respond to essennially TTL levels.
This "it seems more reliable that the spec would lead you to believe" behavior isn't all that surprising, I suppose. There's got be a point where the RX input switches from high to low. If that point is just above ground, than that would easily satisfy the RS-232 spec, which only has to be somewhere between -3V and +3V. (The switch point isn't required to be just above ground of course, but apparently that's a pretty typical place for it.) At room temperature, you'd the TTL or CMOS low output voltage would typically be near enough to the ground rail that the RX input switch point would be between the TTL/CMOS high and low voltage levels. In the other direction, -5V and +5V are far beyond the requirements for the high and low voltages of a TTL/CMOS input, but if there's a current limiting resistor or somesuch in there, it may take a long time for the stress to cause the input to fail. CMOS and TTL ICs can be tough little buggers at times. Of course this is no substitute for a robust design that actually meets the spec.
Quote:
1) NEVER think about using anything but a pre-built, all-in-one, 4-pin metal-canned clock oscilators for the CPU's clock. Anything less will be too slow for the CPU on the breadboard (each strip in the breadboard adds capacitance, and each wire, as Garth says above, adds inductance, all contributing to the reduction of the clock's slew rate. When WDC says that slew must be 5ns or less, they mean it. Anything else runs the risk of intermittent and bizarre behavioral malfunctions).
- GARTHWILSON
- Forum Moderator
- Posts: 8773
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Quote:
When you look at the original Amiga prototype with all its wire-wrapping... it had to be 100 times worse for interference than a small breadboard with a few chips on it.
meganb wrote:
When you look at the origional Amiga prototype with all it's wire-wrapping... it had to be 100 times worse for interference than a small breadboard with a few chips on it.
A wirewrapped circuit, in contrast, introduces significant capacitance only where wires cross or trace each other, and with the small size of wirewrap wire, the amount of capacitance isn't any more than most PCB capacitance for equally long traces. Moreover, a wirewrapped circuit is much, much easier to engineer in a 3-d stack of boards (as the original Amiga boards demonstrate), thus allowing a substantial wire length savings.
This is why the original Cray supercomputers were wire-wrapped, and built in a cylinder shape, to minimize wire lengths and overlap. As a result, speeds upwards of 80MHz were attainable (for the whole computer, not just an isolated piece of circuitry), utterly unheard of at the time the first Crays were released.
Note also that the overwhelming majority of the Amiga's custom chips are architected as a pipeline, so although the boards exist as a stack, and each board is large, the average length of wire never spanned more than a quarter of the board. Only CPU bus lines tended to span farther.
I challenge anyone to build an 80MHz, fully functional computer using only breadboards as its substrate. You cannot use FPGAs (since in order to couple the FPGA to the board, you'll need to use a PCB, something I must forbid for this challenge for maximum fairness). Good luck.
kc5tja wrote:
I challenge anyone to build an 80MHz, fully functional computer using only breadboards as its substrate. You cannot use FPGAs (since in order to couple the FPGA to the board, you'll need to use a PCB, something I must forbid for this challenge for maximum fairness). Good luck.