C=128 80Col NTSC Color.
in [Commodore]
|
Prev: C64 newbie
Next: Commodore 128D disk drive problems
From: a7yvm109gf5d1 on 27 Mar 2007 12:07 On Mar 26, 11:57 pm, Dopple <c...(a)comp.sys.cbm> wrote: > Could always jump into this like I jumped into making a batch of EZ232 and > Link232 interfaces. I bought enough parts in quantity, and am selling them for > $20 as a kit, and $30 assembled. > > Of course, you're looking at a lot more capital for a batch of these converters... > > BTW, I did buy one of the RGB to VGA converters fromwww.converters.tv. > > In a word: Sux0r. > > Problem is, they SAY it can do RGBI, but it can't. So, now I have to build a > RGBI to RGBA converter to feed to this thing. Hah. People say a lot of things about RGBI don't they?
From: Rick Balkins on 28 Mar 2007 09:57 Yes, the solution is pretty simple and intensity must ultimately be attached to the R,G and B lines. A quicky RGBI to RGBA converter is getting 3 DACs suitable for video. You send the syncs in for clocking. The DACs should be 2 bits resolution each. Intensity would be tied to each. EGA just took three seperate Intensity lines for each of the R,G and B lines. Getting you the 64 colors. Of course, after you get 15 KHz RGBA. The next step is scan doubling. Then you should have it viewable on VGA monitors. "Mangelore" <fotios(a)commodore128.org> wrote in message news:mn2Oh.2289$M.949(a)news-server.bigpond.net.au... > Dopple wrote: >> Could always jump into this like I jumped into making a batch of EZ232 >> and Link232 interfaces. I bought enough parts in quantity, and am >> selling them for $20 as a kit, and $30 assembled. >> >> Of course, you're looking at a lot more capital for a batch of these >> converters... >> >> BTW, I did buy one of the RGB to VGA converters from www.converters.tv. >> >> In a word: Sux0r. >> >> Problem is, they SAY it can do RGBI, but it can't. So, now I have to >> build a RGBI to RGBA converter to feed to this thing. >> >> -Jay >> > > It's very simple to integrate the Intensity signal. Just a few resistors > and diodes does the trick.
From: MagerValp on 30 Mar 2007 06:24 >>>>> "a" == a7yvm109gf5d1 <a7yvm109gf5d1(a)netzero.com> writes: a> It'll probably look like this, at best: a> http://upload.wikimedia.org/wikipedia/en/5/59/CGA_CompVsRGB_Text.png Yeah, RGBI to composite is a no-go. I haven't really followed the discussion, but isn't what we want RGBI to VGA? That can be done with (relatively) simple scandoubling. a> Now if only someone could tell me why I can't get the LUT to work a> on my project... My VGA output is purple, but it's sharp! (More or a> less!) a> http://dfpresource.org/VGA_noLUT.jpg That looks exactly like the DTV prototype that Jeri sent me for PAL testing. I don't remember exactly what the problem was, but it was related to the colour carrier inversion. You're not working with PAL though, are you? -- ___ . . . . . + . . o _|___|_ + . + . + . Per Olofsson, arkadspelare o-o . . . o + MagerValp(a)cling.gu.se - + + . http://www.cling.gu.se/~cl3polof/
From: Joseph Fenn on 30 Mar 2007 17:14 Which brings us all back to the start. CBM=VGA never came to pass by Alan Bairstow of U.K. who started the whole idea of useing these new LCD monitors for C128/C64s. He did suceed with the PAL version somehow but never with the NTSC they were trying to make work. Only the C128 was used never heard much feedback on the C64 Useage with LCD's. Joe ************************************************************************** * Ham since 1937 HiSchool Sophomore ex W9ZUU, KP4EX, W4FAG, KH6ARG KH6JF * * WW2 Vet since Sep 1940 to just After VJ day. US Signal Corps AACS * **************************************************************************
From: Rick Balkins on 31 Mar 2007 05:40
"Joseph Fenn" <jfenn(a)lava.net> wrote in message news:Pine.BSI.4.64.0703301110030.6722(a)malasada.lava.net... > Which brings us all back to the start. CBM=VGA never came to > pass by Alan Bairstow of U.K. who started the whole idea of > useing these new LCD monitors for C128/C64s. He did suceed > with the PAL version somehow but never with the NTSC they were > trying to make work. Only the C128 was used never heard much > feedback on the C64 Useage with LCD's. > Joe, Enough with this NTSC/PAL stuff. VDC is NEITHER NTSC or PAL. It is simply its own video architecture format. Basically, the VDC output is really just a digital output bus. It isn't much different then the Serial bus except that it is output only AND that it is a 4 bit bus and there is a couple of clock pins. Then the video hardware device (aka the monitor) then takes the 4 bits and converts it to analog R,G and B. The 4 digital bits are labeled, R(Red),G(Green),B(Blue) & I(Intensity). The monitor has a DAC board inside consisting of THREE 2-bit DACs. You might think that it will do 64 colors assuming that there is 6-Bits of DAC resolution (2Bit DAC+2Bit DAC+2Bit DAC = 6-BIT). You would only be HALF right. The problem is that the Intensity line (the 4th bit of the digital bits coming in) is tied to the high bit of all three DACs digital input. Ultimately the output becomes 3 analog signals of 2 states. If there was two more bits, then they could be intensity 2 and three or you can have the Intensity lines labeled Intensity-Red, Intensity-Green and Intensity-Blue. Then you would tie only one of the Intensity lines to each of the DACs. Each DAC would have seperate Intensity lines. Voila, you now got primitive EGA. If you want to go far enough, add 8-Bits from say the User Port + the one Intensity line built in, you now will have 9 Intensity Lines. 8 coming from the User Port. (You'll have some limits but that is another issue.) You can then add upgrade the DACs to 4 Bit DACs and add put 3 of the 9 "Intensity" lines + the digital "red" line to the digital input for DAC-"Red". The next 3 Intensity lines plus the digital "green" line to the DAC-"Green" and the last 3 Intensity lines plue the digital "blue" line to DAC-"Blue". (Here, I label the 3 Four-Bit DACs) Then they'll produce 3 analog signals with 16 levels of intensities. The CRT itself accepts three analog inputs for each of the three raster guns that produce red,green and blue raster beams which will mix by close proximity of the beams and that they come together to a point. Thus, giving you the colors you see. I over simplied the overall process of and omitted how the Hsync and Vsync lines comes into play. However, there are possible snags with the approach. Possible need of a buffer for the User Port input which will hold the bits as needed. You won't be making any changes in the bit values on the User Port sourced "Intensity" bits as the 1 intensity bit. However, luckily the Intensity bit and the R,G,B bits are changed and sent based on char clock rate and not dot clock. As you coud tell, the R,G,B,I lines are modified at 1 or 2 Mhz and buffered. I believe, you could only change the colors at char clock rate. That is video chip limits. Anyway, the RGBI is digital and has nothing to do with PAL or NTSC. The issue with C=VGA is TOTALLY not related. The issue is likely Composite video to RGB/RGBI conversion. The biggest issue was likely with decoding an NTSC video signal from the NTSC C64's VIC-II chip and making a clean analog RGB signal. A process may entail the digitizing of the NTSC signal into digital RGB bits at 24 Bit resolution. This is a decode analog color info and converting them to digital RGB at 24 Bit digital RGB. (Note: Intensity is not there as it is really meaningless - it is really just luminances of R,G and B anyway) Then it is converted to analog RGB and operating on a 31 Khz HSync - regardless of 50Hz or 60 Hz power cycle rate (VSync). NTSC or PAL is meaningless on the RGB side of things. The trouble was likely in converting & extracting the color info and converting them into RGB. PAL television video was probably easier to extract. Converting them into RGB. Typically involving some sort of LUT and choosing RGB values that represents the colors best. Like on VICE. The problem was probably in extraction of color info. I can't say for sure. I just hypothyzing. |