The video in the CoCo comes from the Motorola 6847 VDG. The VDG is configured by means of several digital signals on its external pins. The CoCo uses some of its PIA outputs and some clever wiring to control the VDG configuration.
The VDG offers a handful of video modes which can be grouped into 4 basic categories: 2-color "resolution" graphics modes; 4-color "color" graphics modes; 4- or 8-color (+ black) "semi-graphics" modes; and alphanumeric modes. In the CoCo and its cousins, the last two categories are combined using the clever wiring mentioned above. Also, one of the "resolution" graphics modes can be used to produce a different 4-color mode by means of NTSC "artifact" colors.
Resolution Graphics
I'm not sure why the VDG designers chose to use the term "resolution" graphics for the 2-color modes. I guess it's because these modes pack more on-screen pixel resolution into the same video buffer space as their 4-color counterparts.
Anyway, in these modes pixel values are encoded with one-bit per pixel, or eight pixels per byte. Any "0" bit values correspond to black. The "1" values correspond to either green or buff (i.e. almost white), depending on the value of the Color Set Select (CSS) configuration pin. This encoding is available in 128x64, 128x96, 128x192, and 256x192 resolutions. The last of those is really only available on black and white televisions due to "artifact" color effects on NTSC monitors.
NTSC Artifact Colors
The combination of the way the NTSC video system encodes color information and the common practice of combining Luma and Chroma signals together into a Composite video signal creates the possibility for certain anomalies when interpreting such video signals. In particular, the signal created by the 256x192 "resolution" graphics mode tricks a color television into producing 4-color pictures! The effective resolution of this mode then becomes 128x192.
The black/green color set produces drab, muddy greenish colors that usually aren't very useful. But the black/buff color set produces a black/white/orange/blue color set. The only real problem is that the encodings for the orange and blue colors (which use "01" and "10" bit encodings) are determined randomly at each boot (i.e. sometimes they use "10" and "01" instead). Most CoCo games that use this mode start with a title screen that asks for the player to reset the CoCo until the screen objects are the correct color.
Mapping images to this color set is not as horrific as it may sound -- the results are reasonably tolerable. The presence of black and white in this color set helps a lot, especially for the stark scenery of a "space shooter" game or something similar. This is probably the single most popular graphics mode for CoCo games, at least for the commercial-grade ones.
There are also some "artifact" colors that use wider and mult-line bit patterns. These modes rely on the nature of a CRT picture tube and not on the nature of the video signal itself. As such, they really don't work on LCD screens and often don't work on "newer" CRT televisions either. In reality, this form of "artifact" colors is really more similar to dithering than to anything else. Given these facts and the relatively poor state of documentation for the expanded set of "artifact" colors, I won't go into any real detail about them here.
Color Graphics
The "color" graphics modes encode color values with two bits per pixel, or four pixels per byte. Depending on the value of the CSS pin, these color values select a color from either a Green/Yellow/Blue/Red palette or a Buff/Cyan/Magenta/Orange one. This encoding is available in 64x64, 128x64, 128x96, and 128x192 resolutions.
In these modes, all of the pixels encoded in a single byte must come from either one of those color sets or the other. It is possible to have both color sets used on the same line, but that requires the CPU to actively change the value on the CSS pin at the correct times while the given line is being drawn on the screen -- tough! A somewhat easier task would be to use different color sets in different horizontal slices of the screen, but that approach does not lend itself well to common playfield layouts. In practice, most usage of these modes simply picks one color set or the other and sticks with it for the entire screen. Expanded use of the CSS pin usually just isn't worth the cost in CPU cycles.
(Note: the only commercial CoCo game known to have used this "on the fly" technique of modifying the CSS pin is Dragonfire.)
Alphanumeric/Semi-Graphics
The VDG has a 64-character set of alphanumerics built into it. These display with a dark (but not quite black) background and a foreground that is either green or orange depending on the CSS pin value. One of the configuration pins can cause these characters to be displayed "inverted", with black foregrounds and green or orange backgrounds. The normal CoCo text screens use black characters on a green background.
The VDG also offers two "semi-graphics" modes. These modes offer lower resolutions (64x32 or 64x48), but with more available colors (at least for SG4). Unfortunately, the colors are specified for groups of pixels rather than for individuals ones.
The Semi-Graphics 4 (SG4) mode divides a character-sized block into 4 pieces (2x2), and allows each piece to be specified as either black or as a single color common to the other colored pieces of that block. All eight colors (Green/Yellow/Blue/Red/Buff/Cyan/Magenta/Orange) are available for each character-sized block in this mode.
The Semi-Graphics 6 (SG6) mode divides a character-sized block into 6 pieces (2x3), and also allows for the blocks to be either black or a common color. This mode offers a choice between the same two 4-color sets as in the "color" graphics modes, with the CSS pin used in the same way to choose between them as in those modes.
The alphanumeric mode only needs six data bits for describing each character, and the SG4 mode only needs seven of them. In the CoCo, these facts are exploited to allow for switching between alphanumerics and SG4 characters automatically based on the data in the video buffer. The high order data bit is fed into the VDG pin that selects between alphanumerics and semi-graphics modes. The next highest order bit is fed into the VDG pin that inverts the alphanumeric character display. This allows for semi-graphics, inverted alphanumeric, and non-inverted alphanumeric characters to share the same display without any heroics from the CPU!
The SG6 mode is handicapped by all this cleverness. The bit used to select semi-graphics mode would normally be a color selection bit for the SG6 characters. But now for SG6 to be active at all then that bit must be a "1" -- this effectively limits the color choices to one of two (or one of four by switching the CSS pin value). The resulting diminished usefulness of the SG6 mode is probably no great sacrifice. In most cases the 64x64 "color" graphics mode is probably about as attractive as the SG6 mode anyway, considering both visual quality and resource usage. In any case, what is done is done and we must live with a crippled SG6 (or just ignore it).
SAM+VDG Semi-Graphics
As documented in the datasheet for the 6883 SAM, the combination of the SAM and the VDG allows for the creation of three new graphics modes based on the SG4 encodings! In fact, it can be used for a few more modes as well -- but the SG4-based ones are the most useful. :-)
By itself, the VDG handles its own memory addressing during video buffer reads. In order to share access to display memory between the VDG and the CPU, the VDG has an input that will force it to relinquish the memory bus to the CPU. However, unfortunate timing of that signal can result in video display glitches as the VDG is starved for information about what to display. A big part of the SAM's job is to coordinate between the VDG and the CPU in order to prevent such glitches. As part of that job, the SAM handles the video addressing on behalf of the VDG and the VDG's memory addressing pins are (mostly) ignored.
The SAM can monitor some of the VDG's output pins (including one of the memory addressing pins) in order to keep track of what part of the screen the VDG is drawing at any given time. But the SAM cannot determine everything it needs to know like this. So, part of the information used to configure the VDG must be used to configure the SAM as well. This is where opportunity rears its head!
The VDG normally re-reads the screen buffer twelve times for every line of alphanumeric/semi-graphics characters -- once for every physical screen line of those characters. When you configure the SAM and the VDG identically, then the SAM replicates this policy. But if the SAM is configured for a bigger display buffer, the effect is for the SAM to re-read the screen buffer fewer times before advancing to the next line of character data. This can double, triple, or sextuple the number of "characters" on the screen, while simultaneously reducing the height of each "character" to half, a third, or a sixth of the original character size. Using this technique with the SG4 encoding produces three new modes known as SG8 (64x64), SG12 (64x96), and SG24 (64x192). Just like SG4, each of these new modes allow for eight colors (and black) to be available on-screen at the same time!
Fahrfall's Graphics Mode
Perhaps ironically, the Color Computer is often criticized for its relative lack of on-screen colors and especially for the particular colors available. I can't do much about the latter, but I did want Fahrfall to demonstrate just how colorful the CoCo really can be. That narrowed the choice of video modes either to one of the SG4-based semi-graphics modes, or perhaps to one of the "color" graphics modes using well-timed CSS manipulations. The movement in the background of Fahrfall and the fact that the player object could be just about anywhere on the screen at any given time made the CSS manipulations seem impractical.
I also wanted to keep the game performance at an entertaining and playable level. Sure, everyone wants a nice "high resolution" display like the ones in the arcades. But the games in the arcades often had hardware assistance either for playing audio or for pushing video objects around the screen (or for both), whereas the CoCo only has the CPU to do those things. So the SG12 mode was chosen in hopes that its 96 lines would be more manageable than the 192 lines of an SG24 display.
From my experience with the CoCo3 Digital Video Player I learned that color resolution can be a good substitute for spatial resolution in graphics. Consequently, a 64x96x8 mode sounds like it is in the same ballpark as the 128x96x4 mode used in many CoCo games. The comments I have received about the Fahrfall videos posted so far seem to indicate that people think it looks alright. So, hopefully the SG12 mode is a good compromise between beauty and performance.
Phew!
Well, this one went longer than planned...I hope it was worth it! At least the CoCo hardware got a little more coverage, and I got to share my thought process for picking SG12 as the video mode for Fahrfall.
The weekend will be here soon -- wish me luck on finding some time to get a player object moving on the screen for Fahrfall... :-)
No comments:
Post a Comment