5 ms·

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 no

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!

pkiller 8y 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 8y 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 8y 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.jpg 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.
cushychicken 8y ago
No pesky compliance issues eating into your precious timing margins...

pkiller 8y 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 8y 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 8y 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.jpg 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.

cushychicken 8y ago

No pesky compliance issues eating into your precious timing margins...