| 00:30.00 | *** join/#edev dijenerate (~dijenerat@196.3.221.33) |
| 00:45.46 | *** join/#edev kergoth__ (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 01:59.59 | *** join/#edev purl (~purl@rikers.org) |
| 01:59.59 | *** topic/#edev is Discussion of embedded systems (Hardware/Software/Linux/WinCE/Commercial Device Repurposing) : Busybox and Buildroot : http://www.elinux.org |
| 02:41.58 | *** join/#edev djerome (~djerome@ip24-251-138-141.ph.ph.cox.net) |
| 03:10.10 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 04:17.24 | *** join/#edev dijenerate (~dijenerat@204.212.240.159) |
| 04:37.30 | *** join/#edev TemporalBeing (~bmeyer@cpe-098-122-058-217.sc.res.rr.com) |
| 04:59.54 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 05:06.00 | *** join/#edev NullMoogle (NullMoogle@cpe-69-205-123-203.rochester.res.rr.com) |
| 05:13.24 | *** join/#edev CcSsNET (~ccssnet@c-98-216-138-179.hsd1.ma.comcast.net) |
| 05:25.21 | *** join/#edev mbuf (~user@nat/redhat/x-rqtotubhuoayzmul) |
| 06:20.29 | *** join/#edev amarsman (~marsman@89.184.175.76) |
| 06:29.04 | *** join/#edev pepsi_ (mork@unaffiliated/jbutera) |
| 07:10.15 | *** join/#edev gvandenbosch (~gvandenbo@86.81.67.223) |
| 07:14.46 | *** join/#edev florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 07:14.46 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 07:46.27 | *** join/#edev clio (~andrej@85.159.109.222) |
| 08:28.56 | *** join/#edev avinashhm (~avinash-h@192.91.66.189) |
| 09:04.26 | *** join/#edev mnemoc (~amery@shell.opensde.net) |
| 09:43.02 | *** join/#edev CcSs (~ccssnet@c-98-216-138-179.hsd1.ma.comcast.net) |
| 09:46.11 | *** join/#edev balister_ (~balister@pool-74-107-168-228.ronkva.east.verizon.net) |
| 09:46.30 | *** join/#edev krushia_ (~krushia@h69-131-92-179.cntcnh.dsl.dynamic.tds.net) |
| 10:05.32 | *** join/#edev causticsand (~quassel@pool-71-114-243-164.austtx.dsl-w.verizon.net) |
| 10:06.03 | *** join/#edev causticsand (~quassel@pool-71-114-243-164.austtx.dsl-w.verizon.net) |
| 10:14.17 | *** join/#edev causticsand (~quassel@pool-71-114-243-164.austtx.dsl-w.verizon.net) |
| 10:16.19 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 10:38.06 | *** join/#edev n17ikh (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) |
| 11:58.37 | *** join/#edev n17ikh (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) |
| 12:20.33 | *** join/#edev clio (~andrej@85.159.109.222) |
| 12:30.37 | *** join/#edev devilsadvocate (~quassel@109.200.19.188) |
| 12:32.14 | *** join/#edev amarsman (~marsman@89.184.175.76) |
| 13:22.59 | *** join/#edev avinashhm (~avinash-h@192.94.92.11) |
| 14:02.11 | *** join/#edev kergoth (~kergoth@ip24-251-173-232.ph.ph.cox.net) |
| 14:58.39 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-rbgpuhaoymwrgbla) |
| 15:18.45 | *** join/#edev sndcrb (~sndcrb@gprs-prointernet-ff1a6a00-210.dhcp.inet.fi) |
| 15:45.22 | *** join/#edev prpplague^2 (~prpplague@ppp-70-242-126-3.dsl.rcsntx.swbell.net) |
| 15:57.07 | *** join/#edev prpplague (~danders@nat/ti/x-ohawsfmvgeidvilb) |
| 17:11.27 | *** join/#edev jayabharath (~jayabhara@nat/ti/x-nktbfjujqorubwiv) |
| 17:50.38 | *** join/#edev NullMoogleCable (NullMoogle@cpe-69-205-123-203.rochester.res.rr.com) |
| 18:48.02 | *** join/#edev florian (~fuchs@sign-4d094ea7.pool.mediaWays.net) |
| 18:48.02 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 19:40.09 | *** join/#edev dijenerate (~dijenerat@196.3.221.33) |
| 20:47.18 | *** join/#edev sndcrb (~sndcrb@gprs-prointernet-ff1a6a00-210.dhcp.inet.fi) |
| 20:56.22 | *** join/#edev dijenerate (~dijenerat@65.48.169.112) |
| 21:51.12 | *** join/#edev DeM0nFiRe (~kvirc@71-87-215-127.dhcp.oxfr.ma.charter.com) |
| 21:51.15 | DeM0nFiRe | Hello |
| 22:07.35 | DeM0nFiRe | I'm wondering if anyone here has done anything using the AD723 or AD725 RGB to NTSC/PAL encoders and can kind of give me an overview of what inputs it needs |
| 23:01.19 | SpeedEvil | Analog RGB |
| 23:01.37 | SpeedEvil | Seperate RGB components in, PAL/NTSC out |
| 23:05.47 | DeM0nFiRe | Oh yeah |
| 23:06.06 | DeM0nFiRe | Yeah I am, aware of that, I am just trying to figure out the timing inputs, and also the format of the color data |
| 23:06.19 | DeM0nFiRe | I mean I know it's analog RGB on seperate channels |
| 23:06.40 | SpeedEvil | Your input data needs to be synced to normal PAL or NTSC |
| 23:06.41 | DeM0nFiRe | But for doing resolution, is it just like send each "pixel" for [total cycles per line]/[pixelsperline] cycles? |
| 23:06.56 | SpeedEvil | It is just a converter for colours. |
| 23:07.10 | madsy | The resolution depends on the frequency of the signal |
| 23:07.24 | SpeedEvil | There is no real resolution in PAL or NTSC |
| 23:07.44 | madsy | The more bandwidth you have, the higher the resolution |
| 23:07.54 | SpeedEvil | Other than you can't really get much more than 4MHz. |
| 23:07.58 | madsy | Which is why both color and high resolution is a bitch on AVR |
| 23:08.30 | DeM0nFiRe | Right, I am not using those, I am using something that's higher clock, and I am using the AD723 for the color so I should be good |
| 23:08.34 | MonMotha | The AD725 is easy to use. Just feed it RGB video with timings suitable for your selected TV standard |
| 23:08.47 | MonMotha | out comes NTSC or PAL modulated video (depending on your selection) |
| 23:09.09 | MonMotha | you can also do some oddball stuff like run 50Hz (generally PAL region) timings with NTSC color modulation or vice versa |
| 23:09.36 | DeM0nFiRe | But what I mean is the NTSC has a certain amount of time per horizontal line, and then a hsync signal, and then a period of time for blanking |
| 23:09.40 | SpeedEvil | DeM0nFiRe: You absolutely need to run at 15625Hz/50Hz or whatever for NTSC |
| 23:09.44 | SpeedEvil | DeM0nFiRe: yes. |
| 23:09.57 | SpeedEvil | DeM0nFiRe: you do _all_ of that in your video card or whatever is generating the signal. |
| 23:10.06 | SpeedEvil | This chip does exactly none of that sort of thing. |
| 23:10.11 | DeM0nFiRe | So the size of a "pixel" is determined by what % of the total signal it makes up, no? |
| 23:10.28 | SpeedEvil | No. |
| 23:10.30 | DeM0nFiRe | Yeah I know that's why I am asking question about the timing so I know how to do it :D |
| 23:10.33 | SpeedEvil | There are no pixels |
| 23:10.37 | MonMotha | SpeedEvil: TVs are more forgiving than you might think :) |
| 23:10.45 | SpeedEvil | Exactly - modulo a bit then |
| 23:10.50 | SpeedEvil | To be standard PAL. |
| 23:11.01 | MonMotha | as long as you feed it something that's ~15kHz and 60ish Hz (or 50ish for Europe), it'll usually work |
| 23:11.14 | SpeedEvil | The timings are as you read on format documents of NTSC or PAL |
| 23:11.22 | MonMotha | many European TVs can apparently take 60Hz timings, too. That's less common on American TVs, especially newer digital sets. |
| 23:11.40 | MonMotha | you also need to make sure there's enough blanking, but again most TVs aren't overly picky |
| 23:11.43 | SpeedEvil | If you have a luminance bandwidth of over 4MHz or so, you will get reduction. |
| 23:11.52 | MonMotha | just go grab the "official" timings and use that, if possible, though |
| 23:11.53 | SpeedEvil | Err - bandwidth limitation |
| 23:12.19 | MonMotha | and yes, if you're using composite video, be aware that you don't get more than ~3-3.5MHz of luma bandwidth in NTSC land, a little more in PAL land |
| 23:12.20 | SpeedEvil | MonMotha: I know that's the case with 'normal' TVs - I'm unsure what happens on later CRTs with framebuffers on the input, or LCD |
| 23:12.46 | DeM0nFiRe | Well I've seen the timing numbers I just don't know how to do them, and then also I haven't seen anything on how to position the color data horizontally |
| 23:12.49 | MonMotha | SpeedEvil: they're generally forgiving as to everything except scanrates. They still need to be "60ish" refresh and "15kHz ish" horizontal |
| 23:13.12 | SpeedEvil | DeM0nFiRe: The color data is just RGB input |
| 23:13.25 | MonMotha | DeM0nFiRe: you don't need to "position" anything. The converter just blindly converts colorspaces (RGB to YUV) and modulates the chroma signal |
| 23:13.36 | MonMotha | it'll actually work at non-standard resolutions, but most TVs won't accept it |
| 23:13.37 | SpeedEvil | DeM0nFiRe: You have a pixel 10us after the start of a line, and it'll be about 15% into the left of the tube |
| 23:14.02 | DeM0nFiRe | Heh maybe I am not wording what I am asking right |
| 23:14.17 | SpeedEvil | And if it's 200 lines after the start of the picture, it'll be most of the way down. |
| 23:14.23 | SpeedEvil | (interleaving) |
| 23:15.07 | DeM0nFiRe | So the actual color data for a whole line is a stream of voltage (well, 3 streams, L I and Q, or in my case RGB because the AD does the color conversion) |
| 23:15.24 | SpeedEvil | yes |
| 23:15.28 | MonMotha | that's correct |
| 23:15.36 | SpeedEvil | The time encodes where it is in the picture. |
| 23:15.40 | MonMotha | it works just like a computer monitor, only you're limited in what timings you can send |
| 23:15.42 | SpeedEvil | Well - the time relative to the syncs. |
| 23:15.49 | DeM0nFiRe | So say y is the voltage at time t on a graph of that line data |
| 23:16.20 | SpeedEvil | Look at how a CRT makes up a picture. |
| 23:16.23 | DeM0nFiRe | To get a certain color at a specific place in the line, you have to start that data at a particular t and then move to the next color at a particular t, right? |
| 23:16.29 | SpeedEvil | No. |
| 23:16.39 | SpeedEvil | You always need to output all the pixels in the frame sequentially |
| 23:16.43 | SpeedEvil | you have no choice. |
| 23:16.51 | SpeedEvil | If you omit pixels, you get black bits. |
| 23:17.18 | DeM0nFiRe | No what I mean |
| 23:17.19 | SpeedEvil | You have to output all the pixels in a row, at a couple of megahertz rate or so. |
| 23:17.31 | DeM0nFiRe | I know I have to output the entire line at once |
| 23:17.46 | SpeedEvil | Not at once - in sequence left to right |
| 23:17.52 | SpeedEvil | followed by the next line. |
| 23:17.54 | DeM0nFiRe | Right sorry that's what I meant |
| 23:19.23 | DeM0nFiRe | Heh trying to describe what I mean |
| 23:20.06 | DeM0nFiRe | But I mean, say your output was 4 pixels wide (just a stupid example) each "pixel" would take up 1/4th of the total stream for the line, right? |
| 23:20.12 | SpeedEvil | yes |
| 23:20.23 | DeM0nFiRe | Ok that's what I was asking :P |
| 23:20.30 | SpeedEvil | You can do that with a normal TV |
| 23:20.43 | SpeedEvil | It's just you only get 4 pixels horizontally, and several hundred vertically. |
| 23:20.43 | MonMotha | the monitor has no idea how many pixels are on each line |
| 23:20.52 | SpeedEvil | It does ease the timing considereably! |
| 23:20.55 | MonMotha | it only knows how many lines there are, and how fast they come out |
| 23:20.58 | DeM0nFiRe | Haha |
| 23:21.28 | DeM0nFiRe | Well I am not going to do that lol I am going to do 320 x 240 and double the width of every pixel in the output and then output black around the edges |
| 23:22.06 | DeM0nFiRe | That also makes timing easier because the interleave stuff is easier since the even line would be the same as the odd line that comes next (assuming 0-indexed lines) |
| 23:22.27 | SpeedEvil | Odd line comes next half-frame |
| 23:22.39 | DeM0nFiRe | Yeah, I meant physically not on the time line |
| 23:22.45 | SpeedEvil | it goes (for a 5 line screen) 13524 |
| 23:22.49 | MonMotha | many TVs will happily accept progressive video |
| 23:22.51 | SpeedEvil | indeed |
| 23:22.54 | MonMotha | (~240 lines) |
| 23:22.56 | SpeedEvil | I'd probably say most |
| 23:22.59 | MonMotha | yup |
| 23:23.06 | MonMotha | some treat it interlaced no matter what and look all jumpy |
| 23:23.13 | MonMotha | but most seem to happily accept progressive |
| 23:23.13 | SpeedEvil | Worst case, you may get it a bit jumpy |
| 23:23.18 | DeM0nFiRe | Well, every TV that takes NTSC input will understand the interlaced right? |
| 23:23.20 | MonMotha | many consoles in fact output progressive video, especilaly older ones |
| 23:23.29 | MonMotha | oh yes, all TVs will accept interlaced video |
| 23:23.45 | MonMotha | (~480 visible lines) |
| 23:23.56 | SpeedEvil | NTSC and PAL are bioth interlaced standards |
| 23:23.56 | MonMotha | note those line counts are for 60Hz refresh (NTSC land) |
| 23:24.03 | DeM0nFiRe | Yeah I figure it's a little more work, but not too much more work since each half frame is the same as each other, and it will ensure maximum compat with TVs |
| 23:24.28 | DeM0nFiRe | Yeah I will have to learn the other timings and such as well later |
| 23:24.31 | DeM0nFiRe | but NTSC is fine for now |
| 23:24.55 | DeM0nFiRe | Right now I am just looking to do a prototype with one MCU and the AD723 just to get something working |
| 23:25.02 | DeM0nFiRe | And for that just NTSC is fine |
| 23:25.27 | DeM0nFiRe | If it works out, I will look at making a more powerful version with 2 boards (one for video and one for everything else) and I will look at doing more formats |
| 23:26.14 | DeM0nFiRe | Ok so the stuff that comes before the color data on a line |
| 23:26.35 | DeM0nFiRe | Is that something that the AD723 does? I think so but I am not sure |
| 23:26.40 | MonMotha | the biggest issue with being compatible with both NTSC and PAL (using the customarily associated 60 and 50Hz timings, respectively - note that there are a few countries that historically used PAL at 60Hz or NTSC at 50Hz) is the difference in color subcarrier freuency |
| 23:26.59 | DeM0nFiRe | MonMotha: Yes, the AD723 actually takes care of that |
| 23:27.14 | DeM0nFiRe | As well as for PAL M and Combination N so I've got most of the world covered on that :P |
| 23:28.09 | DeM0nFiRe | I will just have to adjust the timing of the data, which I figure once I learn it on NTSC the rest should be quite doable |
| 23:28.18 | MonMotha | DeM0nFiRe: you still have to feed it the proper color subcarrier frequency, which means you probably need two oscillators |
| 23:28.19 | DeM0nFiRe | Considering the AD723 does the hard work |
| 23:28.34 | MonMotha | and then adjust the timing of your video, yes |
| 23:28.37 | DeM0nFiRe | That would be the 4SCF clock I believe |
| 23:28.41 | MonMotha | correct |
| 23:28.51 | DeM0nFiRe | So that's the next thing I am confused about |
| 23:28.51 | MonMotha | 14.31818MHz for NTSC or ...something else for PAL |
| 23:28.55 | MonMotha | I don't have that one memorized :) |
| 23:29.36 | DeM0nFiRe | Right, it's 14 and some odd Mhz for NTSC, the board I am using is 72mhz, which divide the two it ends up being that the CSF is 1/5.02 of the board's clock |
| 23:29.56 | DeM0nFiRe | So is doing it as 1/5 within tolerable error for that? |
| 23:30.03 | MonMotha | probably not |
| 23:30.34 | MonMotha | most TVs are pretty picky, and the number is chosen to be such a weird number in order to make lots of stuff work otherwise (note that "proper" NTSC isn't actually 60Hz but 59.94Hz) |
| 23:30.41 | SpeedEvil | The datasheet should have a specification for the frequency standard. |
| 23:30.46 | DeM0nFiRe | Yeah |
| 23:30.54 | SpeedEvil | Probably a few hundred ppm. |
| 23:32.25 | MonMotha | it's fairly tight |
| 23:35.35 | DeM0nFiRe | So you think the difference between one pulse for every 5 in 72 million and one in every 5.02 in 72 million is too much? |
| 23:37.32 | DeM0nFiRe | Ok so that's the issue I am having now then, I mean I am not going to find a board that is a nice multiple of either NTSC or PAL CSF |
| 23:37.51 | DeM0nFiRe | So how do I work around that? |
| 23:37.56 | MonMotha | you're talking about 14.4MHz vs 14.31818MHz |
| 23:38.00 | MonMotha | That's a fair bit of error |
| 23:38.21 | DeM0nFiRe | Oh, yeah I see what you mean |
| 23:38.28 | MonMotha | About 0.5% |
| 23:38.32 | DeM0nFiRe | Yeah |
| 23:38.47 | MonMotha | I'd just grab a "crystal in a can" TTL oscillator |
| 23:38.51 | MonMotha | 14.31818MHz out |
| 23:38.58 | MonMotha | you can get them at whatever logic level you need |
| 23:40.14 | DeM0nFiRe | Ok, so if you can't tell I am new to working with hardware like this, so how exactly would this oscillator work. I assume I have to send it power somehow, does that come VIA a signal from the MCU or do you just apply a direct power line and it does it or what? |
| 23:46.58 | MonMotha | they usually have 3 connections: power, ground, and output |
| 23:47.13 | MonMotha | apply power (specified voltage), hook up ground, and you've got the clock output to feed into your AD723 |
| 23:47.21 | MonMotha | some also have an enable line |
| 23:47.25 | MonMotha | which is just a logic input |
| 23:47.53 | DeM0nFiRe | Some of these appear to be customizable, so I guess that 4th line would be for enable and frequency? |
| 23:48.15 | DeM0nFiRe | http://www.vanlong.com/download/PO300F.pdf like this |
| 23:48.21 | *** join/#edev dijenerate (~dijenerat@72.51.101.57) |
| 23:49.18 | DeM0nFiRe | Oh never mind |
| 23:49.28 | DeM0nFiRe | That is just saying that you can order them in those frequencies, huh? |
| 23:49.39 | DeM0nFiRe | You tell them what frequency you want |
| 23:50.13 | DeM0nFiRe | Wow, thanks for the help guys, this stuff is so much clearer now than before I came in :D |
| 23:50.25 | DeM0nFiRe | Still not 100% sure on this, though |
| 23:54.47 | DeM0nFiRe | Ok, so then |
| 23:55.24 | DeM0nFiRe | do the 4FCS on an oscillator and do the timing for the color, hsync and vsnc in software on the board? |