Has anyone checked out this circuit?
http://www.electronic-projects.net/Schematics/ScanConverter/scanconv_circuit.gif

It's based around three uPD42101 video ram buffers... One for R, one for 
G, and one for B.

There's a bunch of circuitry that can be left out, like the sync 
separators, color separator,  R G B ADC's. (The RAM's can be fed the 
digital signals via buffers hooked to the incoming R G B)

Anyone else think this is worth a shot?

-Urson Bear

It's a discrete design, therefore not worth your time. It extracts the
clock from the colorburst, so you'll have significant re-design anyways
if you want to use RGB. (ie where's your pixel-locked clock coming from
??)
It's for NTSC video, so you'll probably want to increase the horizontal
resolution.
Then you have the fact that you'd be using one or two bits out of each
memory chip.
Then there's the parts procurement fiasco.

a7yvm109gf5d1@netzero.com wrote:
> It's a discrete design, therefore not worth your time. It extracts the
> clock from the colorburst, so you'll have significant re-design anyways
> if you want to use RGB. (ie where's your pixel-locked clock coming from
> ??)
> It's for NTSC video, so you'll probably want to increase the horizontal
> resolution.
> Then you have the fact that you'd be using one or two bits out of each
> memory chip.
> Then there's the parts procurement fiasco.
> 

It seemed to be using a 3.5xxxx MHz crystal for initial clock timing, 
I'd have to look up the V7021 chip for what it does, and where the clock 
pulses go.
The horizontal scan frequency is 15.7xxx kHz, what's the freq for RGBI? 
All I've seen is "About" 16 kHz.
The circuit samples the screen 910 times per horizontal scan- the 
80-column screen has 640 pix (plus borders)  That might be tight, but 
it's fine for NTSC video.
...And the RGBI only outputs 16 colors, anyway. by linking the R/G/B to 
the lower 7 bits of the RAMS, the I can be linked to bit 7 of all RAMS, 
reproducing the color levels for RGBI output.

Whether THIS circuit is usable is moot- using the information in it, 
maybe the C-VGA guys could build something workable?

-Urson Bear

"Whether THIS circuit is usable is moot- using the information in it,
maybe the C-VGA guys could build something workable? "

Yup, you're right. This circuit looks like it's buffering a single line
of video and sending it out twice. I don't know how they handle
interlace, but it's a safe bet that this circuit doesn't do any motion
compensation at all.

As for the C-VGA guys, I think they do have something but I don't know
what their delay  is caused by.

I looked for the NEC FIFO part, and it's OBS-NLA as far as I can tell.

Sadly, the more I think about the RGBI scan-doubler, it looks like it
won't be an internal solution. There's just not enough space in the
video can, and the power supply is just right above it. Plus you can't
get the scan-doubled video out of there gracefully.

" The circuit samples the screen 910 times per horizontal scan- the
80-column screen has 640 pix (plus borders)  That might be tight, but
it's fine for NTSC video. "

Yeah I didn't look too much into the timing details here, 910 samples
at nyquist would be 455 sine waves per line, which works out to a 7MHz
video bandwidth.

" The horizontal scan frequency is 15.7xxx kHz, what's the freq for
RGBI?
All I've seen is "About" 16 kHz. "

I'm busting open my 128D tonight and measuring the basics. The DCLK is
16MHz and the CCLK is 8MHz is all I know right now. So much for doing
this stuff on the weekend, weather's too nice. AFAIK, RGBI hsync =
15.75KHz. After all, it displays on the same video monitors as the
128's VIC video.

"It seemed to be using a 3.5xxxx MHz crystal for initial clock timing,
I'd have to look up the V7021 chip for what it does, and where the
clock
pulses go."

Yeah, I'd guess this crystal is locked to the colorburst to allow
decoding of the color subcarrier.

" ..And the RGBI only outputs 16 colors, anyway. by linking the R/G/B
to
the lower 7 bits of the RAMS, the I can be linked to bit 7 of all RAMS,
reproducing the color levels for RGBI output. "
Why bother? Just use one chip for all 4 bits, it's not like they sell R
G or B versions of these chips. :) That's what I meant by my earlier
criticism, once you look at this circuit, you're throwing out 75% of
the stuff.

As for the colors themselves, I don't even have my 1080 hooked up to my
128D right now to check for this CGA "dark brown" color shift, this
color is created inside the IBM monitor. Does the 128D follow this
spec? Who knows?

Check the Wiki on CGA for more info.

"I'm busting open my 128D tonight and measuring the basics. The DCLK is
16MHz and the CCLK is 8MHz is all I know right now. S"
Oops, brain fart, the CCLK is 2MHz, that is the dot clock/8. 8 pixels
per character, I guess.

Anyways I just measured the H and V sync and it's 15750Hz and 60Hz, as
near as my frequency counter can tell. Those numers don't divide nicely
into 16000000Hz. As soon as I build a test jig I'll hook up the scope
to the VDC. I don't even have DIP test clips...

Papabear wrote:

> It seemed to be using a 3.5xxxx MHz crystal for initial clock timing, 
> I'd have to look up the V7021 chip for what it does, and where the clock 
> pulses go.

VDC has a 16 MHz pixel clock.

> The horizontal scan frequency is 15.7xxx kHz, what's the freq for RGBI? 
> All I've seen is "About" 16 kHz.

The VDC can output anything concerning horizontal/vertical frequencies. 
Also 30 KHz... or 50... etc.

John Selck wrote:
> Papabear wrote:
> 
>> It seemed to be using a 3.5xxxx MHz crystal for initial clock timing, 
>> I'd have to look up the V7021 chip for what it does, and where the 
>> clock pulses go.
> 
> VDC has a 16 MHz pixel clock.

Thanks, but I was discussing the scan converter's clock.
Plus, the pixel clock isn't very helpful when we're trying to sync the 
H-Syncs...

>> The horizontal scan frequency is 15.7xxx kHz, what's the freq for 
>> RGBI? All I've seen is "About" 16 kHz.
> 
> The VDC can output anything concerning horizontal/vertical frequencies. 
> Also 30 KHz... or 50... etc.

That's a pretty big claim. if the VDC can be knocked up to 30kHz H-Sync, 
we don't need a scan converter- just a DAC for the RGBI levels and a 
little register tweaking in the VDC. V-Sync is fine at 60Hz(U.S.)

I'll have to dig through the chip registers.

-Urson Bear

Papabear wrote:
> John Selck wrote:

>> The VDC can output anything concerning horizontal/vertical 
>> frequencies. Also 30 KHz... or 50... etc.
> 
> That's a pretty big claim.

Maybe, but it is true.

> if the VDC can be knocked up to 30kHz H-Sync, 
> we don't need a scan converter- just a DAC for the RGBI levels and a 
> little register tweaking in the VDC. V-Sync is fine at 60Hz(U.S.)

You could up the H-Sync to 30kHz by changing VDC registers 0 to 3. The 
problem is that the dot-clock remains the same; by doubling the 
horizontal sync rate the horizontal resolution is halved.