After the bit file has been downloaded to the board, a batch file such as saapal.bat must be run on the programming computer to program the video decoder chip. Once this is done, push switch 3 to start capturing frames and switch 2 to stop capturing frames. The last frame captured is left displaying when stopped. The default modes set allow high colour images updating as rapidly as possible. This causes a lot of noise on the screen during capture. The code contains comments that can be removed if desired to implement the following features:

Slowing capture rate: By slowing the capture rate, more of each image can be seen clearly between refreshes.

Screen blanking: The screen usually does not blank while a new frame is being captured. Frame capture causes noise in the display signal as the writes to RAM stop the reads from working. It is possible to make the screen blank during frame capture which will result in images going black before they are redisplayed.

Changing to 8-bit data: By changing to using 8-bit data, more pixels can be drawn on each screen. The default is 720 pixels wide with each piece of data mapping to two adjacent pixels. This is like having 360 pixels each two normal pixels wide. By using 8-bit data, two pixels can be stored in each byte in RAM and the full 720 pixels wide can be used.

Specifications

RAM usage

The video in project uses the left bank of RAM to store the data by concatenating the row and column addresses of the pixels. Each address stores the data for two pixels. The row address is the upper 10 bits of the address used. The upper 9 bits of the column address are used to specify which column is being used. The lower bit is ignored as this is the bit which chooses which pixel we want. By default, the 16 bits of data at each address represents a colour for both of the pixels, although it can be changed so that the MSB is used to store 8-bit data for pixel 0 and the LSB stores 8-bits for pixel 1. The right bank of RAM cannot be used, as the pixel lines of the RAMDAC are connected to several of the address lines of the right bank of RAM.

Display

By changing the batch file used to program the video decoder chip, both NTSC and PAL video formats can be displayed, although NTSC will also display some excess RAM data at the bottom of the screen due to its smaller resolution. PAL will display at 720*576 lines, and NTSC at 720*486. The SAA7113 datasheet details what all the registers do and should be referred to when changing the batch file. The standards both interleave their data, and the RAM is written in a way to interleave the data on the screen properly.

SAA7113 Programming

To program the SAA7113 with different data, the SAA7113.exe file should be used. This was provided by the XESS Corporation. It takes command line parameters.

To write to a sub-address use the format:

saa7113 w sub-address value

Both the sub-address and value should be hex values.

To read from a sub-address of the SAA7113 chip use the format:

saa7113 r sub-address value

where again the sub-address is in hex and the value is any hexadecimal integer (it is ignored but is required). The value returned from the SAA7113 will be displayed.

Colour

Some boards do not have the right clock for the video decoder and may not be able to decode colour. This can be fixed by contacting XESS. To activate colour, register 11(hex) may need to have the value 9 written to it. This has not been tested as our board did not have the correct clock, and we did not have time to replace it when the error was discovered, although it seems that it should work. The formulas used in the file to convert YUV to RGB may be incorrect as they have never been properly tested.

Process

The saa7113.vhd file controls the decoding of data by using the VPO bus. See page 31 of the datasheet for more information. The timing codes are searched for in the data to know when to start and stop writing data. See the file for more information.

Limitations

As already mentioned, there are some problems with the signal glitching due to RAM contention while the device is capturing. This can be fixed by lowering the VGA output timing to a 25MHZ pixel clock and cleverly interleaving and pipelining the reads and writes to RAM, to provide a full real-time streaming of input to output. Interleaving also causes some problems in display as the two fields outputted by the chip are sampled at different times, causing screen captures to have half the horizontal lines displaced from the other half.

Finally, there are some problems with the RAM controller this project uses that may be causing some writes to be ignored. This causes some errors in some captured frames.

Extensions

There are many extensions that could be done to this project to increase the use of the project. Many of these have been mentioned in the limitations section above. There are many problems that need to be fixed and the code can be made a lot cleaner.