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?

#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.

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

_________________
Thanks for playing.
-- Lord Steve

Having gotten a 65C816 running at 4MHz on a solderless breadboard, I can pipe in a few tips here.

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.



Not sure why the issue of blame came up here. But, I agree that the very fast rise- and fall-times on the chips can produce noticable cross-talk on a number of signals. But, it is very possible to build a simple computer on solderless breadboards. It's certainly possible to place a 65C22 chip on the breadboard too.

Again, pay very careful attention to detail.

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.

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.

===================================

I'm still learning here so I can't argue with the risks you have pointed out (though others appear to have) but I can say that I've set-up the system and it is running just fine at 2MHz.

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).



I want the serial port to communicate with a PC to load/save programs to/from memory. The LCD that is part of the kit uses a parallel interface that is controlled by a 6522 and works fine.



I was asking about using the 6522 because I have a spare 6522 and just enough room left on the board to add it (and maybe one or 2 smaller ICs). Given all the other responses I think I will take your advice and go with a MAX232 (or something similar) add a serial port.

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).

If you don't have your heart set on the serial port, why don't you look
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.

If you do a really neat job and keep the wires down against the board as short as possible and not have the flying arches, you'll be a lot less likely to have problems. I have no doubt that Samuel's solderless-breadboarded Kestrel had the clock problem because of high-flying wires in the picture he posted. With the clock's rise time too slow, coupling a stray edge from a nearby wire would result in a glitch in each clock edge. The capacitance between rows of the solderless breadboard may be a problem too. Industry guru Bob Pease had an article in Electronic Design magazine about that. I think it was called, "What's all this SMWISIC [show me where it says I can't] suff, anyhow?" where he tells of customers having problems with their (National's) parts and not understanding that it was the breadboard.

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.


The only bug in WDC's 65c22 is the matter of using an external shift clock. It won't see the CB1 shift clock edge if it falls within a certain short time of the phase-2 falling edge. The only bug I recall from other brands or 65c02 is hardware latchup under certain conditions. More about that in a minute.

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.


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.


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!

First, let me say I agree with every thing you said.



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



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

All you need is one 0-5V input and one 0-5V output. If that isn't already available, then a 65C22 will give you that and a whole lot more. You'll only need a quarter or so of the 65C22's pins, which may seem like an inefficient use of valuable breadboard real estate, but it should give you what you need in a single IC. Plus, you'll probably eventually think up things to do with the 65C22 features that you don't initially 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.



9600 baud should be well within the realm of possibility.



I've found most serial ports are very forgiving. One conversion circuit I worked with years ago used a standard NPN inverter with the one of the handshaking outputs (DTR, maybe -- I don't remember the circuit exactly) as the supply voltage for the 0-5V to RS-232 voltage conversion. I think there was a diode in there somewhere too. I can't recall how the other direction was handled. The whole circuit was so small that it fit inside the hood/shell of the DB9 serial port connector, even with leaded parts! Even though it wasn't within a mile of the RS-232 spec, it worked with every PC I tried it with, as I recall.

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.

I've had my breadboard kit working at 2, 4, & 8Mhz with a 2 pin crystal gate configuration. I'm not sure what the big deal is with using a breadboard, cause It seems to work fine. 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.

Besides the fact that the original Amiga wasn't very fast, wire-wrapping can be a lot more friendly to fast logic than solderless breadboards with strips of sockets, especially if the wire-wrap board has a ground plane and that ground plane is used correctly. If there's a power plane on the other side, all the better. It's pretty difficult to determine how well a particular circuit will work on either kind of breadboard though, since each person's construction habits are different and nearly impossible to model. If we know we may be pushing the limits, we just do the best we can with the theory and then be pleasantly surprised if it works as well as (or any better than) we had hoped. There's a nebulous term for this: "good engineering practice."

On the contrary; a breadboard introduces substantially more capacitance than any wirewrapped project I've ever worked on. The reason is pretty simple: lots and lots of strips of metal, all in parallel making nice capacitors, whether you actually use them or not. Then, on top of all that, you still have to deal with wires going every which way over the board, leading to large inductances. The result of combining large capacitance and large inductance is a low-pass filter, and that is ultimately what determines the fastest speed you can safely attain with a breadboard.

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.

This might be a stupid question, but does the http://www.xgamestation.com/view_product.php?id=34 count?