kp74615@nokikana.tut.fi (Karri Tapani Palovuori) (10/01/90)
Hi, I was reading the schematics of my B2000 and noticed that Denise only receives 7M (7.09379 MHz - it's PAL, pal) and C1 (3.546895 MHz) clocks. Are my schematics incomplete or does Denise indeed generate Hires clock internally? Does anybody have any suggestions for reading digital RGB (12-bit, from internal slots) _synchronously_? Hires? Karri
daveh@cbmvax.commodore.com (Dave Haynie) (10/03/90)
In article <1990Oct1.064514.27549@funet.fi> kp74615@nokikana.tut.fi (Karri Tapani Palovuori) writes: >I was reading the schematics of my B2000 and noticed that Denise >only receives 7M (7.09379 MHz - it's PAL, pal) and C1 (3.546895 >MHz) clocks. Are my schematics incomplete or does Denise indeed >generate Hires clock internally? Look again. Pin 34 of Denise gets CDAC*, which is another 7.09379MHz clock, leading 7M by 90 degrees. >Does anybody have any suggestions for reading digital RGB >(12-bit, from internal slots) _synchronously_? Hires? That is kind of a magic trick. The RBG signals can be clocked synchronously, the problem is that there's no built in clock that'll clock them. So you have to make your own. Or something like that. Outta my league, I'm not the video slot expert. Hedley Davis could explain how "Hedley Hires" monitors achieve this magic, though he doesn't read news all that much. If you're desparate, you might try email to hedley@cbmvax.commodore.com. There are probably one or two other people in the world who know this trick :-)... >Karri -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
tell@oscar.cs.unc.edu (Stephen Tell) (10/08/90)
In article <14813@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1990Oct1.064514.27549@funet.fi> kp74615@nokikana.tut.fi (Karri Tapani Palovuori) writes: .... [stuff deleted] >>Does anybody have any suggestions for reading digital RGB >>(12-bit, from internal slots) _synchronously_? Hires? > >That is kind of a magic trick. The RBG signals can be clocked synchronously, >the problem is that there's no built in clock that'll clock them. So you have >to make your own. Or something like that. Outta my league, I'm not the video >slot expert. Hedley Davis could explain how "Hedley Hires" monitors achieve >this magic, though he doesn't read news all that much. If you're desparate, >you might try email to hedley@cbmvax.commodore.com. There are probably one or >two other people in the world who know this trick :-)... > >>Karri >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Well, let me take a stab in the dark. I've never seen schematics for any any devices that do this (hedley monitor and I suppose the flickerfixer as well) nor even examined the boards real closely, but it seems that the way to do it is with that magic circuit, the phase-locked loop. Take the 12 bits of RGB, and somehow generate a signal that indicates whenever any of them change, perhaps differentiating all of them and OR-ing the results or just XORing all of them together. Ideally, the resulting signal will be a proper clock; the ideal case will come out if no adjacent pixels ever have the same color. Since we can't count on the ideal case but we know that one of the frequency components of this signal will be the desired clock and phase, we feed this into a phase-locked loop. We already know the desired clock frequency; that becomes the free-running VCO frequency. You probably want to use a crystal-controlled VCO (VCXO) for stability. Probably use a fairly narrow capture range in designing the low pass filter. If the screen is all the same color, the PLL has nothing to lock too, but that's OK since it won't matter where you sample anyway in this case. With a good PLL design, only a few actual transitions over the screen should be needed to lock the thing in. Now, a different approach. There is probably a clock of the right frequency somewhere in the Amiga, or one can be generated from the 28.63Mhz master clock (8 times color burst for NTSC, right?). If you genlock the system, you've got this clock on the video-slot board since you generated it yourself. The only problem is that we don't know the absolute phase of the pixel clock devided down from the master clock. Devide the clock yourself to the right frequency. Then, use a device called a programmable delay line to tweak the phase. These are a long multi-tapped delay line, with 7 bits or so of binary input that select the delay in increments of 0.5 or 1 nanosecond. You would need a circuit that selected the delay number based on transitions of the digital RGB, but once you had a good number, you wouldn't need to change it. In some respects this is like a PLL, but it is different in that it can't cope with variations in frequency, only in phase. The device to set the delay number is essentialy a phase comparator with a digital output; not sure how you'd implement that. There. Two methods. Now go build us some more video toys! Anyone want to suggest if either of these methods would work, or if anyone uses them? Disclaimer: I'm not real good at this analog / frequency domain stuff. -------------------------------------------------------------------- Steve Tell e-mail: tell@wsmail.cs.unc.edu usmail: #5L Estes Park apts CS Grad Student, UNC Chapel Hill. Carrboro NC 27510 Former electrical engineering student, Duke University, Durham, NC