Analog upscan converter?

[ChaosAlchemyst]

Hey there,

I'm a relative newbie to the wide world of electronics, but as a little project to think about I was looking into how upscan converters for 15khz to 31khz RGB work and if I could build one myself for less then say, an XRBG2. In my research I came across this website: http://elm-chan.org/works/sc/report.html which has an old schematic design for this kind of circuit. It's pretty complex by my standards, but from what I can understand, It converts R,G,and B into digital, writes them into a line memory chip at 15khz on the write clock, then applies some kind of function to the 15khz signal to get 31khz and uses that to set the read clock. Basically it writes one scanline, and then reads it twice before converting the digital signal back to analog and going out to the 31khz viewing device.

I wanted to try and build one of these to see if I could make it work, but unfortunately several of the chips, specifically the line memory chips are no longer in production and not even sold on places like ebay. I brought the project up to one of my professors, and he said to just ditch all the old tech and go straight for something like an arduino or a microcontroller, write a program to double the scanlines and the H-frequency, and just use it as a simple all-in one device to do it for me.

Now, like I said, I'm still relatively new to all this stuff, but is something like he says possible? And if it is, will the output video quality be even half decent? I know these kinds of circuits can be picky sometimes from reading other's experience. I know that this kind of circuit is kind of redundant when compared with things like and XRGB2 or the OSSC, but I wanted to see if I could make it work myself to try and get a handle on some of the aspects ot dealing with these analog video signals.

Any input is welcomed and appreciated.

 

[PascalP]

I'm not familiair with it myself, but there is also this (affordable) device on the market, maybe you can find something on the components used and would this help you with your project?

http://arcadeforge.net/Scaler-and-Strike-Devices/cga2vga-Scaler-PCB::13.html

http://shmups.system11.org/viewtopic.php?f=6&t=35423

 

[twistedsymphony]

I'm a relative newbie to the wide world of electronics, but as a little project to think about I was looking into how upscan converters for 15khz to 31khz RGB work and if I could build one myself for less then say, an XRBG2. In my research I came across this website: elm-chan.org/works/sc/report.html which has an old schematic design for this kind of circuit. It's pretty complex by my standards, but from what I can understand, It converts R,G,and B into digital, writes them into a line memory chip at 15khz on the write clock, then applies some kind of function to the 15khz signal to get 31khz and uses that to set the read clock. Basically it writes one scanline, and then reads it twice before converting the digital signal back to analog and going out to the 31khz viewing device.

I wanted to try and build one of these to see if I could make it work, but unfortunately several of the chips, specifically the line memory chips are no longer in production and not even sold on places like ebay. I brought the project up to one of my professors, and he said to just ditch all the old tech and go straight for something like an arduino or a microcontroller, write a program to double the scanlines and the H-frequency, and just use it as a simple all-in one device to do it for me.

Now, like I said, I'm still relatively new to all this stuff, but is something like he says possible? And if it is, will the output video quality be even half decent? I know these kinds of circuits can be picky sometimes from reading other's experience.

Your thread titles is "Analog upscan converter" but none of what you've described here is analog.

What you're describing... reading a scan line, then repeating the line on the output. requires that you WAIT for the whole line to be read before you can output it. and in-fact in most cases (particularly with interlaced sources) because of the timing you can't just wait for one line you have to wait for the whole frame... and if you wait for the whole frame the you've already got 16ms of lag assuming the rest of your circuit design is 100% lag free. And now (hopefully) you understand why scaling adds lag.

I love the Arduino and the Pi but I wouldn't trust them to do this quickly enough... it would be a fun and interesting project but the end result would be ultimately too laggy gaming.

Another problem is that 15K covers well over 100 different resolutions.

if you're talking about 320x240p RGB upscale to 640x480p VGA then it's pretty cut and dry you need to double the vertical and horizontal pixels, and double the sync signals and call it a day. if you got the timing right you could probably

but lets talk 640x480i RGB upscaled to 640x480p VGA now that's a different beast because you have to read two lines and then interpolate the data between them to build a completely new line. and the horizontal resolution doesn't need to be doubled at all, but when you output it needs to be output at double speed.

Those are the "easy" cases. then you have weird resolutions like 328x224 or 400x232. These don't scale well, you can't just double them because the resultant resolution wont fall in the VGA spec and a number of modern TVs wont display them.

Here's a list of "common" MAME resolutions, and it's not even comprehensive: NON-CRT Displays that support 25K resolutions


If you want to do this project to learn more about video signals, then more power to you. if you're doing this because you're looking for a cheap alternative to one of the "good" scalers on the market I think you'll find that you need purpose built scaling chips to perform these operations quickly and at the end of the day there will be A LOT of work and little to no cost savings over buying one.

 

[ChaosAlchemyst]

Thanks for the info.

I guess that a better title for the project would be "Digital Upscan Converter for 15khs 320x240p RGB Signals"?

I guess to be more articulate, I should have mentioned that I was specifically focused on converting 240p RGB to 480p RGB. And I already own an XRBG2, but I just wanted to try it myself as a project that seemed interesting. I figured that it probably wouldn't be of the same quality as something like the XRGB line.

What you're describing... reading a scan line, then repeating the line on the output. requires that you WAIT for the whole line to be read before you can output it. and in-fact in most cases (particularly with interlaced sources) because of the timing you can't just wait for one line you have to wait for the whole frame... and if you wait for the whole frame the you've already got 16ms of lag assuming the rest of your circuit design is 100% lag free.

What kind of delay would there be if each line was converted/doubled on the fly, instead of waiting for a full frame to be written? I'm pretty sure sure that it is possible in some cases, considering the setup of the circuit shown in the link on my first post. Ideally It would write each of the R, G, and B lines into memory and read/output each line twice before writing another line into memory, meaning that in a perfect world, the amount of time to double the lines would only delay by the amount of time to write one scanline, correct? I'm not sure If I missed anything.

Also, would a microcrontroller that had higher clock speeds than an arduino be able to handle the on-the-fly conversion more efficiently/without lag?

Thanks for helping out with this.

 

[twistedsymphony]

What kind of delay would there be if each line was converted/doubled on the fly, instead of waiting for a full frame to be written?

you can figure this out with math... you know the refresh rates and how many pixels there are in an image... that's all you need to figure it out.

would a microcrontroller that had higher clock speeds than an arduino be able to handle the on-the-fly conversion more efficiently/without lag?

again... simple math. can tell you how fast you need to be able to calculate the line.

in general though what you're describing is a software scaler, since the scaling operation is being done in the code that runs on your MCU. "good" scalers do this in purpose built hardware. you could throw a faster MCU at it but a lot of it will come down to how efficient your code is. and for really efficient code you'll want to be working in Assembly, not Arduino-C, but even with a really fast MCU and really effecient code you wont hold a candle to the speed of a hardware scaler.

 

[ChaosAlchemyst]

Thanks for the response.

It looks like I have some homework to do on this if I do end up deciding to try out this project. I appreciate the corrections and help with my relatively limited understanding of the field.

 

[Muf]

converting 240p RGB to 480p RGB

480p is outside the RGB spec once you have 480p it's VGA... by definition VGA means 640x480 with a 31KHz horizontal refresh rate, once you move beyond a 25KHz horizontal refresh then you're no longer talking RGB.

I understand what you're trying to say but the way you're saying it is horribly, totally wrong. VGA is RGB, and the sync rate of the signal doesn't stop it from being RGB. Please don't confuse people when it's already a technical subject.

 

[twistedsymphony]

I understand what you're trying to say but the way you're saying it is horribly, totally wrong. VGA is RGB, and the sync rate of the signal doesn't stop it from being RGB. Please don't confuse people when it's already a technical subject.

480p is outside the 15KHz spec once you have 480p it's VGA... by definition VGA means 640x480 with a 31KHz horizontal refresh rate.

Is that better?

I realize that by it's technical definition "RGB" is a video transmission spec and "VGA" defines a resolution. But typically once you go beyond 25K people stop referring to it as "RGB"; I was using the colloquial definition of "RGB".

 

[Muf]

Is that better?

One of the problems with that terminology is that technically VGA refers strictly to 31KHz 0.7vpp RGB over separate H/V TTL sync, and whatever line count isn't even specified; 400 lines at 70Hz (adds up to 31KHz) is just as much VGA as 480 lines at 60Hz, and the former is actually "standard" VGA as an IBM PC would normally drive it; the CRT phosphors are optimised for 70Hz and that's why 60Hz appears to flicker on a VGA monitor. Mode 13h (320x200 on a planar 8-bit paletted buffer at 70Hz) is line doubled to 400 lines in the graphics card. 800x600 and anything higher technically isn't VGA any more, but it is still transmitted through the same connector and signalling standard because of the mess that was IBM PC "compatibles" in the 80s and 90s. What I'm trying to say is you're opening a can of worms that you really don't want to open.

RGB on the other hand simply refers to the colour space used, and this can cover 15KHz, 31KHz, 85KHz, 0.7vpp, TTL level, analogue, digital (CGA), TTL sync or 1vpp sync, H/V separate or composite sync, etc etc etc. So using the generic terminology won't get you in trouble (where with "trouble" I mean people getting confused about what you're trying to say). Arcade RGB is 15, 25 or even 31KHz analogue at TTL level (3-5vpp) with TTL composite sync. SCART RGB (sometimes referred to as RGBs in the console world) is 15KHz analogue at 0.7vpp with 1vpp composite sync. And so on. You can use these shorthand terms so you don't have to specify the exact details of each parameter, but assuming "RGB" to mean any kind of standard is a recipe for confusion.

Additionally, since analogue RGB is analogue, there is no horizontal pixel clock in the signal (you have to guess it, which is why there are clever circuits for that in LCD monitors) and technically when you're doubling lines you don't need to double pixels. So a scan doubler like OP is describing would just output 320x480 and assuming the horizontal clock/phase is correctly guessed from the input signal, the output from said device would look identical to a horizontally doubled signal. Things like that are more important when designing scan doubler hardware than what abbreviation to use.

As for OP's original question, I think these kind of circuits are normally written in VHDL/Verilog for an FPGA/CPLD, with out-of-the-box cheap chinese solutions favouring ASICs that introduce a bunch of lag. I have no idea if any of the popular microcontrollers are fast enough to do the same in software. Someone like invzim should be able to shine light onto that subject.

 

[twistedsymphony]

when you're doubling lines you don't need to double pixels. So a scan doubler like OP is describing would just output 320x480 and assuming the horizontal clock/phase is correctly guessed from the input signal, the output from said device would look identical to a horizontally doubled signal

that's pretty clever