I hooked it up and hit the button, it said that it "passed". I didn't see anything else on the screen really, so...?

I hooked it up to the oscillator and got a sine wave. It was not square. Again, could be a lot of things going on there. I get square waves from EEPROM and further counters and stuff. The slower the signal, the more square it is. The faster it is (as in 25.175 MHz, or any of the signals from the first counter), it looks less like a square wave, more like a sine wave.

Well, I did get some money for Christmas, so I guess $30 probes with free shipping isn't too bad. Dying to have an EEPROM programmer though, ugh. Programming that 28C256 yesterday took about 30 minutes using the Raspberry Pi and my little breadboard circuit.

Chad

I looked up TDS1002 manual and it has a "auto set" button (top right) so you can hook up your probe to the 1KHz output and press "auto set". It should automatically calibrate and display a square 1KHz wave. Since you are seeing 25.175MHz (not surprised at sine wave because of uncompensated probe), your scope should be OK.

I sent off 6 board designs to JLCPCB yesterday, one of them is the 6502-based EPROM programmer. I should receive the boards back around New Year, so I'll send you a board when it is all checked out. I know it can program SST39SF010 EPROM and I believe it should program 28C256 as well. It is only software, haha! (It is what we said to the software weenies when they give us hardware guys hard time.)
Bill

Square waves contain only odd harmonics, so to see 25MHz as a square, you need 25MHz, 75MHz, 125MHz, ... A 60MHz scope isn't going to see much past the fundamental, so you should expect to see a sine wave.



The slower it is, the lower its harmonics are. That means the scope can see more of them, and will be able to show you more of the shape. It's working as it should.

The higher the frequency, the more work you have to do in interpreting what you're seeing. In your position, I'd use the higher speed clock as a "good, that's there", and devise tests that only use slower signals (10MHz or below) for checking the details.

I did the auto set button, and boom, a beautiful 1k square wave. Cleanest I've seen on this machine. Thank you.

Excited about the programmer! I can pay you for sure.

Thank you John West, sounds good.

I was thinking about this all night (of course) and this morning I put a pull-up resistor on the reset line. Nothing new. I added capacitors and all that too, nothing new. I have an idea to use the '163 as a 4-bit edge triggered latch, but that's not my issue at the moment, pretty sure.

I noticed that the 1k square wave was basically just two solid lines when I zoom in a lot (for a horizontal sync signal). So although there's a ton of static, and two lines on top and bottom, I'm not going to worry as much about it.

Whelp more wonky readings this morning. I'll send pics of the scope and the schematic sometime soon. Thank you all.

Chad

A latch is probably ok so long as you send it a short enough load pulse, at the right time in the cycle. You can also use a 74HC74 if you have one, at least for the reset signals. Some people get away without the latching at all, but that never worked well for me, possibly because I used a mixture of counter types.

Most of my VGA development was done without a fast enough oscilloscope too - I used multimeters with frequency/duty cycle readings, and monitors that told me what frequency they were seeing. Another trick is to unhook your clock and instead drive it slowly from an Arduino or similar, to check the outputs for each clock tick, make sure the total number of ticks before reset is correct, etc. It can give you confidence that the circuit is working at least at a low speed. But it's all much easier with a decent scope!

Chad,
You have a working scope, great! Productivity is proportional to the quality of tools; your scope is a great tool.

My guess is the scope has self-calibrating capability with the help of the 1KHz square generator, so you need to calibrate (auto set) probe on each channel whenever you've changed the physical probe. This means your existing coaxial cable probes can be auto compensated to work correctly--that's the good news, but the bad news is the capacitive and resistive loading are still there. This is where the 10X probes can help you reducing the loading by a factor of 10.

You need to spent some time playing with your scope. Learn to use external trigger to set the starting time and use the two channels to examine signal relative to the starting time. Reset is the obvious starting time and horizontal sync and vertical sync are two signals to observe. Use the "single seq" feature to observe one event instead of the continuously triggered event. There is a reason why the "run/stop" button is located at upper right corner--it is about the most used button on your scope.

Horizontal sync and vertical sync MUST be stable; jitters and glitches will cause your monitor not to lock.

Bill

Thank you George. I don't have a 74HC74 on hand, but I did use 3 NAND gate chips to generate a reset signal. And it works VERY nicely! More on that in a second.

Thank you Bill. I will see about that external trigger thing. I have been using the scope all morning and I am MUCH more comfortable with it now. I basically know what I'm doing, minus some cool features like you are mentioning.

So! I made a reset signal with the NAND gates I had on hand. It went perfectly. A ton of jitter was gone from my EEPROM signals after that, so I was able to read the horizontal and vertical syncs without any issues on the scope.

The horizontal I *think* is ok with it's timing. I can't zero in perfectly yet with the scope, but it's round-about timing was very close to what I expected. If it was off, it was not by much.

The vertical was where I expected it, but for some reason it does a double-jump thing instead of staying low. I kept seeing the same thing, like it wanted to be only pulsed at the correct timing, instead of being held low for 2 lines.

Since I was finally getting a clean signal on everything now, my conclusion was the EEPROM is not programmed right. I did it with my little Pi + breadboard, and generally it's worked, but I never programmed all 32K before. Hm.

Off to reprogram it now! I had already switched that breadboard over as well. After an hour of "why isn't this working", I found I flipped the latches /OE signal. Opps. After that I got readings from my EEPROM as I expected. Except... it wasn't incrementing. I spent probably 2 hours probing this darn thing. Everything is connected fine, I rearranged some logic to make it cleaner, etc etc. Nothing. I thought I fried my Pi, nope.

I went to eat breakfast, had another idea, tried it, failed. But then I was fumbling around with the probe wires and suddenly stuff changed! I jiggled the wires on the breadboard, and a ton of correct data came pouring through. Not permanently, I couldn't hold the wires in a way to make it work or something. Nope, it only works if I jiggle it constantly. So perhaps the washing machine is my next idea... (har har)

Conclusion: Breadboards suck. So hit and miss for me. Expect me to solder this 3 chip Pi Programmer soon. Then we'll see if the VGA stuff works finally or I might just solder that too.

*sigh*

I learned a lot about the scopes and probes, and I learned a valuable lesson. That's good enough for this morning. More updates later, thank you everyone!

Chad

Arg!

So I did an inventory of what I had, found a ton of 74HC00 chips, so I decided to try a real Ben Eater style sync generator.

Attached is a schematic that I did this afternoon. I then put that on a board. It barely fits. Wires are a mess, it's like doing surgery.

The reset signals are great, timing looks great, everything is great. EXCEPT the SR-Latches!

Also attached are the two timed signals going into the SR-Latch for the horizontal sync. I don't have a third probe, so I can't show the results, but the results are a flat line. One side is always high, the other side is always low.

Clearly the signals look fine, and because they are alternating, it should trigger the latch to change in one way or another! I did notice a little blip on the other channel when it should trigger, I zoomed in to show. Could that little blip stop it from triggering?? I added capacitors nearby, same results.

I can't do this any more today, but tomorrow I have an idea to use a 74HC193 counter as a 'latch' by setting one line to enable load a zero, and the other to the clock up, having my h-sync line on the Q0 or whatever. Silly as heck, but if this SR Latch ain't working, what other options do I have? I figured this SR Latch thing was super easy...

Anyways! There's the update. Thanks everyone.

Chad

EDIT: I now realize my "VISIBLE" tag is off on the logic. But those SR Latches are just frustrating me! Grrr. I'll do some more testing tomorrow.

The glitches in one signal when another signal changes state quickly are the kinds of thing decoupling capacitors can help with. One signal changing causes extra current draw through the IC that outputs it, and without a local decoupling capacitor this leads to drops in VCC (or rises in the ground level) going to other ICs that then cause echo-like effects on other signals. Adding a 0.1u ceramic capacitor to the IC that is switching state may help, as well as considering where your probe ground connections are located, as not all grounds are the same level.

For the kind of circuit you have there though, these glitches can also be due to race conditions between different counter output bits going through chains of logic gates, arriving with sightly different delays. It is tricky to get these kinds of things right and again sampling at a specific time after the logic has had a chance to settle has worked best for me.

However, if signal 1 is high and signal 2 is low, then the NAND pair's output should definitely be different to when signal 2 is low and signal 1 is high - regardless of what happens at the transition points. It's odd if you don't observe that. Your scope traces show low periods of around 1us I think which should be plenty long enough to observe the output changing, even if it didn't latch properly due to the glitches in the transitions.

I'm going to address all three really:

1) I added some capacitors nearby, and it did "help" a bit. The blip got a little smaller in magnitude, though not by much. This was with those capacitors added.

2) Indeed, there are multiple things going on at different times. I figured most of the inputs to the signals are fairly slow, being in the hundreds generally. I do see solid signals, for goodly amounts of times, and at the right times as far as I can tell (except anything past an SR latch).

3) I looked at my configuration about a hundred times this evening. I just keep thinking, "Surely I just put a wire in the wrong place." or "Surely I just didn't power the chip or something." I have looked and looked, and see nothing wrong.

I can simplify some of these signals with AND gates that I have, so I will probably replace any NAND -> NOT with AND tomorrow. That might give me some room to use a '193 as a "latch", and see if that works. Who knows. It's very frustrating being so close here, and yet a very simple SR latch is holding me back.

Btw, I'm doing it this way because my EEPROM programmer is busted, so if the ROM has incorrect signals on it I can't change it at this point. I was going to solder a new one but decided to try this again. And maybe even tomorrow.

Thanks George.

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?

Very correct Garth. I remember reading that post a bit ago. And I should have listened to you, breadboards are not the way to do this sort of thing.

Oh and I figured out why the SR latch wasn't working. Super easy solution: The chip wasn't seated at all! It had popped off the breadboard!

Update:

Since about 3:00am I've been re-writing the logic side of things on the breadboard. I used some AND gates and it significantly reduced chip count, good! I tested as I went, checking everything.

My horizontal sync signal was coming in just a bit shy of what the specs say. So I altered a bit of logic to reset/clock one pixel earlier. The scope said a dead-on 31.468kHz. I couldn't get any more exact than that.

I then went to my vertical sync, and it was double the frequency needed, 120 Hz almost exactly. Why? One of the '163 counters on the vertical side was counting like each clock was two clock ticks. I don't know why, capacitors didn't help. Whatever, I shifted all of the output lines over one, and I got a dead-on 60 Hz. Wish I would have taken a picture.

At this point the monitor is doing nothing at all, not even black. It's just it's "self test" whatever. The menu doesn't work at all. I figured it was missing pixel data. So I told it to display 1 pixel somewhere in the middle of the screen. While doing so some chips pop off the board. And then some wires. I redo stuff, I put things back. Nothing is displaying. I go back to check and the vertical sync is now saying 30 Hz. ARG. I *just* shifted everything over to accommodate for that weird timer, now it's working properly???

It's the breadboard's fault.

So I took off the VGA connection wires, I took off the probe wires, I took off the power wires, and then I threw the breadboard over my shoulder. It is literally trash to me at this point. I'll recover the chips later.

If I ever get the smart idea to use a breadboard again in my life, slap me.

Onwards: How do you guys normally prototype (without breadboards)? I can solder onto perfboard, but I switch so many wires (probably again because breadboard's fault) that it doesn't seem practical to solder right up front. Any ideas are welcome. A "better" breadboard sounds fine at face value, but I'm put off from these things for now.

Thanks everyone, so close, yet I was never close to begin with.

Chad

Were you using some decent breadboard, or some Chinese 2$ stuff? The difference is huge, like.. huge!

I think with this sort of nested logic you need to be careful driving anything asynchronous from it, which would be upset by random spikes here and there, but it will work better if you can ensure that whatever "reads" the output of the logic network only does so when it's had time to settle since the last input change, e.g. on the next clock.


If you have an Arduino Nano or Raspberry Pi Pico then you might be interested in https://github.com/gfoot/nanoprom or https://github.com/gfoot/picoprom - which allow you to program EEPROMs without needing any extra glue components. The disadvantage to these is that they can't read back from the EEPROM to check the programming, but they worked very well in general when I was developing them, and Nanos and Picos are very cheap.

Well, if you say so. I had two different boards from two different places, and two different price ranges. One was this super sturdy one from Radio Shack, had knobs on the top and a nice big metal plate on the bottom. Seemed high quality, it felt like high quality plugging things in. Problem is, when I jiggle wires, everything changes.

The second one I have is bigger, cheaper, but not $2 for sure.

You can mark it up to just a cheap board, but I've had a really bad run on two of them now. I didn't use a breadboard for my 6502 design, and it went pretty well (I switched two wires, all the rest worked). So perhaps I just gotta "do it", and start soldering like I did that one time. And if it doesn't work, try again.

George, my counters are all 74HC163's which are sync'd to the clock. But thinking back, that's probably why I had to reset the horizontal at 799 pixels because of that synchronous behavior of the reset. Ben Eater uses the exact time because he is using 74HC161's, which have an async reset.

As for the programmers, that's pretty neat! I have a regular Raspberry Pi, and I was using latches to triple-up on the data bus line on the GPIO pins. It works fine, but it's a pain to set up because the Pi needs it's own monitor and power source and a keyboard, and then I have to plug it into the breadboard. It's just unwieldy. Bill (plasmo) has been working on a EPROM programmer board, and I intend on using that when he's ready.

Thanks.

Chad