Prev: Converting Commodore tapes to TAP files
Next: USB chip
From: Joseph Fenn on 5 Oct 2006 16:58 On Thu, 5 Oct 2006 a7yvm109gf5d1(a)netzero.com wrote: > JohnH. wrote: >> I'm looking for a detailed description of the electrical >> characteristics of the C128s RGBI output. A friend of mine is an >> electronics engineer for Hamilton Beach. In an exchange of favors he >> has agreed to help me build a color interface between C128 80 column >> RGBI output and a modern flat panel monitor. > > It's just a 74LS245. > > Look here > > http://www.dfpresource.org/ > > How much longer can you wait? > >> I'm not sure if the output would be VGA, S-Video or component video >> at this point. The starting point is obviously a fundamental >> understanding of RGBI output. > > There's not that much to understand. There's a Hsynch, a Vsync and 4 > bits that describe the color of each pixel on a line. > >> In my web searches I recall seeing a document that went into the >> C128's RBI output in great detail showing voltage levels and timing. >> I can't find that web site again. I'm beginning to doubt my >> memory. Has anybody seen, or does anybody have a document like this? >> >> Thanks, >> John > > You're better off reading the specs on the timing of the VDC to > understand the signal. I just bought a 128 prg reference guide from > eBay to help me do just that, even though I already have a pretty > complete Compute's Gazette Mapping the 128 here. Electrically, there's > not much to it. TTL levels. > > The basic thing you're likely to need is a AL250 or AL251 chip. You can > then take the upscanned digital outputs to a DVI transmitter chip, or > be happy with analog VGA. The AL250 chips are like 10$ each in small > qties. > > There are some people in this group that insist that a device to > convert RGBI to VGA already exists made by Extron. This is false and > I'm still waiting for a picture of the working setup. The other person > thinks you can just program the VDC to output 31KHz Hsync when every > test I've made show the VDC stops at about 21KHz Hsync. Ignore these > people. > > Once you guys get it all figured out and working in 128 NTSC mode, Let Alan Bairstow and the UK group know how you did it as they have spent 2 years working on a box to do what you want in NTSC and feed it to VGA monitors. They suceeded with PAL but never made it yet with NTSC on the 128. They still working on that problem and the project is called Cbm=VGA. Joe
From: a7yvm109gf5d1 on 5 Oct 2006 17:12 Jukka Aho wrote: > a7yvm109gf5d1(a)netzero.com wrote: > > >> RGBI -> Component video would require the least work, so that's > > > I think you'll find that's completely untrue. I eagerly await a > > simple circuit to take 16MHz dot clock video and encode color > > unto a 3.58MHz colorburst. It's not trivial, not by a long shot. > > What are you on about? The previous poster talked about component video, > not composite video. Component video does not have a "colorburst". Composite: Composed of two or more parts. Component: Composed of seperate parts. S-video is a component system. Please describe how the color is encoded. I think I was talking only about s-video. If I got confused, sorry.
From: a7yvm109gf5d1 on 5 Oct 2006 17:23 Joseph Fenn wrote: > > > Once you guys get it all figured out and working in 128 NTSC mode, > Let Alan Bairstow and the UK group know how you did it as they have > spent 2 years working on a box to do what you want in NTSC and > feed it to VGA monitors. They suceeded with PAL but never made it > yet with NTSC on the 128. They still working on that problem and > the project is called Cbm=VGA. > Joe I don't understand the problem of his design. If it works on one sync rate, it should work on the other (in VGA). I have my own set of problems to worry about in my design. I am not sure exactly what his approach to the problem is. I suspect he dropped the project because he has more pressing things to do in his life, not because it's terribly hard to upscan RGBI to VGA. The stumbling block in my design is the clock recovery. At present, I am unable to get my microcontroller to ouput a PWM waveform that the genlock can use to recover the video clock. It should be easy, but the stupid thing is not switching to PWM mode, it's stuck in port I/O mode. I only need to do 3 things for the PWM mode to be enabled. 1) Chip configuration bits. 2) Port pin in output mode. 3) PWM mode selected. All this is done, and the PIC is still in I/O mode. The datasheet shows that if I do steps 1 and 3 properly, the port pin RB3 is no longer in I/O mode. However, I can change the pin in software... It's ridiculous.
From: a7yvm109gf5d1 on 5 Oct 2006 17:37 Jukka Aho wrote: > American-style component (YPbPr) signal? And why are you bringing > obsolete composite or s-video signals and their color burst timing > problems into this discussion at all when the original poster doesn't > even want to use a tv set but a flat-panel PC monitor? I believe if you check the recent threads it was very much a discussion about s-video! Sorry if I got on a soapbox about it... I guess I'm getting old, "component" still means s-video to me. I'll check my pills and from now on will think only in terms of YUV, which is as you say, a simple matrixing job. The main problem with that approach is that you are still driving a television at the end of the day. You will not have scan doubled video unless the TV does it, in which case you have to specify a model of TV to get your 80 column jollies instead of waiting for my (admittedly long) project to come to fruition. I don't think I know of any TV with that kind of processing that comes in a 14 inch desktop size. If you look at the LCD TVs that are out there, they are considerably more expensive than just a regular LCD monitor. I'm not sure how these LCD TVs handle their YUV inputs. My CRT Wega has a singularly horrible picture with all kinds of distortion so that's why I tend to stay away from TVs. I think that the amount of people in the situation of having a good enough TV to plug a 128 RGBI to is very low, but pretty much everyone has a VGA monitor or a TV with component, err, s-video inputs. No?
From: Jukka Aho on 5 Oct 2006 18:05
a7yvm109gf5d1(a)netzero.com wrote: >> What are you on about? The previous poster talked about component >> video, not composite video. Component video does not have a >> "colorburst". > Composite: Composed of two or more parts. > Component: Composed of seperate parts. S-video is a component system. > Please describe how the color is encoded. > > I think I was talking only about s-video. If I got confused, sorry. Now you're just being silly. As far as common video terminology usage goes, "component video" is generally only used for YPbPr, YUV, or YIQ signals. RGB, for example, is every bit as "component" as YPbPr, but it isn't usually called that in normal parlance. S-video is somewhere halfway between "component video" and "composite video" since it sends the luma part of the signal separately but both color components down the same wire (and requires a color burst as a reference for separating them from each other, which the "real" component video signal formats don't need.) MagerValp was referring to "Scart to component adapters" in his post. With no further clarification, it has to be assumed that by "component" he means YPbPr, since that's what people usually mean when they're talking about "component" in the context of discussing video signals. Here's one such adapter - much like the DIY device to which I linked in my previous post, but as a commercial product: <http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=280033473794> He might also have meant something like this... <http://www.tvcables.co.uk/cgi-bin/tvcables/PGV373.html> ....or something like this... <http://www.tvcables.co.uk/cgi-bin/tvcables/YUV-RGB-SCART.html> ....but if that was what he had in his mind, unfortunately, these latter two are only passive adapters. They don't convert signals; they just connect the RCA connectors to certain pins on the SCART connector. (They are intended for devices that can natively accept or send YPbPr "component" signal through a SCART socket. This is not a standard capability in SCART-equipped devices but has become more common in the recent years.) -- znark |