CD+G Revealed.txt

Version 1.0

1/9/95

Jim Bumgardner

Introduction

A CD+G is a special Audio Compact disc that contains graphics data in addition to
the audio data on the disc.  The disc can be played on a regular Audio CD player,
but when played on a special CD+G player, can output a graphics signal
(typically, the CD+G player is hooked up to a television set).

This file describes how CD+G information is stored on the disc, and provides
information to help programmers implement CD+G playback on personal computers
equipped with CD+G compatible CD-ROM drives.  This document assumes a familiarity
with computer programming, and especially the C programming language.

Ever since I released a utility for the Macintosh that allows owners of Apple's
CD300 to play CD+G discs (CDG Player), I have received numerous requests asking
for the CD+G specification.  Unfortunately, this information has not been made
available to the general public (as far as I know) and is hard to find.
Hopefully, this informal description will help.

It has been a while since I read the CD+G specification.  I am describing this
system from memory, and will often deviate from the nomenclature used in the
actual CD Audio and CD+G specification.

How CD+G information is stored on the disc
==========================================
A Compact Disc contains two kinds of data:  Content data, which is used to store
Audio and Computer software and the like, and Subchannel data, which is normally
used by the CD player to help control the disc.

Assuming the disc is being read at normal speed (approx 150 kps) for audio
playback, the data is read at 75 sectors per second.  In each sector there are
2352 bytes of Content data and 96 bytes of Subchannel data.

On the disc, the Subchannel data is interspersed with the audio data.  But when
the disc is played back, the two streams of data are separated.  On a typical
CD-ROM player you can't access the Subchannel information - it is never sent to
the computer.  In fact, until recently on most CD-ROM players, you couldn't read
the Content data on an audio track either. You could only read the Content data a
data track which is used specifically for storing computer information.
Presumeably, this was done to prevent people from easily pirating Audio CDs.

More recently however, manufacturers have started producing drives that allow the
computer to access not only the Content data on an audio track, but also the
Subchannel data.  As we shall see, it is this Subchannel capability which is
needed for a computer to be able to play a CD+G disc.

The 96 bytes of Subchannel information in each sector contain 4 packets of 24
bytes apiece.

The structure of the packet is as follows:

typedef struct {
  char	command;
  char	instruction;
  char	parityQ[2];
  char	data[16];
  char	parityP[4];
} SubCode;

Each byte in the 16 byte SubCode.data[] field can be thought of as being divided
into 8-bits.  Each of these bits corresponds to a separate stream of information.
These streams are called "channels", and are labeled starting with the letter P,
like so:

  Channel#      P Q R S T U V W
  Bit#          7 6 5 4 3 2 1 0
                ---------------
  Byte #  0     0 0 0 0 0 0 0 0
  Byte #  1     0 0 0 0 0 0 0 0
  Byte #  2     0 0 0 0 0 0 0 0
  .
  . (etc.)
  .
  Byte #  15    0 0 0 0 0 0 0 0

Both the P and Q channels, on a regular Audio CD are used for timing information.
They are used to assist the CD Player in tracking the current location on the
disc, and to provide the timing information for the time display on the CD
Player.

On a regular Audio CD, channels R through W are unused.

The CD+G format takes advantage of the unused channels R thru W.  These unused
six bits are used to store graphics information. Note that this is an extremely
thin stream of information.  6 bits per byte * 16 bytes per packet * 4
packets per sector * 75 sectors per second = 28800 bits per second, or 3.6 K per
second.  By comparison, a typical 160 x 120 QuickTime movie uses 90K per second.

CD+G Graphics Instructions
==========================
The CD+G standard is published by Philips and Sony as an extension of the Red
Book. It defines a specific system for decoding the subchannels R thru W.  Note:
if you gain sufficient control of the CD mastering process, you could define your
own Audio-compatible format which is potentially more interesting than CD+G.
For example, you could use the Subchannel to store control information for an
animatronics robot, MIDI information, etc.  There already is a CD+G+MIDI extension
of the CD+G standard, but I won't describe it here.

Also, there is an "Extended" CD+G standard which allows for more colors and
effects in a backward compatible manner, but I have yet to see any discs
published in this format, so I will only describe the basic format.

In the CD+G system, 16 color graphics are displayed on a raster field which is
300 x 216 pixels in size.  The middle 294 x 204 area is within the TV's
"safe area", and that is where the graphics are displayed.  The outer border is
set to a solid color.  The colors are stored in a 16 entry color lookup table.

Each color in the table is drawn from an RGB space of 4096 (4 bits each for
R,G and B) colors.

Since we are using a 16 color table, each pixel can be stored in 4 bits,
resulting in a total pixelmap size of 4 * 300 * 216 = 259200 bits = a little less
than 32K.

The SubCode.command and SubCode.instruction fields in each SubCode packet are
used to determine how the data is to be interpreted.  I will enumerate these
commands below.  When reading the command and instruction fields, you should only
pay attention to the lower 6 bits of each of these bytes (e.g. by ANDing
the byte with the hex value 3Fh). The upper 2 bits are used for the P and Q
channels which you should ignore.

If the lower 6 bits of the command field are equal to 9, then the SubCode packet
contains CD+G information, otherwise it should be ignored.

If the packet contains CD+G information, then you use the instruction field
(again, the lower six bits), to determine how to interpret the data.
An example will be shown below.

Instruction List  (Brief)
================

A more detailed description of each instruction appears later in this document.

Number        Name/Description
======        ================
   1          Memory Preset
   				Set the screen to a particular color.

   2          Border Preset
   				Set the border of the screen to a particular color.

   6          Tile Block (Normal)
   				Load a 12 x 6, 2 color tile and display it normally.

   20         Scroll Preset
   				Scroll the image, filling in the new area with a color.

   24         Scroll Copy
   				Scroll the image, rotating the bits back around.

   28         Define Transparent Color
   				Define a specific color as being transparent.

   30         Load Color Table (entries 0-7)
   				Load in the lower 8 entries of the color table.

   31         Load Color Table (entries 8-15)
   				Load in the upper 8 entries of the color table.

   38         Tile Block (XOR)
   				Load a 12 x 6, 2 color tile and display it using the XOR method.

Code Example
===========

This code example shows how you might implement the graphics display dispatcher
for a CD+G player in C.

	#define SC_MASK           0x3F
	#define SC_CDG_COMMAND    0x09
	#define CDG_MEMORYPRESET  1
	#define CDG_BORDERPRESET  2

	// etc... - define each instruction listed above

	ReadSubCodePacket(&subCode);

	if ((subCode.command & SC_MASK) == SC_CDG_COMMAND) {	// CD+G?
		switch (subCode.instruction & SC_MASK) {
		case CDG_MEMORYPRESET:		MemoryPreset(subCode.data);		break;
		case CDG_BORDERPRESET:		BorderPreset(subCode.data);		break;
   			// etc...  - implemement each instruction listed above
		}
	}

How to read SubCode packets on a Computer equipped with a CD-ROM drive
======================================================================
This is the (possibly) hard part.  If your CD-ROM drive doesn't support this
feature, you are shit-out-of-luck.  If the *Driver* software that is used to
control your CD-ROM drive doesn't support this feature, you are also
shit-out-of-luck, although less so, since you might be able to write a new
driver, or obtain a new one.  Good luck.

As far as I know, the only way this step can be easily solved (today), it to use
an Apple Macintosh equipped with an Apple CD300 drive or better.  Both this
drive, and the driver that is included with it support SubCode access.  Apple
publishes a document called "CD-ROM Driver Calls" which is available from
ftp.apple.com.  It describes the newer driver calls that allow you to retrieve
SubCode packets on the Apple CD300 drive.  These calls often do not work on 3rd
party drives. I used the information in this document to code a function based on
the Mac Toolbox call PBControl, which will retrieve SubCode packets.


CD+G Instructions (detailed)
=================

Here I describe the CD+G instructions in detail, hopefully providing enough
information for a programmer to implement CD+G playback.

Note that in all these instructions, only the lower 6 bits of each data byte are
used.  So, for example, If I refer to subCode.data[0], I actually mean
(subCode.data[0] & 0x3F).

****
Memory Preset (subCode.instruction==1)
****

In this instruction, the 16 byte data field is interepreted as follows.

 typedef struct {
	char	color;				// Only lower 4 bits are used, mask with 0x0F
	char	repeat;				// Only lower 4 bits are used, mask with 0x0F
	char	filler[14];
 } CDG_MemPreset;

Color refers to a color to clear the screen to.  The entire screen should be
cleared to this color.

When these commands appear in bunches (to insure that the screen gets cleared),
the repeat count is used to number them.  If this is true, and you have a
reliable data stream, you can ignore the command if repeat != 0.

***
Border Preset (subCode.instruction==2)
***

In this instruction, the 16 byte data field is interepreted as follows.

 typedef struct {
	char	color;				// Only lower 4 bits are used, mask with 0x0F
	char	filler[15];
 } CDG_BorderPreset;

Color refers to a color to clear the screen to.  The border area of the screen
should be cleared to this color.  The border area is the area contained with a
rectangle defined by (0,0,300,216) minus the interior pixels which are contained
within a rectangle defined by (6,12,294,204).

***
Tile Block Normal (subCode.instruction==6)
Tile Block XOR (subCode.instruction==38)
***

These commands load a 12 x 6 tile of pixels from the subCode.data area.  I recall
that in the original CD+G spec, the tile is refered to as a "font", but I think
the word tile is more appropriate, because the tile can (and does) contain any
graphical image, not just text. Larger images are built by using multiple tiles.
The XOR variant is a special case of the same command, the difference is
described below.

The tile is stored using 1-bit graphics.  The structure contains two colors which
are to be used when rendering the tile.  The tile is extracted from 16 bytes of
subCode.data[] in the following manner:

typedef struct {
	char	color0;				// Only lower 4 bits are used, mask with 0x0F
	char	color1;				// Only lower 4 bits are used, mask with 0x0F
	char	row;				// Only lower 5 bits are used, mask with 0x1F
	char	column;				// Only lower 6 bits are used, mask with 0x3F
	char	tilePixels[12];		// Only lower 6 bits of each byte are used
} CDG_Tile;

color0, color1 describe the two colors (from the color table) which are to be
used when rendering the tile.  Color0 is used for 0 bits, Color1 is used for 1
bits.

Row and Column describe the position of the tile in tile coordinate space.  To
convert to pixels, multiply row by 12, and column by 6.

tilePixels[] contains the actual bit values for the tile, six pixels per byte.
The uppermost valid bit of each byte (0x20) contains the left-most pixel of each
scanline of the tile.

In the normal instruction, the corresponding colors from the color table are
simply copied to the screen.

In the XOR variant, the color values are combined with the color values that are
already onscreen using the XOR operator.  Since CD+G only allows a maximum of 16
colors, we are XORing the pixel values (0-15) themselves, which correspond to
indexes into a color lookup table.  We are not XORing the actual R,G,B values.

***
Scroll Preset (subCode.instruction==20)
Scroll Copy (subCode.instruction==24)
***

In these instruction, the 16 byte data field is interepreted as follows.

 typedef struct {
	char	color;				// Only lower 4 bits are used, mask with 0x0F
	char	hScroll;			// Only lower 6 bits are used, mask with 0x3F
	char	vScroll;			// Only lower 6 bits are used, mask with 0x3F
 } CDG_Scroll;

This command is used to scroll all the pixels on the screen horizontally and/or
vertically.

The color refers to a fill color to use for the new area uncovered by the
scrolling action.  It is only used in the Scroll Preset command.  In the Scroll
Copy command the screen is "rotated" around.  For example, in scrolling to the
left, pixels uncovered on the right are filled in by the pixels being scrolled
off the screen on the left.

The hScroll field is a compound field. It can be divided into two fields like so:

  SCmd = (hScroll & 0x30) >> 4;
  HOffset = (hScroll & 0x07);

	SCmd is a scrolliing instruction, which is either 0, 1 or 2.
		0 means don't scroll
		1 means scroll 6 pixels to the right,
		2 means scroll 6 pixels to the left.

	HOffset is a horizontal offset which is used for offsetting the graphic
	display by amounts less than 6 pixels. It can assume values from 0 to 5.

Similarly, the vScroll field is a compound field. It can be divided into two
fields like so:

  SCmd = (vScroll & 0x30) >> 4;
  VOffset = (vScroll & 0x0F);

	SCmd is a scrolliing instruction, which is either 0, 1 or 2.
		0 means don't scroll
		1 means scroll 12 pixels down,
		2 means scroll 12 pixels up.

	VOffset is a vertical offset which is used for offsetting the graphic
	display by amounts less than 12 pixels. It can assume values from 0 to 11.

Smooth horizontal and vertical scrolling in all directions can be done by
combining scroll commands.  For example, here is a smooth horizontal scroll to
the left:

	SCmd			HScroll
    ===             =======
	0				1
	0				2
	0				3
	0				4
	0				5
	0				6
	2				0
	(repeat)

You can create the effect of an infinite panorama by continually loading in new
tiles into the border area and scrolling them into view.

***
Define Transparent Color (subCode.instruction==28)
***

This command is used to define a CLUT color as being transparent, for example so
that the the graphics can be overlayed on top of a live video signal.


***
Load Color Table Lo   [colors 0 thru 7]  (subCode.instruction==30)
Load Color Table High [colors 8 thru 15] (subCode.instruction==31)
***

These commands are used to load in the colors for the color table.  The colors
are specified using 4 bits each for R, G and B, resulting in 4096 possible
colors.  The only different between the two instructions is whether the low
part or the high part of the color table is loaded.

In these instruction, the 16 byte data field is interpreted as follows.

typedef struct {
	short colorSpec[8];  // AND with 0x3F3F to clear P and Q channel
} CDG_LoadCLUT;

Each colorSpec value can be converted to RGB using the following diagram:

    [---high byte---]   [---low byte----]
     7 6 5 4 3 2 1 0     7 6 5 4 3 2 1 0
     X X r r r r g g     X X g g b b b b

Note that P and Q channel bits need to be masked off (they are marked
here with Xs.

The Load CLUT commands are often used in CD+G to provide the illusion of
animation through the use of color cyling.

* End of Document *
</pre>

<!--#include file="footer.html" -->

 
</body></html>