Comment by iheartpotatoes

8 years ago

Oh to built 20Mhz systems again! ... no picosecond timing skews to stress over, no ground plane worries, no trace-related design rule violations, no harmonic noise issues, no dynamic bus inversions to prevent victim/attacker degradation, no thermal issues... I spend so much time debugging GHz multi-layer circuit boards that I forget how "easy" 20MHz digital circuits can be. This guy's project is truly inspiring!

4 comments

iheartpotatoes

Reply
pkiller  8 years ago

Thank you :)

I would love to learn more and be able to work with faster circuits like you. Yes it's way easier to work with "slow" digital circuits I had very little issues using breadboards and really long wires, that probably look cringy to you and others.

  • iheartpotatoes  7 years ago

    Note I put "easy" in quotes because your project was by no means "easy", especially with no tools at your disposal but the internet!

    Can I ask how you incrementally tested the video circuit as you built it? Did you have a test pattern generator or something? I know very little about TV signals, I spent some time trying to wire up an analog camera and just ragequit because I lacked a good fundamental debug process.

    • pkiller  7 years ago

      I knew what you meant by "easy" and I agree.

      Well, I think it isn't that hard to get an analog video signal going. Having a TV that took an RGB analog signal, meant that I could connect the microcontroller directly to the TV (using resistors to convert the voltage and for the color DAC).

      Then all I did was get the timing right, especially with the sync signal. Along with other resources, I used this image ( http://martin.hinner.info/vga/pal_tv_diagram_non_interlace.j... ) to understand when to set the Sync signal to 0 or to 1. When using a microcontroller you can use interrupts or you can have well-timed instructions to set the sync signal on or off at the correct time, I chose the latter. The micros I used are AVR 8-bit architecture based, so most instructions always take 1 cycle, others take from 2 to 4 cycles to execute, simply by looking up in the manual I could calculate when certain instructions would execute and build a program in assembly that would generate the sync signal successfully. And if everything was right, my TV picture would switch to black, meaning it detected a valid PAL signal.

      Of course, it wasn't always this easy, for example, I had a bug when I started, I wasn't setting one of the registers correctly and it took me a day to solve it, I had to look at the code over and over until I figured out what was wrong. Not having an oscilloscope nor a logic analyzer certainly made it harder.

      Another lucky thing for me, was that the TV I have (an old CRT TV) is actually quite forgiving and even if I don't feed the timings exactly, it will still show a picture, so that helped.

      Once I had a valid signal going I tested sending pixels to the screen, and I did use patterns to see if I had the timing right for each pixel, if I took too long switching pixels they would get wide. So I tried some checker patterns and stuff like that, but nothing fancy. I hope this answers your question. It really isn't that difficult to generate a video signal and also I was quite lucky to get it working early on.

      I probably didn't do things like they should be done, but it worked for me. I would say that best thing is have a logic analyzer or oscilloscope to check if the signal you're generating corresponds to what it should be, that makes it a lot easier.