The 1980 Radio Shack Color Computer (and the Color Computer 2 revisions) used a Motorola MC6847 Video Display Generator chip. This video chip was used in a variety of other systems, and one can easily recognize it by its 32×16 text mode characters with the square letter “O”. I recently spotted it in a YouTube video by Atari Archives discussing the Atari VCS Hangman cartridge (see 5:04 if this direct link doesn’t work):
I was unfamiliar with the AFP Imagination Machine mentioned in the video, but CoCo Crew co-host John Linville confirmed it indeed used the same CoCo VDG chip. The “nuclear green” background color and blocky low-resolution “semigraphics” do stand out.
I also stumbled upon it in a list of unreleased Atari products. A company named Unitronics was planning an Atari VCS Expander System that would allow loading games from a built-in tape deck. In a screen shot for the device (which looked like a cassette player that plugged into the top of the Atari), the nuclear green CoCo screen can be clearly seen:
The screenshot in the first picture appears similar to that of Radio Shacks’ Color Computer – same color scheme and maximum of 32 characters per line.http://www.ataricompendium.com/game_library/unreleased/unreleased.html
And, there was even going to be a conversion of the 1980 CoCo ROM-Pak Space Assault and a screen shot was used of the CoCo version
The screenshot shown in a brochure for the Expander System (picture #1) is actually the Radio Shack Color Computer game Space Assault (picture #2). The game was licensed to Tandy by Image Producers Inc. in 1981. Perhaps Unitronics was going to license the game for the Expander. If the game shown in the brochure is actually running on the Expander, that would mean the Expander used the same graphics chip as the CoCo – the MC6847 VDG chip.http://www.ataricompendium.com/game_library/unreleased/unreleased.html
Until recently, I had no idea anything but the Radio Shack CoCo and MC-10s, as well as the UK’s Dragon computers (and, I guess, the French MC-10 clone, Alice) used the VDG chip.
64x32x8 … technically.
Ignoring using solid color character blocks in the 32×16 text mode, the lowest resolution graphics mode in the VDG was a 64×32 mode that could use 8 colors plus black. It did this by dividing each text block of the 32×16 text screen into a 2×2 graphics character. They weren’t true pixels, but instead where just characters made with all possible 2×2 variations in eight different colors. You could PRINT them using CHR$:
This reminds me of how the Commodore VIC-20 worked with its extended PETSCII character set, but instead of all the weird lines and shapes and card suit symbols, it was 2×2 graphics blocks with different colors. Much like the standard VIC-20 text mode, each text position could only contain one color plus black. Thus, while you could have eight colors on the screen, you could never have more than one color (plus black) in a character’s 2×2 block.
Rendering graphics in this mode was tricky, since you could not have more than a single color (plus black) in any 2×2 block.
In BASIC, you could set the top left pixel to yellow using:
…but you would see it would change all the other pixels in the 2×2 block to black:
And if you tried to set two pixels side-by-side to different colors:
…it would turn any other set pixel in that 2×2 block to the new color:
I am sure I learned this limitation when I first started playing with a CoCo in Radio Shack back in 1982.
Because of this “all pixels must be the same color” effect of the SET command, doing a random pixel plotting program…
0 REM 64x32.bas 10 POKE 65495,0:CLS 0 20 SET(RND(64)-1,RND(32)-1,RND(8)-1) 30 GOTO 20
…starts out as you might expect…
…but after awhile, every pixel has been set so new sets will change everything in that 2×2 block to the same color:
I know I wrote this program at that Radio Shack ;-)
Black is not a color
The early “Getting Started With Color BASIC” manual that came with the CoCo described the SET() command as being able to use the following colors:
- 0 – black
- 1 – green
- 2 – yellow
- 3 – blue
- 4 – red
- 5 – buff
- 6 – cyan
- 7 – magenta
- 8 – orange
But that manual was a bit incorrect. While you can try to SET(x,y,0), you won’t get black. The SET() command treats 0 and 1 as the same green color.
In fact, from what I can see, there is no way to set just a black pixel on the green text screen other than setting all the other pixels in that 2×2 block to the background screen green (color 1).
0 REM setblack.bas 10 CLS 20 SET(1,0,1):SET(0,1,1):SET(1,1,1) 30 GOTO 30
I guess the SET() command was really designed to work on a black screen (CLS 0). In fact, when viewing the Color BASIC disassembly in the “Color BASIC Unravelled” book, I even see it checks for this specifically:
CHANGE COLOR NUMBERS FROM 0-8 TO (-1 TO 7) BRANCH IF SET(X,Y,0)
It looks like they could have allowed it to support this, based on how the code checks what’s in the character initially. Maybe it was an oversight, or maybe it was just a lack of ROM space.
Regardless of the reason … I recently wanted to draw a black pixel on the green screen, and found doing so quite challenging.
The “draw black” challenge
Given a clear txt screen (CLS without any color), create a BASIC subroutine starting at line 100 that will plot a single black pixel using variable X and Y. Basically, make it act as if SET(X,Y,0) would actually set a black pixel like the BASIC manual implied.
It will be called like this:
10 CLS 20 FOR A=0 TO 31 30 X=A:Y=A:GOSUB 100 40 NEXT 50 GOTO 50
That above code would draw a diagonal black line from the top left of the screen down to the middle bottom of the screen.
To erase a pixel, we’d just use SET(X,Y,1) to place a green pixel there.
Is there a clever way to do this? Leave your efforts in the comments, or send them to me via e-mail.