gfoot wrote:
...
I think at this point people split into two camps - one says don't use breadboards, use wire wrap or make PCBs; the other says, keep using breadboards but be aware that you're likely to suffer some difficult debugging from time to time. Personally I've found this to be not as bad as people imply it will be, but everyone's experiences vary. I've certainly had a fair few occasions where things aren't working well, and the oscilloscope shows periodic fluctuations in signal or VCC levels compared with ground, and occasions where I've had problems with reflections on my clock causing double-counting and things like that - in these cases series or parallel termination has helped. But for sure, to some extent if you go this route and still want to achieve things like VGA clock frequencies, on a breadboard, you will need to be prepared to debug issues without many clues as to what's actually wrong.
Definitely agree. I'm too clumsy and I've already shorted a few things and roasted them. (My poor PS/2 keyboard!
(oh well, guess it's time to give those cherries I have lying around an excuse to live!
) )
Quote:
...
I have seen definite benefits to having bulk capacitance on every breadboard power rail, and providing power to each power rail from a direct "star" topology connection to the power supply rather than daisy-chaining them (or at least minimising the daisy-chaining). 4.7uF is quite small for this purpose though, I use 100uF-330uF (whatever I have available).
For sure, 4.7 is what I had available, which at first I grabbed from an old Radio Shack electronics lab. I can get a few bigger ones if need be.
Quote:
Quote:
The analog side of electronics has been a lot more baffling to me. Part of the reason why I mostly stuck with software I think, the digital side of things has always been very clear to me.
Up to a few MHz I don't think any of this matters very much so long as the clock lines are clean, and as BDD said using slower logic families (edges specifically) can help. Most other signals in your circuit will get sampled on the edges of the clock, and any time taken for them to settle down and stop ringing doesn't matter too much at low clock rates. This is for me the main mitigation for dealing with these things on a breadboard.
Yea, the 6.3MHz is right around the limit of what I can do with my EEPROM, so that's what I've stuck with. It feels like it would be slow enough to not cause too much trouble, and as I mentioned, things didn't seem to improve any when I dropped the clock closer to 1.5Mhz (25.175 / 16). I want to say I caught it doing this nonsense when I was single stepping the clock by hand, but I'm not 100% sure of that. I do have a 1MHz oscillator I can also throw on there for good measure, or I can just whip up an astable 555 circuit. I have plenty of those lying about.
Quote:
For things that have to be at specific faster rates (are you doing VGA, as you're using a 25.175MHz oscillator?) you need to take a bit more care with those signals, keep an eye on them with an oscilloscope, and watch out for other things being affected by them (e.g. power/ground levels spiking on clock transitions, which can affect unrelated nearby ICs). And for things that are edge-triggered you need to make sure they transition cleanly without ringing too much. It is a lot to keep an eye on.
The plan is to do some video projects with a few of the older monitors I have which accept a 15-pin VGA yes.
Quote:
Regarding your specific problem here, I tried to read the schematic but couldn't really follow it, due to the issues others have mentioned. It didn't stand out a being wrong, but the address decoding is quite complex. My main advice is to try to simplify the circuit and see if it still goes wrong. You've already tried removing the 65C51, and it appears to prevent the problem, which is great. It still may or may not be the actual cause. BDD's point about F-series voltage levels is important. I'd also wonder whether it's something silly like the 65C51 causing an interrupt which you're not handling - have you tried disconnecting its IRQ line?
Good question, I have not physically disconnected the IRQ line, but I have turned off interrupts on the CPU. The NMI pin is tied high, so I don't think those are the cause. Perhaps somewhat ironically I did not see this behavior until I started trying to use interrupts and was wondering why everything was behaving oddly, so I started stripping my code down to the bare bones. Which is how I ended up with just a simple program that just does a 16-bit count in the zero page.
No interrupts, no use of the UARTs, just the 16-bit count in ZP, and writes to the 65C22 to display to the LCD module.
Quote:
Otherwise, assuming it is the 65C51, the main candidate would probably be that it is driving the data bus when it's not meant to be selected, which comes back to the address decoding again. If you have a digital oscilloscope, setting it to trigger on the 65C51's chip select and capture also the clock and maybe some address lines, might show up some oddness in that signal.
This was my suspicion as well. I tried putting the scope and setting a low going trigger on the CSB line which is what I'm using to drive them, and I don't even so much as see a ripple on it. :/
I
think I got this right, but I'm a complete beginner when it comes to using scopes.
Quote:
Another thought is that if it doesn't matter what kind of UART you put in your circuit there, does it matter if you put something else entirely? e.g. a bus transceiver, enabled by the same CS line, which drives the data bus whenever the UART's CS is asserted. You can make it drive the data bus to $00, the opcode for BRK, and it will be very obvious if this is happening at the wrong times.
I did try a 470 ohm resistor pack and drove the bus high and low with that, but nothing misbehaved. (Of course though, anything else asserting to the bus would just ignore the resistors)
I will definitely give the bus transceiver a try!
Thank You.