Sadly, price and quality don't always correlate. Breadboard wizard Radical Brad uses breadboards from Twin Industries, so that's what I chose. To me they didn't seem overly expensive.

And I wasn't eager to find a cheaper one anyway. Price aside, the value of a breadboard that sabotages your project is close to (or even less than) zero.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I've successfully built quite large projects (e.g. https://github.com/gfoot/compvideo6502) on very cheap breadboards without too much trouble. But I've bought another batch from the same seller and marketplace and found them to be much worse quality, although they look identical. So I think it can be hit and miss.

If DIP chips are popping off the board, perhaps the pins need some gentle realignment. As-shipped, the pins are often somewhat splayed, and by careful pressing against a steady flat surface you can bring them to the correct row-to-row distance. (0.3 inch for smaller DIPs)

It's also possible, if the chips are rather old, that the pins are tarnished, and can usefully be cleaned with a fibreglass pen or pink abrasive pencil eraser. If the pins or wires make poor contact, that'll be a source of unreliability and frustration.

I had new chips on this batch, from Mouser. I don't know if I'll try that alignment thing because I'm just tired of looking at it, thank you though.

George and Jeff, it's good to see some folks can use them! I wasn't intending on making this topic a breadboard discussion, just telling you my experiences on this particular project.

I'm going to follow Ben Eater's design very closely (only changing it to 640x480 with 25.175 MHz clock instead), since I know it's a proven design. And then I'll either print a board or solder on perfboard. I'll keep y'all updated if there is anything to update.

Thanks everyone.

Chad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That indeed is a good takeaway from this experience. There are lots of things I need to buy still: EPROM programmer, good breadboard, better multimeter. New probes are on the way, and thankfully this scope was basically "free". Thank you BDD. My collection is slowly growing.

And Garth, indeed. I got my first one from Jameco, but the Radio Shack one was a gift from a friend. Who knows if they are Chinese or not.

Thanks guys.

Chad

Before I realized pc board technology had became affordable, I was prototyping fair size board using point-to-point wirewrap wires. This was the prototype board of Tiny302 which was about the time I discovered the cheap PCB technology, circa 2017. That was my last significant prototype effort. I still prototype with point-to-point 30-ga wire, but at a much smaller scale. I seldom use solderless breadboard for prototyping--it has reliability problem as you've discovered.
Bill

2017 seems like ancient history, haha

Well I know all about that point-to-point stuff. I like your board, looks good, the smaller wires make it look clean. I was talking with my wife about this today, and she said I need to weigh the time and money aspect. Basically a printed board is probably the best solution at this point.

Attached is a brand new schematic I worked up today. It uses a lot of the counter and logic ideas from what I was trying to do on the breadboard. But then I added the RAM and a way to access it. The main idea is that this will "shadow" my ROM on the 6502 side of things. If I read, it's from ROM, if I write it's to this video RAM.

Some things I have altered or kept because of my experience today:

1) I'm using the '161 and not the '163. Going with Ben Eater here, the async reset make sure that I actually reset on the value I'm trying to hit. No need to search for 799 when 800 is the goal.

2) I'm using the '688 instead of whatever NOT-NAND gates that it might replace. The '688 is still fast and it's all included, no need to have a ton of logic chips going this way and that. And no nesting required.

3) I'm going to keep the SR Latches, they are easy to use and when soldered I doubt they will jump off my board.

4) Because the counters are counting real pixels, there is no need for me to have a separate set of counters for the RAM. This alone has removed 8 chips that my previous idea had.

5) 6x '245 bus transceivers will let me read from the RAM and write to the RAM at proper times. My previous idea was to use latches and a VIA, sharing the data bus, but this 'shadow ROM' idea will make it much easier to access, and very fast.

6) Instead of trying to squeeze my RAM to fit every pixel on the screen, this will just be a colorful block in the top-left corner. This eliminates a lot of glue logic and complexity. It won't look perfect, but it will display all the same. Later editions of this board could shift or stretch the size if I desire.

7) I might add some additional enable lines, but I'm trying to keep this side super basic.

If you have any thoughts let me know. I'm willing to hear it. There won't be any more 'testing' of this board, I'm going to solder whether it's a printed board or just perfboard.

Thank you everyone, I appreciate your feedback so far, it has been very helpful. It has likewise been a morale boost when I needed it most.

Chad

The main concern I have with the design is the asynchronous outputs of the 6 comparators. Synchronous counters do produce cleaner outputs but using them to drive comparators and expecting the comparator outputs to be glitch-free can be a risky move. The signals I'm worrying about are /H800 to aynchronously reset horizontal 74HC161 counters, /H800 to clock vertical 74HC161 counters, /V525 to aynchronously clear vertical counters, /H656, /H752, /V490 and /V492 for HSYNC & VSYNC generation. Glitches on these comparator outputs can throw the counters out of sync. Maybe I'm worrying too much, but I would gather all comparator's enable inputs together and connect to ground through a low value resistor, so if there are unwanted glitches, the comparator's enable inputs can be qualified with the 25MHz clock.

You should tie unused inputs to VCC. Does the oscillator really has an enable input? It need to be enabled if so. RGB inputs have 75 ohms termination on the monitor side so if your HC245 driver is tri-stated, these inputs will pull down to ground.

I would watch /H800 carefully. It will be a short, spiky output; as soon as the count reached 800, it asserts and clear the horizontal counters which, in turn, cause /H800 to immediately de-assert and clock in the vertical counters. That spiky signal will drive 3 counters going down and then drive 3 more counters going up. It'll probably all work, but I'm just a worrywart. It makes me want to emulate it with a CPLD...
Bill

Worrying is good

This is why I prefer to latch these kinds of derived signals from a clock signal so that anything responding to them does so after the interim logic has settled down, and any feedback effects (like resetting counters) don't happen until the following clock cycle.

You might be able to do that in Ben's design for the reset signal at least, using a D flipflop (I'd recommend getting some 74HC74s anyway, they are useful for all sorts of things) and that should ensure it stays asserted for at least one clock cycle. You'd wire the main clock (which causes the counters to tick up) into the DFF's clock input (possibly inverted if you need to change its phase) and the DFF's data input comes from /H800. The catch is, you might find you actually want /H799 instead for this... I haven't thought that through in depth.

Thank you Bill. What you have typed here has answered numerous questions I've been having. This little post has really taught me a lot.

Just as study/reference material: https://eater.net/vga



As George said, worrying is good. That is a good idea to help sync those comparators together. Here is my rebuttal to it though: Ben does it. Now, he is using NOT-NAND gates all over the place, but I don't see how that would be in effect any different than than what a '688 would produce. Heck, having the ability to tie that enable line to the clock is even MORE helpful, and I will research into applying that logic or not.

Ben also is using the async reset. Let me tell you why (answering George's last comment). When I was doing this breadboard thing, with the sync reset counters, I DID have to find /H799, and not /H800. As soon as I switched things over to 799, it was PERFECT. Sure, great, but Ben is doing this using 800 (rather his equivalent) with async reset. Ben's design is SO GOOD that he can sell kits for this stuff for over a hundred dollars. Wish I could do that! You get the point of my rebuttal: I'm following a working design, worrying or not. If you suggest me changing the those '688 chips into NOT-NAND style chips, I will do so in a heartbeat. Either design will fit on the printed board without issue.



Yes, again I was following ol' Ben here. I could easily tie those unused inputs to VCC though, and will do. And, thank you for answering my question, so I will not include some funny pull-down resistors on the color lines.



Yes yes yes indeed! I was running the scope on that horizontal reset, and it was EXACTLY as you said: short and spiky. It was never a clean square pulse, even with the sync resets. It would be not a blip on my scope, I zoom in and it's like a little valley thing, short and spiky. But it did do the job, as I did this exact counter setup on the breadboard minus the async resets.

I'm going to answer George's post now, thank you for this Bill, I appreciate the feedback a lot. If my rebuttal is incorrect, I do not mind being corrected!

Chad

Indeed!



It makes sense of course, but (like you stated below) will you then be seeking 799? Or 800? That's just the point here. The async resets can be handled at that exact value, and I *know* it will be at that exact value. I used 799 on my breadboard with sync resets, but does that mean I should on my printed board? Can I trust my data on the breadboard? That's why I'm going with Ben's style of async resets, because it's Ben, and he makes money on this very thing we are discussing



Right, that's the hard part here. I definitely get the use of the '74, and I'm all for it, but then I'm back to sync/async issues again. Should I go with the 799? Or the 800? My breadboard test says 799, but Ben says 800 (or his equivalent).

I'm all for 'safe and assured', but I'm even more for 'working'. George, I am listening to what you and Bill are saying, very much so! I'm also showing what Ben does and Ben's design works.

I am very welcoming of the comments, both of you, and thank you for them. I am listening, and will be applying this to the design. And I'll be thinking over the other stuff as well.

Thank you both very very much!

Chad

EDIT:

I want to see if my logic in using the async over the sync makes sense. I know the sync logic, wait until the next clock pulse so that everything is "in sync" literally. So here is my async logic:

I'm using /H800 here. When the counter ticks to the 800 mark (synchronously) it's sending that signal to it's respective 74HC688's P lines. That chip is receiving all of the counters at once (sync counters, no ripple. Ben actually uses a slight ripple in his counters not using the "Figure 2" we had previously discussed, but whatever). The '688 then does it's logic stuff with the already high and low signals on the Q lines, so the result should likewise be synced, but delayed by 15ns or whatever.

At that moment, the /H800 that was high is now low, and at the exact same time, it's sending that signal to the /MR horizontal counters, and the PC vertical counters. As soon as the low pulse hits the /MR line (async here), it resets it's counters to zero. It takes 20ns for this to happen (as per the datasheet). That's 35ns now, which is getting close to my 40ns max for the 25.175 MHz clock pulse.

At the same time, /H800 is also going to the CP line on the vertical counters. Funny thing is that it counts on the up tick, so at this point, it's doing nothing. It just waits for the reset line to go back to normal.

At the 35ns mark the horizontal counters are zero, and 15ns later the /H800 signal is gone. Now we are at 50ns. But by then, about the 40ns mark the clock has pulsed and we have the horizontal counters ticking after 7ns or something small. This would then be around the 47ns mark, which is just about when the 50ns /H800 goes back high and now the vertical counters start ticking, their signal is delayed by again 7ns or so. Thus we have horizontal at 47ns now showing a "1", and 57ns when the vertical also now shows a "1". Their timing is off.

So how does Ben do it? A 74HC04 has a delay of 9ns, and a 74HC30 has a delay of 12ns, adds up to 21ns, which is slower than my 74HC688. Ok, so same math:

H-counters uptick and send it's signal to the NOT-NAND logic, 21ns. /H800 is now low, goes to /MR which transitions using 20ns, now we are at 41ns, which is past my 40ns limit on my clock (but not on his 10 MHz clock, hm). So would that tick now not be counted? Or would it still count to "1" at this point? At the same time, 41ns plus the 21ns back through the NOT-NAND logic make 62ns, and now the vertical counters tick, and then more 7ns, leaving us at: Horizontal counter possibly ticked up to "1" at 47ns, maybe, and the vertical counters ticked up to "1" at 69ns, which is even more of a delay.

I think what's going on here is that the 25.175 MHz clock is too fast for async resets. So I'm forced into sync resets. The only other option is to have a separate divider counter that is not tied in with the other horizontal counters in the "Figure 2" method, but is stand-alone, and simply gives me a 12.5875 MHz frequency, which is good enough for me because I was going to to use 2x2 pixel 'blocks' anyways.

Thoughts? I'm seeing that you guys are right. Ben is also right, but at a lower frequency it basically is a null argument. Keeping with the 25.175 MHz clock would require me to use sync resets. That's my conclusion.

Thanks for sticking with me on this. I'm learning math (and I teach it!).

EDIT EDIT:

Attached is an altered schematic. I added a 74HC74. One half is a clock divider, the other half is for the horizontal sync signal. This freed up 2 NAND gates for my enable logic to make more sense.

Just an update, thank you all.

Chad,
By examining the delay numbers I think you've came to an understanding of synchronous reset vs asynchorons reset very well. There are multiple ways of getting 800 pixel per line. Ben Eater needs to explain the concept to newcomers so his implementation may be more expensive in order to have clarity. Since the '161 is loadable counter, you can imagine another method is preload 223 so 800 counts later it reaches 1023 where '161 generates a terminal count thus save a comparator. However, explaining that clearly may be more difficult. There are, in fact, compelling reason why you want to change the starting count and end count dynamically. This is one method of rolling image left or right or scrolling image up and down without changing the content of image memory.
Bill

One thing about that loading at 223: That actually is a great idea! The only problem is that Ben (and I) are using these counters not just for sync signals, but also to retrieve data from RAM/ROM. So I need the addresses to line up perfectly with the counters. I personally stop at 256x128 resolution, again convenient because of the counters. But if it were only for sync signals, then yes, start at 223!



Bill, it's like you read my mind this morning. Dynamically! I woke up at 3:00am with an idea: Why can't I do BOTH sync and async styles on the same board?!

So spent 2 hours just now making these little solder jumpers for the back end of the board. I can then manually solder each '688 comparator high and low, I can change the clock speed to full or half, and I can also change the '688 enables to GND or to the clock.

I will have to adjust this a bit because if I want 799 I need to have some solder jumpers available that I don't currently have here, but the idea is there. Because I'll get 5x boards printed automatically, and the '161 and '163 have the exact same pin configuration, I can try one style, if it doesn't work I'll try another style, etc. Small adjustments can be made with solderwick.

I just ran the auto-router and it seems to be ok with this, I will have to test it again later because I stopped it before it would finish.

There's the update, thank you Bill!

Chad

EDIT: The schematic PDF has been updated, I had to use two NAND gates to get the comparators to work with the ability to adjust the single digits too, darn. Oh well, there it is. Running auto-router now, it's struggling I love seeing computers having a hard time doing something. Maybe it's a psychology thing.