Hi-Res Coco3 Graphics to BMP and Back Again

Part I

by Robert Gault


This is the beginning of a three part series on Coco 3 graphics. Much of the series will deal with assembly language programming in the format of EDTASM6309. (Minor changes will make it suitable for EDTASM+.) You will learn how to check the color tracking of your TV/monitor, transfer high resolution Coco graphics to BMP files for transfer to Windows computers, and how to view BMP files on the Coco in a special flicker mode. No it’s not the flicker mode your thinking of!

Before getting to details, I need to set the stage with some background. This project was born of necessity and grew to a series of full fledged programs. I just started a personal web page and wanted to include Coco graphics. There are several ways this could be done but I don’t have the programs or equipment. 1) Take screen photos, convert them to digital format, and post them. (I don’t have a digital camera or scanner.) 2) Run the programs with the Coco 3 emulator and do screen captures. (I don’t have Jeff’s program.) 3) Capture the graphics with a Coco program in a universal format, GIF, JPG, etc. (I don’t have Roger’s latest version of The Projector.) Hey, but we own Color Computors and like to program, right?!

There are many different formats for saving graphics data. The most common are GIF and JPG, but these also use compression schemes that would tax the capabilities of a Coco. For one thing, most of these files are now in the megabyte range and can’t fit on any Disk Basic media. However, there are many programs available for Windows computers which can convert graphic file formats, change color counts, and shrink picture sizes. With this in mind, I chose to make use of the BMP format because there are two BMP types (2 color and 16 color) which store data in the same manner that the Coco uses memory for HSCREEN2 and HSCREEN3 pictures. Therefore a HSCREEN to BMP convertor is by far the easiest program to write.

Testing a Monitor for Color Linearity and How the Coco 3 Uses Graphics Memory

In the Coco, the bytes $FFB0 - $FFBF hold the palette values. These values tell the hardware what voltages to place on the color lines going to your monitor. The graphics data itself contains only a palette number. This is true for both RGB and composite systems. I would much prefer to only discuss the RGB format but many Coco users have composite monitors so I’ll describe both systems.

The simplest system is the R(ed)G(reen)B(lue) which sends signals directly to the three color guns in a picture tube. Colors are made with an additive color blending technique where no signal is black and a full signal in all three channels is white. The palette registers are assigned as follows for the RGB system.
  bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
Palette Byte - - msbR msbG msbB lsbR lsbG lsbB
Full red     1 0 0 1 0 0
Medium blue green     0 1 1 0 0 0

The composite system uses intensity and phase angle to create colors. This is not as intuitive as RGB but not impossible to understand. This signal is not sent to the color guns but instead to a demodulation unit. The signal consists of a color burst at about 3MHz and an intensity voltage. The color burst is a sine wave which is synchronized with the square wave of the intensity signal. If the square wave starts in the middle of the sine wave pattern the color will be different than if it started at the beginning of the pattern.

The best way to think of this is to picture a color chart in the form of a circular dart board. The center of the board is maximum intensity the edge minimum. The primary colors are separated by 120 degrees. If you draw a line from the center to the edge, the angle (0-360) will determine the color and the length the intensity.

If you have a composite monitor try program CMP.BAS to see how this looks. Without having a circular color chart, it is very difficult to know what values to use for composite colors.
  bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
Palette Byte     msbI lsbI msbP     lsbP
Full red - - 1 0 0 1 1 1
Med. blue green - - 0 1 1 0 0 0

I=intensity P=phase angle

There is no exact correlation between RGB and composite colors. In the Coco composite system, there are 2^4=16 distinct colors and 4 levels of intensity. In the RGB system, there are 3 distinct colors with 3 levels of intensity plus white, black and two grays. However, RGB colors can be blended at will. Blending in levels of gray creates more effective intensity levels for some colors. The color changes can be very subtle and on some systems may be very hard to see; which brings me to the second subject for this article.

If your monitor is not correctly adjusted, the picture can be quite amazingly bad. Let’s look at just one aspect of this, color. Both your computer and monitor must have accurate color tracking to get a good picture. On modern sets it is rare to see gross misalignment where a screen has an overcast of red, green, or blue. Small misalignments will make it difficult to achieve a full range of color. The following program SCREEN.BAS will test color tracking on both RGB and composite system by generating color bands of increasing density from black to white. All bands should be easily seen whether red, green, or blue. This is not much of a test in this world of 24 bit color but it will be a challenge for most monitors used with a Coco. There will be one more band on RGB systems than on composite systems. Make the selection by changing a value in line 10.

If you can’t see the full range of density, try adjusting brightness, contrast, and tint, if on a composite monitor. If none of the above help, you will need to adjust the monitor internally (drive and gain), but don’t call me for help if you mess up the settings on your monitor.

In case it was not clear from the above discussion, here is the graphics memory format for HSCREENs. Your actual picture data does not contain any color information, just palette numbers. The choice of HSCREEN mode determines the number of bits assigned to hold the palette numbers. Here is the format for the two modes I will be using in Parts 2 & 3.

HSCREEN2 320x192x16
    320x192=61440 pixels
    2^4=16 so 4 bits can represent 16 colors
    61440 / 2=30720 or $7800 bytes per mode2 screen
HSCREEN3 640x192x2
    640x192=122880 pixels
    2^1=2 so 1 bit can represents 2 colors
    122880 / 8=15360 or $3C00 bytes per mode3 screen
At 15K and 30K, you can easily fit several files on a Disk Basic floppy in BMP format as the header is at most 76 bytes.
0 REM CMP.BAS (c) Robert Gault, Feb 1999
10 REM This is for CMP monitors only! However, you can still get an idea
20 REM of how the program works on an RGB monitor.
30 REM Numbers are entered "blind" but will show after ENTER key.
60 FORI=0TO170STEP44:HCIRCLE(320,96),192-I,15:NEXT
70 HCIRCLE(500,170),20,15:HPAINT(500,170),14,15
80 A=.419:FORI=0TO15:HLINE(320,96)-(320+SIN(I*A)*192,96-COS(I*A)*96),PSET:NEXT
90 B=.22:FORJ=0TO2:FORI=1TO15:N$=STR$(I+16*J)
100 HPRINT(39+SIN(I*A-B)*(22-6*J),12-COS(I*A-B)*(11-3*J)),N$:NEXTI,J
120 HPRINT(0,3),"GRAY SCALE":HPRINT(60,3),"CMP COLORS":HLINE(10,36)-(50,96),PSET,B
130 HPRINT(0,14),"RED=7":HPRINT(0,16),"BLUE=12":HPRINT(0,15),"GREEN=2"
140 FORI=0TO2:HLINE(10,50+I*15)-(50,50+I*15),PSET:NEXT
150 FORI=0TO3:HPRINT(2,5+I+I),STR$(I*16):NEXT
160 HPRINT(0,23),"ENTER A NUMBER:":HPRINT(4,22),"0-63"
170 INPUT NUM:HLINE(140,184)-(200,192),PRESET,BF:HPRINT(17,23),STR$(NUM)
190 GOTO190
200 CMP

0 REM SCREEN.BAS (c) Robert Gault, Feb 1999
10 DIMP(28):B=6:' RGB=6 CMP=5
20 A$="":ON BRK GOTO300
50 GOSUB290
60 A=INSTR(1,"RBGX",A$):IFA=0THEN50ELSE A=(B+1)*(A-1)
100 DATA 0,4,32,36,39,60,63
110 DATA 0,1,8,9,15,57,63
120 DATA 0,2,16,18,23,58,63
130 DATA 0,0,7,0,56,0,63
150 DATA 0,7,23,39,55,48
160 DATA 0,12,28,44,60,48
170 DATA 0,2,18,34,50,48
180 DATA 0,16,0,32,0,48
230 HPRINT(3,5),"(R)ed (B)lue (G)reen (X) Black"
240 HPRINT(8,7),"Set Brightness, Contrast"
250 HPRINT(1,8),"(and Internal Settings if needed)"
260 HPRINT(8,9),"for the best results"
270 HPRINT(0,11),"All bands are be different colors"