8.3 Initial Requirements/Specifications
The following requirements/specifications for a "Frame Buffer" box were proposed:
-
Autonomously generate and output a repeating ramp image.
-
Receive a single downloaded file from a DECstation via a Direct Memory Access (DMA) interface.
-
Accept full or partial frames.
-
Output the downloaded frame once, a specified number of times, or repeat the frame continuously.
-
Inject a deterministic delay between telemetered frames.
-
Telemeter a segment of pixel(s) "n" times.
-
Generate a base frame which repeats and in which pixel data increments according to downloaded parameters. (Refer to the Status section.)
-
Provide 6 DEA-to-FEP output circuits having indentical data and signal timing.
8.4 Basic Design Concept
The Buffer is designed around a Motorola 56001 Digital Signal Processor (DSP). All code will be in ROM. A DMA interface is incorporated for receiving downloaded files from the DECstation (and possibly DMA equipped SPARCstations). An internal memory stores a full 16 Mbit frame plus up to 128K miscellaneous pixels (e.g., Over Clocks, Ignores, directives, etc.). The memory is organized in 9 131,072 x 16-bit pages. Electrical and data format of signals interfacing to flight hardware will be reproduced as defined in the "DPA/DEA Interface Control Document". Integrated circuits interfacing to flight hardware will be commercial versions of flight components. Signal timing will be done with hardware circuitry versus software control. The Pixel Clock frequency is derived from an "RC Coupled CMOS Gate Mulitvibrator" circuit running at approximately 6.4 MHz. Since the frequency is determined by a resistor and capacitor, its stability will not be very good.
The Frame Buffer will not supply FEP power. Buffer internal power will be over-voltage protected.
Buffer requirements such as telemetering a segment of pixels "n" times, or a frame "n" times, are accomplished by using special "directive" pixels inserted in the appropriate locations in the downloaded file. These directives use five (TBR) Pixel Codes not used by the FEP. In some cases the 12 data bits in the directive or the 12 data bits in a second pixel are an argument to the directive. Directive pixels must be inserted by the user in the file to be downloaded.
8.5 Operating Modes
There are two modes of operation selected by a front panel switch: Ramp and Normal Mode.
8.5.1 Ramp Mode
In Ramp Mode the Buffer continuously telemeters pixels which are generated in real time--this is not a stored file. The ramp image begins with 4 Ignore pixels followed by 4 Vertical Syncs followed by 1024 rows of 1024 columns of Valid pixels. Column 0 of each row contains the row number (0 thru 3FF hex). Columns 1 thru 1023 contain the column number (1 thru 3FF hex). Each row ends with 32 Over Clocks having an incrementing data field (0 thru 1F hex) followed by 4 Horizontal Syncs.
8.5.2 Normal Mode
8.6 Directive Functions
In the following paragraphs, unused bits in hexadecimal fields are marked with the letter `X'.
8.6.1 "EXXX" Last Pixel Flag (LPF)
The LPF marks the last pixel in the downloaded file. The data bits in this pixel are ignored. Attempting to download pixels after a LPF will have an indeterminate effect on the Buffer operation. A frame may contain multiple images but only one LPF directive.
8.6.2 "Annn" Repeat Segment "nnn" times (RS)
"Xnnn" Segment Length argument (SL)
This function requires two arguments. The first argument is the 12 data bits in the directive which defines the number of times (up to FFF hex) the segment is to be written to the FEP. The second argument is in the following pixel and defines the number of pixels (up to FFF hex) in the segment. The pixel following the second argument is the first pixel of the segment.
8.6.3 "7nnn" Repeat Frame "nnn" times (RF)
Repeat this frame "nnn" times. If the downloaded file does not begin with this directive, or if its argument "nnn" is "000 hex", the frame will repeat continuously. This directive must appear as the first word in the downloaded file--it is only tested once, and will be ignored if it occurs later in the file.
8.6.4 "6000" Go (TBR)
This single directive (or, more appropriately, command) downloaded from the DECstation causes the Buffer to begin telemetering a currently stored frame. This directive is ignored unless a frame has been stored in the buffer.
8.7 Current Status
Two circuit boards have been wired and a third is in progress. (Hardware revision levels below are for initial use only.)
-
S/N 01 hardware is at Rev. 01. The DSP code installed in this unit is configured to generate ramp images only--image data files cannot be downloaded to this unit at this time.
-
S/N 02 hardware is at Rev. 04. This unit has been used to develop DSP code to receive downloaded files, decode directives, and output image data in accordance with those directives. Code to generate a ramp image is not installed in this unit as yet.
The current version of the DSP code processes directives correctly. Timing has been a concern because, within the 2.5 sec pixel period, each pixel is read, decoded and processed before it is telemetered to the FEP. "Repeat Segments" within the frame are processed in about 1.5 sec. Continuous frames are also not a problem, taking about 0.75 sec to process. The additional code required to process a "Repeat Frame" proved to be a problem. Periodically it has taken more than 2.5 sec to set up for the next frame. As a result, the last pixel of the previous frame would be re-telemetered before the first pixel of the coming frame could be latched into the output circuits. To avoid this problem, I have the DSP running with minimum wait states. To gain some margin, the current 24 MHz DSPs will be replaced with 33 MHz devices. The download time for short (1k word) files has been measured at approximately 3.2 sec/word. The requirement in which the Buffer would generate a "base" frame which would continuously telemete meter pixels which change data from one image to the next according to downloaded parameters will not be implemented.
8.8 Proposed Additional Features
8.8.1 Front Panel Status LEDs
-
Power On LED -- Self explanatory.
-
DMA Request LED -- Indicates that the DECstation is waiting to download a file. It remains lit during the download and is cleared by the Buffer receiving a LPF or a RESET.
-
Telemetry In Progress -- Lit while the Buffer is telemetering Pixels to the FEP.
8.8.2 Error LED(s)
-
Pixel Re-write LED -- Lit when a timing error occurs and the Buffer re-telemeters a Pixel. This LED would be cleared by a RESET.
Table of Contents
Previous Chapter
Next Chapter
Peter G. Ford Last modified: Mon Nov 25 15:22:26 EST