Final Report on the Digital Video Processor

Stephen Edwards

Overview

This describes a digital video processor built around the Motorola 56001 DSP and the Philips digital video chips. Coupled with a bank of twelve 256k bit * 4 VRAMS, this system is capable of genlock, overlay, real-time frame capture, and video effects such as shrinking and rotating.

Theory of Operation

In the following discussion, please refer to the block diagram.

The system accepts two different input formats: conventional NTSC composite color video, and the newer SVIDEO format, which separates the luminance (brightness) and chrominance (color) information into two signals. Composite video or the luminance portion of SVIDEO is digitized at 13.5 MHz by a TDA8708 video ADC. For SVIDEO, the chrominance portion is digitized by a similar TDA8709.

From the two ADCs come two 8-bit data streams at 13.5 MHz, which are fed into the SAA9051 Digital MultiStandard Decoder or DMSD. This chip separates the color information from composite video and separates the two chrominance signals into two data streams, one for luminance, and one for chrominance.

Once the color video is separated in the digital domain, it can flow to one of two places. If the system is in the pass-through mode, this information flows through a bank of multiplexers to the SAA7192 Digital Colorspace Converter. This chip takes the luminance and chrominance signals, smooths them, and performs the YUV-to-RGB conversion. This data then passes through a Brooktree Bt101 Video DAC and on to an RGB monitor.

Alternately, the digital video stream can be diverted to a bank of latches, which combines pairs of pixels to form 24-bit words which the 56001 can write into the VRAM. The 56001 functions almost as a DMA controller, since the video data flows directly to the VRAMS, and is not stored or processed by the 56001.

The serial shift registers in the VRAMS are constantly sending out pairs of pixels, which can be made to flow through the aforementioned bank of multiplexers to be displayed on the monitor.

Operation

Frame Capture

Full color interlaced frame capture can occur in real time through the use of page mode accesses to the VRAMs. At the beginning of a scan line, a VRAM access is initiated, and the row address is supplied. When active pixels begin to appear, they are written in pairs to the VRAM, all while RAS is held low to preserve the row address. For this, the 56001 is performing read cycles to supply the column address to the VRAMS. However, the VRAM controller changes this into a write cycle for the VRAMs and output enables the pixel latches. Since the 56001 is doing a read cycle, it is not driving the bus during this time.

Using the elaborate address generation unit in the 56001, fractional horizontal compression of the video is possible here. Since the low-order bits of the address are not used to produce addresses for the VRAMs, the address is treated as a fixed-point number with a fractional part.

Frame capture is accessed by pressing `down' from the main menu. The video begins to be captured. The upper line and leftmost column can be adjusted by holding the `up' and `left' buttons while turning the knob. The width and height of the captured image can be likewise adjusted using the `right' and `down' buttons.

As always, the `center' button will exit the frame capture mode and hold the picture in the current buffer.

Parameter Modify

The SAA9051 DMSD has 12 control registers in it, accessed through Philips' I2C bus, a multi-master, variable speed serial bus. Unfortunately, the 56001's two serial ports are not flexible enough to completely implement the protocol, so it was written instead in software. Since these registers only need to be changed occasionally, the speed penalty is perfectly acceptable, and the protocol easily supports this.

Parameter modify is accessed by pressing the `left' button. Normally, the bit or byte highlighted in yellow is changed when the knob is rotated. Which register is being modified can be changed by holding down the `up' button while rotating the knob. The selection of which bit to modify, or the whole byte, can be changed by rotating the knob while the `left' button is pressed. `center' exits.

Spinning Cube

The same mechanism of fixed-point address arithmetic used for frame capture allows the incoming video to be drawn on the three visible faces of a rotating cube in space. Fundamentally, the problem is to distort the incoming video frame linearly in real time. By reloading the row address after every four pixels, an incoming horizontal line can be written into memory as a tilted line of any length. By spacing the beginning of these horizontal lines along another line, the necessary distortion can be acheived.

When you press the `up', `left', or `down' buttons in the cube mode, the velocity of the knob is translated to the velocity of the cube's rotation in a particular axis. If you release the button, that velocity remains, so to spin the cube, press the button, spin the knob and release the button while the knob is turning. `center' exits.

Problems & Solutions

At the end of the first term, the color still didn't work. I had located a 24.576 MHz crystal, but it was designed for series resonance, not parallel as required by the on-chip crystal oscillator of the 9051. The slight frequency difference this caused (at most, 10 kHz) was enough to prevent the chip from correctly locking onto the colorburst. Finally, I substituted an external series-mode crystal oscillator and fed that to the 9051. This cured the problem.

The next real challenge was getting the 56001 talking to the 9051 and 7192 over the I2C bus. Eventually, the code would be placed in a horizontal interrupt routine, so I couldn't use any of the nifty hardware looping functions of 56001. Instead, I used the 24-bit word size of the 56001 to keep extra state information. As the data was shifted to get at the various bits, control bits were also shifted around. This scheme works well and produces very clean code.

Another trick was to make the 56001 think it had an open-collector style output. All the parallel I/O is bidirectional, but tristate. By leaving the output data at ``0'' and changing the direction of the pins, the operation of an OC output was emulated.

Next, I wanted the VRAM circuitry to work. One physical challenge was mounting the chips, since they only come in 28-pin ZIP packages having two rows of 14 pins each, offset from each other by 0.05". This, coupled with the fact that I would have to connect over four hundred wires to these chips made me design a PC board. Using a double-sided board, I was able to route the majority of signals to the 96-pin Eurocard connector using a PC board not much larger than the chips and the connector.

The other big challenge was making the color come out correctly. Since the DMSD compresses the chrominance information, each channel supplies two bits per pixel, which are then blocked together by the 7192 and filtered. This also means that if an odd pixel suddenly turns into an even pixel, the color would be off. I finally cured this by making the least significant column address going to the VRAM controlled by the input, and not the 56001.

The final challenge was forcing the program into the limited memory capacity of the 56001. The DSP has 512 24-bit words of program memory on-chip, and it's a very good idea to use this if you can. Otherwise, you need to spend bus cycles going to three off-chip memory chips, which is inherently slow. Since the spinning cube and initialization code nearly consumed all 512 words, I used the additional space in the bootstrap EPROM to store the other modes, loading them into memory and overwriting them as necessary. Since a slow human controls the modes, this switch is never seen.

Conclusion

Overall, this project was very successful. I created what I wanted to create (i.e., the spinning video cube), and it works well. However, in hindsight, it's clear that the compressed chrominance, while reducing memory size and bandwidth by a factor of two, created some other problems on the way. Because of this, I essentially dealt with the image in four-pixel chunks which are easily visible. It would have been better had I adopted a 24-bit color scheme where each pixel would stand on its own, and could be placed anywhere.

Last updated 941105