OK, here are a bunch of questions about C128 video that have been rattling around in my brain for awhile. I'm sure the answers are all probably an obvious 'no', but I'd like to try to understand why.

(1) Can you just add a switch to the NTSC/PAL pad on the C128 and flip your VIC from one mode to the other? If so, do you have to reboot or can you do it on the fly? (I thought I'd start out with an easy one for an expert, even though I certainly don't know the answer.)

(2) Why can't you just add a chip to divide the VIC clock by 1/2 when you go into FAST mode so you can keep the 40-column display? I know the VIC is still performing some functions in FAST mode, right? It's not completely turned off. (OK, I've thought about it and I know dividing the clock is a dumb idea. D'oh! But isn't there SOMETHING you can do? Something that the Commodore engineers thought of, but management nixed because it might add a dime to the cost of the machine?)

(3) How much work would it be to hack in an INTENSITY value for the VIC and/or the VDC? Adding a hack to change the whole screen permanently wouldn't be hard - you could do that with one resistor! But how about to change intensity by frame? By character row? By scan line? (By scanline, maybe an 8-bit D/A converter inserted into the intensity line, mapped into I/O space somewhere and updated during refresh?) By character block? By pixel? I'm sure each of these is possible, somehow, but how practical is each? Of course, I'm thinking ultimately of 16 colors at 256 displayable intensities for each pixel. :)

(4) Could you add a little daughter board - something like CLD's 64k video RAM expander - to enhance the VDC or VIC video capabilities? Like with the luminance thing above, or to add more available scanlines, or more pixels per line, or MORE COLORS (especially more colors), etc.

(5) As far as that goes, how about programming a CPLD to take the place of the VIC or VDC chips? Seems to me like this would be an easy way to add enhancements. I know there are some that come in 40-pin formats, and there are 40-pin adapters for the others.

That ought to be enough to spark some discussion! :)

Quote from: airship(4) Could you add a little daughter board - something like CLD's 64k video RAM expander - to enhance the VDC or VIC video capabilities? Like with the luminance thing above, or to add more available scanlines, or more pixels per line, or MORE COLORS (especially more colors), etc.

The second version of the Graphic Booster 128 was advertised as allowing 7200 out of 65000 colors at once.

The first version, as far as I can tell, was just a 64K VDC upgrade coupled with new BASIC commands for VDC programming. The ads claimed, though, that you could choose 2 colors out of 3000 in graphics mode or 16 colors out of 2000 in text mode. Seems doubtful to me, because after the 128 DCR came out with 64K VDC RAM standard, the Graphic Booster was rereleased as a simple ROM plus disk, and then simply a disk version with no ROM. So where were the extra colors coming from if special hardware wasn't needed?

8-Bit Nirvana has this little tidbit about the 'first version' of the board  (auto-translated from German by Google) - was there ever really a second version?:

http://tinyurl.com/yold9q

"The notorious graph IC booster... the plate and the wire to the extra Rome base are only masquerade, so that all bought the plate; -) The normal change on 64K VDC-RAM does it exactly the same."

So the board was simply a 64K video upgrade like the CLD board, and the jumper wire coming off of it was just deception, according to this guy. And everything else was just normal 64K VDC programming - if there is such a thing as 'normal' when it comes to the VDC.

Thanks. That pretty well confirms my own conclusions about it.

I don't know whether the second version really existed or was just more hype -- I suspect the latter. Probably just another deception to try and sell the same 64K upgrade and BASIC extension.

I can imagine a possible video extension which wouldn't require any internal modification. The standard RGBI output could be passed through a circuit which reinterprets the signal before passing it to the monitor. Each color cell can normally have only two colors, background and foreground. The circuit would take every two horizontal pixels and transform them into one by taking two thirds of the first color and one third of the second color.

QuoteBackground-Background = Background     (eg. 2/3 black plus 1/3 black = black)
Background-Foreground = 2/3 Background, 1/3 Foreground     (eg. 2/3 black plus 1/3 white = dark grey)
Foreground-Background = 2/3 Foreground, 1/3 Background    (eg 2/3 white plus 1/3 black = light grey)
Foreground-Foreground = Foreground     (eg. 2/3 white plus 1/3 white = white)

Horizontal resolution would be halved, so for instance a 640x200 screen would become 320x200, but each color cell could effectively be 4x2 and would have more tonal range.

One would certainly need a switch to turn this feature off and on, as it wouldn't be desirable all the time.

But of course, being very ignorant, it's easy for me to imagine things which might not even be possible to do. Perhaps one of the smarter people here could weigh in on it.

4) Nikoniko, that's a neat idea.  The only problem I see is aligning the bit pairs, and counting bits.  Counting bits would need access to the 16MHz dot clock so at least a small H/W mod would be needed.  With this, you could align bits by simply counting clocks; reset the counter every H sync.

Oh yeah, it sounds like the extra colors of the Graphics Booster is simply from dithering.

1) The different VICs have different internal timings.  Most importantly the number of cycles per raster.  Another reason a simple switch isn't possible is each runs from a different frequency master clock.

2)I don't know what the problem is!  You would think with double frequency the VIC could produce 640 horizontal resolution with 16 sprites!!  Of course you would need extra registers for extra sprites.  I think Commodore expected the VDC to be the answer and left us with VIC only for 64 compatibility.  Stupid!  The VDC has no sprites, or raster/sprite IRQ...  I will stop now before I really start ranting.

3)The VIC produces a composite output so it shouldn't be too much trouble to scale it giving intensity.  You'd need to be careful to return to normal intensity during the sync signals; this would be difficult because there is no seperate Sync line from the VIC.  Would be easier with the VDC in this case (it does have seperate sync) but you would probably want to scale all 3 RGB components seperately.

5)Good luck with that!  These chips are monsters.  Not only creating an image in real time, but also responsible for memory refresh.  The VIC has extra functions too like scanning the keyboard and stretching the clock for I/O access.  One of the few mods I would gladly pay lots of money for instead of do-it-myself.

Quote from: hydrophilic4) Nikoniko, that's a neat idea.  The only problem I see is aligning the bit pairs, and counting bits.  Counting bits would need access to the 16MHz dot clock so at least a small H/W mod would be needed.  With this, you could align bits by simply counting clocks; reset the counter every H sync.

Interesting. Would you mind going into that a little more? Why couldn't a device derive the correct timing from the video signal itself? After all, monitors do.

The monitors interpret it (the R,B,G components) as an analog signal -- at least in the time domain.  You need to get an ordered pair of 'bits' to do the color conversion.  I'm not saying its impossible without the dot clock, but it would be soooo much easier with it.

You could set-up a (internal) timer to start counting when it receives the h-sync to do bit alignment but this has two problems. 1) the internal count could could be off by 1 so that your bit pairs are backwards and since order is important in your scheme, the color would go wacko (a software setting could scroll the screen by 1 pixel to compensate but that requires user intervention).  More importantly 2) if your counter did not match the VDC dot clock exactly, there would be drift; the pixels could be fine at the start of the raster, crazy in the middle, and backwards at the end of the raster.  This is with only 1 pixel/raster error.  You're timer would need to be at least 1/2 pixel / raster accuracy or about 1/1300 accuracy.  0.07% is not impossible to achieve but would be difficult, I think.

I hope that makes some sense.  Another way to think about it is: how long (in time)is each bit/pixel?  What ever number you calculate, there is no gaurantee that any particular C128 will match exactly (in fact probably the opposite).  Even if the match is good at startup, the frequency / bit-time will drift with temperature and power fluctuations.  Maybe this drift wouldn't be enough to effect your device...

Edit
This is also related to what I said about the VIC.  The sync and luminance are provided from the same pin.  The sync could be extracted from this signal.  Use an analog comparitor for example.  Obviously this is possible (monitors do it), but is more trouble than a simple digital ciruit.

Quote from: hydrophilic1) the internal count could could be off by 1 so that your bit pairs are backwards and since order is important in your scheme, the color would go wacko

Yeah, that wouldn't be pretty. :tillfreds:

Hmm.

Well, assuming it were possible to tap the VDC's clock, I wonder how that could be communicated? Perhaps something could be rigged to transmit the necessary timing through the composite pin? (Assuming we don't care about giving it up.)

The dot clock goes straight to pin 2 on the VDC.  A driver with hi-impediance (sp?) could input from there and output to the VDC connector.  Composite pin is a good idea since your device wouldn't work with composite (or would it?!).  Another idea is pin 2 of the connector.  It is ground.  We already have a ground on pin 1, we don't need two!  Of course removing your device and plugging a monitor into the modded port might not like that!

Quote from: hydrophilicOf course removing your device and plugging a monitor into the modded port might not like that!

True. Then again, if the second ground or the composite pin, whichever one is used for the device, isn't important, an off switch on the device could not only turn off the video transformation but block the signalling from the repurposed pin. Aside from doing 80 column monochrome on a TV, does any actually use the composite?

I think I've realized a major snag, however. The monitor is only expecting the RGBI pins to signal 16 colors, right? So there there isn't actually be any way to send other colors... or is there? Will the monitor accept RGBI values that are not full off, full on, 0, 1 values?

Ooooh... the CGA monitor. I hadn't thought of that. From the 1902A schematics, it looks to me like inside the monitor the Intensity line might just be flipping 'on' and 'off' to select two levels. At least, there's a little 'square wave' icon in a little box, there right before the Intensity is mixed (via a resistor pair) with R, G, and B to go to the CRT guns.

I could be wrong, of course, and the odds are actually VERY good that I don't know what I'm talking about. But if it is the case that Intensity is just binary, then varying the intensity level wouldn't make any difference in the actual display unless you did a full conversion of the signal to RGBA and used a different monitor. Shucks.

But maybe you could still do it on the VIC side?

Quote from: airshipBut if it is the case that Intensity is just binary, then varying the intensity level wouldn't make any difference in the actual display unless you did a full conversion of the signal to RGBA and used a different monitor. Shucks.

That's an idea. RGBI to RGB is doable.

QuoteBut maybe you could still do it on the VIC side?

That could work as well, turning the 320x200 mode into a specialized 160x200 mode. Combined with FLI, you could have 4x1 color cells. Unlike true multicolor mode, you couldn't have 4 different VIC colors in one cell, but being able to do nice gradations between two colors could make for some nice pictures. The major snag there, and most likely a deal breaker, would be sprites -- you couldn't really use them since they'd screw up the colors of the background image. A VIC-II without sprites... yuck.

But how about this for some more senseless and ignorant brainstorming... could there be a way to add real hardware sprites to the VDC display? What I mean is not replacing the VDC, but combining its output with the output of a sprite generator of some sort, allowing sprites to be overlayed onto the video signal. Ideally, I'd hope the generator wouldn't be limited to 8 sprites per line -- a minimum of 16, or more if possible. Also, if the interface takes the RGBI input, translates it to Analog RGB, then does its overlay, sprites wouldn't have to be limited to the 16 VDC colors. We could perhaps expand into 256 color territory. Anyway, sprites would pretty well compensate for having no direct access to VDC video RAM.

How about a video mixer that would take a black-background VIC screen with sprites and use it as an overlay (with the black transparent, of course) to the 80-column screen? You could create a black-foreground mirror of the VDC screen on the VIC screen to give your sprites something to collide with (a technique I read about somewhere on this board - maybe even from you, nikoniko!). Then you could use standard sprite commands to move and detect real sprites on the 80-column VDC playfield. Sprites could even go behind objects on the VDC screen by simply going behind the black foreground mask on the VIC screen. And, of course, you could use all of the standard screen-interrupt stuff to increase the number of sprites, use different colors, etc.

Too bad it would only work in SLOW mode.

I think I'm describing a genlock here, aren't I? Except it would have to mix standard video with CGA, instead of video with video.

Great idea! Since the VIC already has sprite generation hardware, that would simplify the device considerably. Despite not offering any new capabilities over existing sprites, you'd have the great advantage of programming them exactly the same as one is used to, and could even use the various tricks that are so popular in demos. Plus, you'd have the satisfaction of using the VIC and VDC in a lovely collaborative relationship.

So... all you need is a circuit that would:

(1) Lock the VDC and VIC chips together so that they do vertical retrace, horizontal retrace and line scanning at absolutely the same times & rates,

(2) Time everything so that the VIC draws one pixel for every 2 drawn by the VDC (pixel stretching?),

(3) Display 2 VDC pixels anytime there is a black pixel coming from the VIC, and

(4) Mix the two signals for display on, what, S-VHS?

Piece of cake. :förvånad:

Hehe... I wonder how much of a bounty we'd have to raise for somebody to do all that?

Damnit, Commodore... I know we weren't supposed to use the VDC for anything but text, but you had to know people would want their sprites, too. I guess with the Amiga out at the same time, though, there wasn't much reason to develop the 128's capabilities into something more.

Maybe we could start with one of these?

But if you are using the VIC, you have to be running at 1mhz and that will pretty much make gaming on the VDC useless.

Why would it be useless? There are plenty of good games on the C64 running at 1MHz. Most of them I can't keep up with at that speed, much less twice as fast!

Though you couldn't run at 2 MHz, at least you'd have sprites on a hi-res VDC screen.

Because getting graphics data INTO the VDC is slow, even at 2mhz with the VIC turned off; I would imagine it would be needlessly slow with the VIC turned on.  So, what specifically would it buy you to be able to genlock VIC and VDC together?  I could possibly see a use of 80-column text with VIC multi-color images, but nothing that screams for a need for sprites.

Having said that, I'm sure some demo makers would LOVE to have this capability....

It's the standard answer, Payton: "Because it is there!"

And remember, you CAN switch on FAST mode during the horizontal and vertical refresh for about a 20% speed boost. So all is not lost.

Quote from: plbyrdBecause getting graphics data INTO the VDC is slow, even at 2mhz with the VIC turned off; I would imagine it would be needlessly slow with the VIC turned on.

2Mhz with the VIC turned off does increase performance some, but not enough to make up for the VDC itself. For anything more complex than block copy or fill, a graphically intensive program will spend so much time dealing with the VDC that any performance advantage of 2Mhz processor speed is lost. Where the VDC shines is its resolution, its excellent and easy scrolling capabilities, and quickly moving around blocks to whole byte boundaries. Being able to combine those advantages with hardware sprites would compensate for having to work in 1Mhz mode, as well as being much more pleasurable to program for.

That said, more realistically I expect that most methods of enhancing the 128's graphics capabilities, short of pure genius like Hydrophilic's interlace hack, would be too complex and too expensive to be practical.

However, maybe something like this would be suitable? Seems it would be less expensive and require less complicated hacking to get a 128 controlling it.

Quote from: nikoniko

Quote from: airship(4) Could you add a little daughter board - something like CLD's 64k video RAM expander - to enhance the VDC or VIC video capabilities? Like with the luminance thing above, or to add more available scanlines, or more pixels per line, or MORE COLORS (especially more colors), etc.

The second version of the Graphic Booster 128 was advertised as allowing 7200 out of 65000 colors at once.

The first version, as far as I can tell, was just a 64K VDC upgrade coupled with new BASIC commands for VDC programming. The ads claimed, though, that you could choose 2 colors out of 3000 in graphics mode or 16 colors out of 2000 in text mode. Seems doubtful to me, because after the 128 DCR came out with 64K VDC RAM standard, the Graphic Booster was rereleased as a simple ROM plus disk, and then simply a disk version with no ROM. So where were the extra colors coming from if special hardware wasn't needed?

The (theoretical) high number of possible colours on the screen is accessible via the fade-parameter and different patterns (mixing of the possible four colors: background / foreground for each of the two interlaced raster lines per color block). The colors are not the colour of one pixel! It is only the overall visual impression.

Fading (fade-parameter) is very strange. I think it is something like the hozizontal (de-)adjustment of a monitor with the h-sync poti. So you will "fade" the colour of the whole screen (by manipulation of one or some VDC register(s)). I didn't ever recognize this effect on a monitor. It is hardware depending may be it will work on a 1901 but not in VICE and not on a 1084.

The (software) difference between V1 and V2 of the Graphic Booster is the "optimization" of pattern-mixing / fading. The version avaliable on C128.net is V2 [evidence: the manual explains how to upgrade V1 programs to V2].

Regards WTE

A 64/128 Genlock.  That's sooooo cool.  I thought that was vaporware.  With that you have a lot of posibilities.  Like use the VDC for static/scrollable background, and use the VIC for sprites and background enhancment.  The biggest downside would be the Genlock only works on composite (just a guess!) so you'd have to use the VDC monochrome

I really liked nikoniko's idea for extra colors from the VDC (I always assumed it would output to VGA) but I was doing some unrelated programming last night and it hit me like a ton of bricks: the VDC output is only sync and colors so there is no way to detect which color is 'background' and which is 'foreground'  Well you could if you used only text mode.  Since the background is the same everywhere you could determing the background in an off-screen location, like a few rasters after v-sync.

Quote from: nikonikoHowever, maybe something like this would be suitable? Seems it would be less expensive and require less complicated hacking to get a 128 controlling it.

Oooh.  Another video controller.  Take multi-monitor apps to the 3rd degree

Quote from: wteFading (fade-parameter) is very strange. I think it is something like the hozizontal (de-)adjustment of a monitor with the h-sync poti.

I need to check into this VDC 'fade-parameter'.  I have no idea what that means...

Quote from: hydrophilicI really liked nikoniko's idea for extra colors from the VDC (I always assumed it would output to VGA) but I was doing some unrelated programming last night and it hit me like a ton of bricks: the VDC output is only sync and colors so there is no way to detect which color is 'background' and which is 'foreground'

Ah... you probably didn't see the update I had made to my earlier post to clarify the technique. The method doesn't need to know which color is background or foreground. You simply take 2/3 color of the first pixel and 1/3 of the second. That's it. I only used the words 'background' and 'foreground' out of habit. Regardless, seems the method wouldn't work unless you converted the signal to some other form such as analog RGB.