Breadboard 65c02 computer reliability/stability (er, lack thereof) - Page 1
Forum section: electronics / beginners

author: sci4me
author_rank: Regular Contributor
timestamp: March 03, 2019, 05:44:12 am
content: Hey guys, so, recently I've started working on a 65c02 computer. I've had a small amount of success but it's been plagued by unreliability and instability. I have a WDC 65c02, an AT28C256 EEPROM, and a 65c51 on my breadboard, along with a 74LS04 for decoding purposes.Basically what I'd like to hear about is what kind of things should I look for that might be causing the instability. By instability I just mean it simply doesn't behave as expected. I have a program in the EEPROM that just writes ASCII bytes to the serial port. I have seen it work many times but it seems to work maybe 1 in 50 times or less...Unfortunately I (still) don't have the proper tools to properly debug it. I'm hoping to get a DS1054Z but at least for the next few weeks, I have nothing. This means my only hope of "debugging" is just fiddling with it; not an effective strategy.But the fact that it does work rarely tells me that I've managed to connect things correctly and program it correctly. So I guess I'd just like to hear if there's anything obvious that I can look into that might be a problem for stability. One thing I ran into when I first started was the clock was actually too fast. I bought a 1 MHz crystal oscillator and have had no luck with it, so I ended up hooking up an Arduino and programming it to generate a ~500 KHz square wave (50%) and it worked fine. During my fiddling with it, I've tried slower clock rates (and slower baud rates for the serial port) but have had no luck with that.I've attached a picture of my setup along with a schematic. Not sure if there's much anyone will be able to do to help without me being able to measure signals with a scope but I'm desperate. (Of course it's also entirely possible that there is some design mistake but I have yet to see it...)

author: oPossum
author_rank: Super Contributor
timestamp: March 03, 2019, 05:59:11 am
content: Place 100 nF caps near the supply pins of each chip.Make sure the power rails of the breadboards are not broken in the middle - it is common for them to be split.

author: GK
author_rank: Super Contributor
timestamp: March 03, 2019, 06:08:11 am
content: For a start, don't use the PHI2O output pin on the WDC65C02 to drive anything. This is explicitly recommended in the datasheet. The WDC65C02 is designed to operate as high as 14MHz - much higher than the original 6502. To this end valid data is only guaranteed to remain on the data bus for 10nS after the (falling or rising - can't remember which ATM) edge of the PHI2 clockinput. Propagation delay (uncontrolled and no longer specified/guaranteed in/for the WDC65C02) from the PHI2 input to the PHI2O output is a majority chunk (from my testing) of this 10nS, which (in the case that there isn't any data bus buffering between the '02 and the external devices, extending the data hold time by virtue of the buffering devices own internal propagation delays) eats away almost all remaining setup/hold time for write operations and makes for either unreliable or completely inoperable communications between the WDC65C02 and peripheral (VIA, PIC, ACIA.....) devices.The proper way to configure a system with the WDC6502 is to generate a robust clock signal/source and to use this to clock everything in parallel.EDIT: found the general timing diagram and PHIxO notes. The datasheet isn't really as clear on this critical requirement as is ought to be.

author: sci4me
author_rank: Regular Contributor
timestamp: March 03, 2019, 07:57:02 am
content: I have taken the given suggestions; each chip now has a 100nF cap at its supply (plus the other caps littered on my supply rails) and I have moved the PHI2 input of the ACIA to be driven from the same source as the PHI2 input on the processor. Additionally I have verified that the power rails are not split.I think the next thing for me to do is re-verify the software and each individual connection. ... I feel like I'm really running out of things to try without being able to look with a scope... but my desperation persists.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 03, 2019, 07:58:21 am
content: This is very, very like an A-level project I did at school - getting on for 30 years ago!It was a great learning experience, though perhaps not in the way you'd expect. I had very few issues with the electrical design, but some major problems with the breadboard itself.The main thing was power distribution. Simply daisy-chaining the power rails from one board to another didn't work, because the contacts were quite resistive, and multiple connections in series meant the voltage dropped too far. I remember that, with it in this state, adding decoupling capacitors across the power supplies of the chips actually prevented it from working at all.Symptoms were truly bizarre, like: it had a 2 digit LED display, which would work fine until you put your hand near it, then it would gently fade to a dim '88'. Move away and it's OK again.The fix was simple, just run multiple wires from the supply to each of the individual power rails, then decouple properly.IIRC it ran at 2 MHz and would have had a 32kx8 SRAM, with code stored in a 27128 EPROM. Input and output consisted of a numeric keypad, an ADC and a DAC, and it was used to do simple audio effects (echo, reverb, reverse etc).Really enjoyed that project, even if it was ridiculous overkill under the circumstances.I got an 'A'

author: sci4me
author_rank: Regular Contributor
timestamp: March 03, 2019, 08:11:11 am
content: Quote from: AndyC_772 on March 03, 2019, 07:58:21 amWell I'm quite perplexed right now. I had tried a few other things with no luck so I removed all the extra caps I had on my power rails but kept the ones I had on the supply of each chip. Coincidentally, it worked right after that!Then I write slightly different code on the EEPROM (which should still work) and it stopped working. So I tried removing the rest of the caps and it still doesn't work. Finally I reverted the code change and ... it's still non-functional.So, it does work... once in a blue moon... *sigh*

author: iMo
author_rank: Super Contributor
timestamp: March 03, 2019, 08:12:07 am
content: With modern MCUs and components the solderless breadboard works with 20-30MHz designs, at least in here.The older chips need much more current so a good decoupling (100nF ceramic at each chip and some 10uF tantalum or ceramic multilayer at each segment) and doubling the power rails is a must as indicated above.The '51 baud generator needs 1Mohm in parallel with the 1.8MHz crystal afaik.With low frequency clocks or "single step" button implemented always doublecheck whether some of your chips do not use "dynamic" registers/logic (like old drams, it requires a minimal frequency then). Only "fully static design" chips can work reliably with low clocks or simple single step.With longer wiring the use of termination resistors should be considered.

author: sci4me
author_rank: Regular Contributor
timestamp: March 03, 2019, 08:13:10 am
content: Quote from: imo on March 03, 2019, 08:12:07 amThat's one of the next things I need to try; a higher-current supply. For all I know that could be a large part of the problem...EDIT: Adding a 1M resistor across the 1.8MHz crystal didn't change anything, but it is in the datasheet.EDIT 2: Well... it's still unstable but the suggestions I've received so far have dramatically improved stability. It now works something like, I don't know, 1 in 5 times? It depends... it seems like it will work consistently for a while and then it'll stop working for a while... and sometimes it'll work but then I'll reprogram the ROM and it'll stop working again. Feels like just breathing wrong will make it stop working.Although I have yet to see it stop working as it's running...

author: iMo
author_rank: Super Contributor
timestamp: March 03, 2019, 08:40:10 am
content: The modern CMOS WDC should be fully static design, so I would implement a simple HW "single step" button (with a second 555 for example). After the reset you may then step through your code, while observing the data/address bus with a logic probe (or o'scope or DMM) and you will easily see what is going on.The old NMOS would require a different single step handling.PS:1. Could you elaborate on how do you provide the Chip Selects for the '51 and the EPROM?2. No SRAM required in your design?

author: sci4me
author_rank: Regular Contributor
timestamp: March 03, 2019, 09:02:57 am
content: Quote from: imo on March 03, 2019, 08:40:10 amAs of now, the "address decoding" is very simple; the 15th bit of the address bus goes to the input of a 74LS04 NOT gate; it also goes to the CS pin on the '51. The output of the '04 goes to the CS pin on the ROM.SRAM will come soon.

author: sci4me
author_rank: Regular Contributor
timestamp: March 03, 2019, 04:25:53 pm
content: It was working when I went to sleep. Just got up, turned it on, and it's back to not working. Nice. Two days in a row it's done this.So clearly I haven't even come close to eliminating all the instability...EDIT: Slowed the clock down by a factor of two and it started working...I'm starting to think it may be related to the USB to serial converter I'm using. It's this one:https://www.adafruit.com/product/954?gclid=Cj0KCQiAzePjBRCRARIsAGkrSm45qYTK-wOEYFku9vi1ckV7UWLs9Cgkh6FfsjBoIknZE5VU7eSxvjsaAoxqEALw_wcBI can see that data is being written on the TxD line of the ACIA, but I also see the serial converter pulling its own Tx line low. It pulls it low a few seconds after being powered and holds it low until I power cycle it.EDIT 2: Well I feel like an idiot. Turns out another issue I have to watch out for is my laptop assigning the USB to serial converter a different name in /dev !!EDIT 3: Yeah I think there are power supply/distribution problems...EDIT 4: Clock distribution? I think this is it actually. Or, part of it. I tried connecting the clock to a 74LS00 I was going to use for address decoding and it started flaking out so I undid that and it works fine again.EDIT 5: Something about feeding the clock into a 74LS00 is definitely causing consistent instability...EDIT 6: At this point, it will work for a short period of time and then start behaving strangely. It writes to the serial port as expected for a while and then starts missing characters and writing the wrong characters...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 03, 2019, 09:27:26 pm
content: It sure would be nice to have a single ground for everything; unfortunately, the reality is that you've got a forked power distribution network, and signals routed completely away from them. So every time a chip toggles its output pins, it produces an upset that plucks the tines like a tuning fork.It may help to put shorting wires between grounds, and between supplies (the latter are optional if VDD/GND are bypassed to each other periodically), turning the forked power supply into more of a grid.It would also be nice to have a connection to the ground plane, the panel the breadboards are stuck to. Sometimes this is a bolted connection to binding posts, sometime it's completely floating. If floating, consider scraping paint away to make a few connections from it to ground. It's probably aluminum, so, don't expect to get a soldered connection, or at least a nice one, but a clamping spring would be okay.High speed signals may benefit from ferrite beads, to slow the edge rate. This would be rather annoying to employ here on so many signals, though. I've had to do it on breadboarded SPI before, which is a lot easier to put beads on.Tim

author: sci4me
author_rank: Regular Contributor
timestamp: March 04, 2019, 03:17:01 am
content: Frankly I'm quite confused as to why I'm still having dramatic instability even with a clock speed under 1KHz. Is it the edge speed, bad contacts, contact resistance, capacitance, etc.I'm becoming more and more tempted to spin a PCB with my current design... given that I know what I've built does work. However it concerns me because I want to also add a 65c22 VIA ... and I haven't been able to test that on the breadboard. Might just give it a go, not sure...

author: radiolistener
author_rank: Super Contributor
timestamp: March 04, 2019, 03:51:02 am
content: try to decrease length of wires, especially with high frequency signals.And use exactly the same length of wires for all lines in the address/data bus.Also, check that your power supply is enough and clean.I noticed that these breadboard has high resistance.So, the voltage may be drop down significantly.When I tried to power high speed ADC through breadboard, I notice for about 0.2-0.3V drop.

author: amyk
author_rank: Super Contributor
timestamp: March 04, 2019, 03:57:54 am
content: A 65C02 is a static design, clock itreallyslowly (as in 10s of Hz or lower) and see if your problems persist.

author: sci4me
author_rank: Regular Contributor
timestamp: March 04, 2019, 04:49:50 am
content: Quote from: radiolistener on March 04, 2019, 03:51:02 amEDIT: Same length wires? How important is that at low speeds? I mean, the differences in wire lengths in my particular case should equate to sub-nanosecond differences... is that really enough to throw it off? I'm skeptical of that, considering it's been working previously...As of right now, I can't get it to function properly at 50 Hz or even 10. I was messing with it earlier so I think I need to re-verify my connections again. Hopefully I'll find something I messed up...It's back to writing a single 0 byte to the serial port.As for power, I share the suspicion that the power isn't high-enough-quality, but unfortunately I literally have no way to test it right now. I have a multimeter... but it's ~1000 miles away right now. I'm hoping to have it in a week or two.I also intend to buy a scope but ... again, it's gonna be a while. So I'm truly going at this blind.I also wonder about my clock source; since I can't use the 1 MHz oscillator, I'm (hackily) using a SiFive HiFive1 board (Arduino compatible RISC-V) to drive the clock. It's been working this whole time but.. idk.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: March 04, 2019, 05:40:45 am
content: Quote from: sci4me on March 04, 2019, 03:17:01 amYes, edge speed most likely.Quote from: amyk on March 04, 2019, 03:57:54 amUnlikely, if edge rate is the problem. It may not even be possible to clock it once, as such! Signal bounce at the end of the clock trace, say, can deliver several clocks much too quickly, leading to inconsistent internal state, and freezing.Tim

author: sci4me
author_rank: Regular Contributor
timestamp: March 04, 2019, 05:48:03 am
content: Quote from: T3sl4co1l on March 04, 2019, 05:40:45 amWell, what's most likely going to happen is I'll end up re-building it from scratch. Not sure what else I can do without being able to measure what's going on...

author: iMo
author_rank: Super Contributor
timestamp: March 04, 2019, 07:34:38 am
content: I doubt it is about "edges" or signal integrity. People mess with dozens of cmos chips on a solderless breadboards clocking them at megahertzes. Sure, the wires shall be as short as possible.Double check your wiring and rethink your design.Terminate the data bus with say 10k pullups (a single 8x10k SIP module may do). Remove your EPROM. Ground specific data pins with 22-50ohm resistors such you get "EAh" - the NOP instruction, afaik.Without any EPROM inserted the MCU shall now increment its address bus from 0..65535 in a loop so you may easily observe what is going on.Also do implement HW single step button.PS: Do not panic - these kind of exercises require a certain portion of experience and debugging effort

author: sci4me
author_rank: Regular Contributor
timestamp: March 04, 2019, 03:54:50 pm
content: Quote from: imo on March 04, 2019, 07:34:38 amThe "EAh" thing was the very first thing I did and it worked a treat. I haven't observed any problems that are explicitly relating to the EEPROM but it's possible that I just haven't been able to observe them.I'll try terminating the data bus...

author: soldar
author_rank: Super Contributor
timestamp: March 05, 2019, 09:24:26 pm
content: Quote from: AndyC_772 on March 03, 2019, 07:58:21 amAround 1979, 40 years ago, using the 6502 I designed and built an access control system. I still have it.Maybe I am wrong but I would not dream of using breadboard because I do not consider the connections reliable enough. I used wire-wrap sockets and solder connections. After everything was working fine I designed and built the double-sided PCB.IMHO using breadboard for this type of project is asking for trouble.

author: sci4me
author_rank: Regular Contributor
timestamp: March 05, 2019, 11:02:48 pm
content: How plausible is it that tying the BE (bus enable) pin directly to VCC instead of to VCC through a resistor could cause these stability problems? I got a suggestion elsewhere to use say a 3k3 resistor instead of tying it directly, and, so far the computer has been 100% stable! Is this actually solving my problem or am I just getting really lucky right now? (I've even been able to up the clock rate significantly with no problems whatsoever... so far...EDIT: I don't understand why but this was absolutely the problem. I've been programming it and using it and it's been nearly 100% stable since. The only instability was when I move it around, probably shuffling some connections. Took almost no time to get it back to normal.

author: iMo
author_rank: Super Contributor
timestamp: March 06, 2019, 09:16:27 am
content: Quote from: sci4me on March 05, 2019, 11:02:48 pmWhile looking at your wiring - your BE(36) wire to +5V goes to a different +5V rail segment as the MCU's Vdd goes.Your decoupling is not optimal - your elyt capacitors are placed on the top horizontal rail. From that rail the vertical segments are fed. Thus your capacitors shall be rather placed on the vertical power rails (because of the jumpers between the horizontal and vertical power rail bars which introduce some resistance/inductance and the vertical bars are much longer).You still miss 100nF ceramics placed everywhere (the XXuF alu elyts have none effectiveness when talking fast edges/spikes/glitches).It could be, because of wrong decoupling, that there are glitches between the vertical power rail bars. It may induce an instability to the BE then (as the MCU's Vdd is connected to a different vertical power rail than the MCU's BE pin is connected). The 3k3 resistor may reduce/filter the glitch, therefore it looks "more stable".Try to connect the BE pin directly with pin 8 (Vdd) of the MCU - my guess is it will work fine without the 3k3 resistor then.Also you may place a 100ohm resistor in series with clock signal to suppress ringing.Long time back I saw in some old NMOS 6502/680x datasheets they recommend to put 8x100ohm in series with the data lines (the resistors wired close to the MCU). It may not be applicable to the modern CMOS versions.The 8x10k pullups on the data bus and address bus may help too.Improve your Vcc/Gnd wiring and decoupling and all will work fine. As I wrote above, people did 20x bigger stuff on such a solderless breadboard at much higher clock speeds and it worked..

author: sci4me
author_rank: Regular Contributor
timestamp: March 06, 2019, 01:37:10 pm
content: Quote from: imo on March 06, 2019, 09:16:27 amThat was my next question: is using electrolytic capacitors not going to help me? I didn't think so. Probably should have swapped those out earlier! But now that I've placed that resistor, it's working even without doing that. Well, I'll do so anyway!