This chapter describes the LeoCross ASIC.
The LeoCross ASIC (U1401 of the upper board schematic), pixel clock synthesizer (U1602), and output RAMDAC (U1501) constitute the video output section. The pixel clock synthesizer is described in Chapter 11, "Pixel Clock Synthesizer." The output RAMDAC is described in Chapter 10.
Figure 9-1 shows the LeoCross block diagram. LeoCross extracts image and window ID data from the Frame Buffer VRAMs. The WID data are then used to select one of several look-up tables, which serve to transform the image data. In addition, LeoCross generates the video timing for several video display resolutions.
Figure 9-1 LeoCross Interface Block Diagram
LeoCross, shown in Figure 9-2, consists of the following main parts:
Figure 9-2 LeoCross ASIC Block Diagram
The VRAM Interface is the data path between the frame buffer and LeoCross. This interface is used during the video cycle to read pixel and window ID data.
The Output RAMDAC Interface generates the final pixel value to be displayed to the RAMDAC. LeoCross generates the data onto two 24-bit buses to the RAMDAC: A and B. These two buses represent two adjacent pixels in the output data stream.
The CX Bus Interface allows LeoCross to interface to LeoCommand. LeoCommand is the provides the interface between the SBus and LeoCross. All lookup tables, control and status registers, and programmable registers are accessed through this interface.
The Plane Switch Network matches incoming RGB data from the VRAMs with the corresponding color lookup table via the window ID and cursor data. The Plane Switch Network includes window identification lookup-tables (WID LUTs) and color lookup-tables (CLUTs). This section contains:
The cursor logic consists of two major components. The first component consists of the cursor enable and cursor color planes. These two planes are 32 by 32 RAMs, whose data comes from the SBus (via LeoCommand). The second component, is the cursor processor, which examines the cursor address register and decides when to introduce the cursor data into the video stream. The cursor color bit is fed into a look-up table, which provides two choices of cursor color.
LeoCross supports interlaced monitors and, therefore, the interlaced cursor generation. Leo does not support stereo cursor.
The Video Timing Generator generates the video signals necessary to control the following video specifications:
The stereo shutter, left/right field signal is generated from this block.
LeoCross has seven major interfaces: VRAM data, Output RAMDAC, Video, monitor ID input, LeoDraw, CX Bus, and miscellaneous.
Table 9-1 summarizes the VRAM data interface signals.
Table 9-1 LeoCross VRAM Data Interface Signals
------------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ------------------------------------------------------------------------------------------
LX0_RGBO<23:0'> 24 I Bi-state Image RGBO for interleave 0
LX1_RGBO<23:0'> 24 I Bi-state Image RGBO for interleave 1
LX2_RGBO<23:0'> 24 I Bi-state Image RGBO for interleave 2
LX3_RGBO<23:0'> 24 I Bi-state Image RGBO for interleave 3
LX4_RGBO<23:0'> 24 I Bi-state Image RGBO for interleave 4
LX0_FC<5:0'> 6 I Bi-state Six fast clear planes for interleave 0
LX1_FC<5:0'> 6 I Bi-state Six fast clear planes for interleave 1
LX2_FC<5:0'> 6 I Bi-state Six fast clear planes for interleave 2
LX3_FC<5:0'> 6 I Bi-state Six fast clear planes for interleave 3
LX4_FC<5:0'> 6 I Bi-state Six fast clear planes for interleave 4
LX0_WID<9:0'> 10 I Bi-state Window ID for interleave 0
LX1_WID<9:0'> 10 I Bi-state Window ID for interleave 1
LX2_WID<9:0'> 10 I Bi-state Window ID for interleave 2
LX3_WID<9:0'> 10 I Bi-state Window ID for interleave 3
LX4_WID<9:0'> 10 I Bi-state Window ID for interleave 4
WID_FC_SC<4:0'> 5 O Tri-state WID and Cursor serial clock for interleaves 0 - 4
A_SC<4:0'> 5 O Tri-state A serial clock for VRAM interleaves 0 through 4
B_SC<4:0'> 5 O Tri-state B serial clock for VRAM interleaves 0 through 4
A_SE<4:0'> 5 O Tri-state A serial enable for interleaves 0 through 4
B_SE<4:0'> 5 O Tri-state B serial enable for interleaves 0 through 4
OVL_SE<4:0'> 5 O Tri-state Overlay serial enable for interleaves 0 through 4
------------------------------------------------------------------------------------------
These lines contain the 24-bit image and overlay data from interleaves 0 through 4, where n = 0 through 4. The overlay data shares the red color data bits.
These lines contain the six-bit fast clear input for interleaves 0 through 4, where n = 0 through 4, representing interleaves 0 through 4. The VRAM component that stores this fast clear information also contains two bits of the window ID information. When LeoCross reads the window ID information from this VRAM, LeoCross automatically lines up the pipe register stages internally before the fast clear information is needed.
The LXn_WID<9:0 lines are the window IDs for interleaves 0 through 4, where n = 0 through 4. This is the address to the WID LUT.
Each location of the window ID LUT consists of ten bits, used as follows:
-------------------------------------------------------------------------------------------------------------------------------------------------
Bits Usage -------------------------------------------------------------------------------------------------------------------------------------------------
2 - 0 Fast clear plane selects. Selects one of six background colors.
3 Fast clear plane enable.
5 - 4 LUT selects. Selects the three LUTs and a LUT bypass.
8 - 6 Bank selects. Depending on bit 9 (color mode), these bits select among
the following:
Bit 9 Bits 8 - 6 Selects
0 000 True color, 24-bit RGB from buffer A.
0 001 True color, 12-bit RGB from 4 MSBs of buffer A.
0 010 True color, 12-bit RGB from 4 LSBs of buffer A.
0 011 Not used.
0 100 True color, 24-bit RGB from buffer B.
0 101 True color, 12-bit RGB from 4 MSBs of buffer B.
0 110 True color, 12-bit RGB from 4 LSBs of buffer B.
0 111 Not used.
1 000 Pseudo color, 8-bit index color from buffer A red
input.
1 001 Pseudo color, 8-bit index color from buffer A
green input
1 010 Pseudo color, 8-bit index color from buffer A blue
input.
1 011 Pseudo color, 8-bit index color from overlay input.
Bit 9 Bits 8-6 Selects
1 100 Pseudo color, 8-bit index color from buffer B red
input.
1 101 Pseudo color, 8-bit index color from buffer B green
input.
1 110 Pseudo color, 8-bit index color from buffer B blue
input.
1 111 Not used.
9 Color mode. Selects pseudo color or true color.
-------------------------------------------------------------------------------------------------------------------------------------------------
Window ID and fast clear VRAM serial clocks for interleaves 0 through 4. Two signals drive two VRAMs each. There are a total of 10 VRAMs.
Serial shift clocks for the 24-bit A buffer, B buffer, and Overlay VRAMs, where n = 0 through 4 (the interleaves). Each signal drives three VRAMs.
Serial shift enable for A and B color VRAMS for interleaves 0 through 4. Each signal drives three VRAMs.
Serial shift clock for the overlay VRAMs, all five interleaves. Each signal drives one VRAM.
Serial shift enable for overlay VRAMs, interleaves 0 through 4. Each signal drives one VRAM.
Table 9-2 summarizes the Output RAMDAC interface signals.
Table 9-2 LeoCross Output RAMDAC Interface Signals
---------------------------------------------------
Signal Name No. Pins I/O Type Description ---------------------------------------------------
DAC_A<23:0'> 24 O Tri-state RGB, A output
DAC_B<23:0'> 24 O Tri-state RGB, B output
DAC_LD 1 O Bi-state RAMDAC load
---------------------------------------------------
The color outputs to the RAMDAC. LeoCross performs a five-to-two interleave conversion; the five-way VRAM interface to the two-pixel RAMDAC input.
RAMDAC load. The rising edge of DAC_LD latches the RGB inputs and the BLANK and SYNC signals into the RAMDAC.
Table 9-3 summarizes the video interface signals.
Table 9-3 LeoCross Video Interface Signals
------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ------------------------------------------------------------------------
CSYNC_L 1 O Tri-state Video composite sync to the RAMDAC
CBLANK_L 1 O Tri-state Video composite blank to the RAMDAC
EXT_CSYNC_L 1 O Bi-state Not used
STEREO 1 O Tri-state Video right-field (stereo monitor)
V_SYNC 1 O Bi-state Vertical sync
H_SYNC 1 O Bi-state Horizontal sync
------------------------------------------------------------------------
Table 9-4 summarizes the monitor ID input signals.
Table 9-4 LeoCross Monitor ID Input Signals
------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ------------------------------------------------------------------------------------
MON_ID<2:0'> 3 I Bi-state Monitor ID input code from the attached monitor
------------------------------------------------------------------------------------
The monitor ID input code from the attached monitor. This code is latched into the Monitor ID register. The system software reads the register and programs LeoCross with the necessary video configurations for that monitor. Table 9-5 lists the standard monitor ID sense codes.
Table 9-5 MON_ID<2:0 Sense Codes
----------------------------
Code Scan Rate ----------------------------
0 1024 \xb4 768 at 76 Hz
1 1152 \xb4 900 at 66 Hz
2 1280 \xb4 1024 at 76 Hz
3 1152 \xb4 900 at 66 Hz
4 1280 \xb4 1024 at 67 Hz
5 1152 \xb4 900 at 66 Hz
6 1152 \xb4 900 at 76 Hz
7 1152 \xb4 900 at 66 Hz
----------------------------
Table 9-6 summarizes the LeoDraw interface signals.
Table 9-6 LeoCross LeoDraw Interface Signals
-------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description -------------------------------------------------------------------------------
XFER_REQ<2:0'> 3 O Bi-state Encoded video refresh request to LeoDraw
-------------------------------------------------------------------------------
Transfer request code. LeoCross uses these lines to send requests for VRAM transfer cycles during the horizontal and vertical blanking interval. A non-idle request is asserted for one cycle. These signals are encoded as follows:
---------------------------------------------------------------------------------
Bit 2 Bit 1 Bit 0 Meaning ---------------------------------------------------------------------------------
0 0 0 No request (idle)
0 0 1 Not used
0 1 0 Not used
0 1 1 DRAM CAS-before-RAS refresh
1 0 0 Increment video counter, split transfer (add offset)
1 0 1 Increment video counter, non-split transfer (add offset)
1 1 0 Initialize video counter = left-even register, use left-even
offset, non-split
1 1 1 Initialize video counter = right-odd register, use right-odd
offset, non-split
---------------------------------------------------------------------------------
Table 9-7 summarizes the CX Bus interface signals. See Chapter 5, "CX Bus for more information on the CX Bus interface.
Table 9-7 LeoCross CX Bus Interface Signals
-----------------------------------------------------------------
Signal Name No. Pins I/O Type Description -----------------------------------------------------------------
CX_DAT<7:0'> 8 I/O Tri-state CX address and data bus
LX_CE_L 1 I Bi-state LeoCross chip enable
CX_R_WL 1 I Bi-state CX Bus read or write enable
CX_CTL<2:0'> 3 I Bi-state CX Bus control
-----------------------------------------------------------------
LeoCross decodes addresses or uses data on this bus to load many LUTs and its programmable registers, which determine its operational functions.
The chip enable for LeoCross. Generated by LeoCommand.
CX Bus read or write enable. When this signal is low, LeoCommand drives the CX Bus. Depending on which devices are enabled at the time, LeoCross takes the bus information and performs a write operation to the specified register.
When this signal is high, LeoCross performs the read cycle. Within a specified number of clock cycles, the enabled LeoCross drives its requested data (set by CX_C<2:0, and its internal address register) onto the CX Bus.
CX Bus control. The functions of these control bits depends on the selected device (LeoCross or Output RAMDAC), as follows:
-------------------------------------------------------
Select C2 C1 C0 Description Access -------------------------------------------------------
LeoCross 0 0 0 LeoCross address pointer Direct
LeoCross 0 0 1 LeoCross control registers Indirect
LeoCross 0 1 0 LeoCross color tables Indirect
LeoCross 0 1 1 Video frame counter Direct
LeoCross 1 0 0 Cursor address pointer Direct
LeoCross 1 0 1 Cursor CSR Direct
LeoCross 1 1 0 Shadow cursor address Direct
LeoCross 1 1 1 Cursor functions Indirect
RAMDAC 0 0 0 RAMDAC address pointer Direct
RAMDAC 0 0 1 RAMDAC color table Indirect
RAMDAC 0 1 0 RAMDAC control register Indirect
RAMDAC 0 1 1 RAMDAC mode register Direct
-------------------------------------------------------
Table 9-8 summarizes the miscellaneous signals.
Table 9-8 LeoCross Miscellaneous Signals
----------------------------------------------------------------------------------------
Signal Name No. Pins I/O Type Description ----------------------------------------------------------------------------------------
VERT_INTR 1 O Tri-state Vertical blanking interrupt.
OSC_SEL<4:0'> 5 O Tri-state Oscillator select. Controls the pixel clock rate.
OSC_STB_L 1 O Tri-state Oscillator strobe. Strobes the OSC_SEL signals
into the clock generator.
PIX_CLK_DIV2 1 I Bi-state Pixel clock divided by 2.
CLK_25M_LX 1 I Bi-state System clock, 40 nanosecond cycle time.
----------------------------------------------------------------------------------------
Vertical blanking interrupt signal to LeoCommand.
Pixel clock synthesizer address and data lines. Only the OSC_SEL<3:0 lines are used. The address and data are strobed into the synthesizer by the OSC_STB_L signal. See Chapter 11, "Pixel Clock Synthesizer," for information on the registers.
Strobes the OSC_SEL<3:0 address and data into the pixel clock synthesizer. The negative edge latches the address into the synthesizer. The positive edge latches the data into the addressed register.
The PIX_CLK_DIV2 input operates all of the LeoCross video-related functions, such as the video timing generator and the state machines. This clock is the pixel clock divided by two, generated by dividing the output of the pixel clock synthesizer by two in the RAMDAC.
In addition to serving as a LeoCross timing signal, this signal (as the DAC_LD signal) also latches incoming two-way interleaved pixel data into the RAMDAC. For more information, see "Horizontal Synchronization" on page 9-63.
As shown in Figure 9-2, LeoCross consists of the following main functional blocks:
These blocks are described in more detail on the following pages.
Figure 9-3 shows the VRAM interface to LeoCross. The figure shows the VRAM inputs to LeoCross and the serial clock and serial enable signals from LeoCross to the VRAMs. Note that the serial enable, SE, input to the Fast Clear and WID planes is not used. This is because they do not need to be tri-stated. Image VRAMs are multiplexed together because the VRAM output tri-state feature of the VRAMs is exploited to act as a multiplexer, allowing the same 24-bit path to be used for Buffer 1 RGB, Buffer 2 RGB, and overlay data.
All operations of the VRAM-to-LeoCross port are synchronized with the serial clock (pixel clock div by 2). Data is shifted out of the VRAM registers at the rising edge of serial clock. The serial clock also increments the VRAM internal nine-bit serial pointer, which selects the address.
Figure 9-3 LeoCross VRAM Interface
The serial enable (SE) output to the VRAMs enables serial access operations. In a serial read cycle, SE is used as an output control. When SE is de-asserted, serial access is disabled. However, the serial address pointer location is still incremented when SC is clocked, even if SE is de-asserted.
The Output RAMDAC interface, shown in Figure 9-4, provides the data signals to the RAMDAC. The RAMDAC provides two-to-one multiplexing of the two sets of eight-bit red, green, and blue ports. The multiplexing control is handled in the RAMDAC.
See Chapter 10, "Output RAMDAC," for more information on the RAMDAC.
Figure 9-4 LeoCross Output RAMDAC Interface
The CX Bus to LeoCross consists of an eight-bit address/data bus, a read/write control signal, a chip-enable signal, and a three-bit control code. See Chapter 5, "CX Bus for more information on the LeoCross CX Bus interface.
LeoCross contains a shadow lookup table that serves as a buffer between LeoCommand accesses and the active lookup tables which actually perform the pixel transformation. LeoCross controls ownership of the shadow lookup table, alternating between LeoCommand ownership and the pixel path, and checks for completion of transfer operations.
In normal operation, LeoCommand would not need to access the active LUTs. However, this capability is provided for diagnostic purposes.
LeoCommand writes data into the shadow table and reads data from it. These two actions differ only in the direction of transfer. In both cases, LeoCommand issues a command to LeoCross which causes LeoCross to transfer data between the shadow and active tables. LeoCross does not execute the command immediately, deferring execution until the arrival of the next vertical blanking interval. At the start of vertical blank, the data is transferred between the active and shadow tables. The transfer operation completes before the end of the vertical blanking interval.
After the transfer is completed, LeoCommand is notified via an interrupt and status reporting mechanism. Obviously, write and read operations are sequentially different. The host is required to write the shadow table before issuing the write transfer command, and is required to issue the read transfer command and receive acknowledgment before reading the shadow table.
It is possible for one or more software processes to require access to different parts of a lookup table during a video frame. The protocol is designed to permit such accesses while minimizing the latency of access. This is accomplished through the combined use of the command and status information associated with each shadow table. Before describing the protocol, it is necessary to define the contents of the registers that control the shadow transfer functions.
Each shadow function is controlled by means of a command status register, shown in Figure 9-5. The command status register bits comprise the transfer direction control, the transfer command, and the device status. For more information on these registers than provided here, see "VINT OPS Control and Status Registers" in the "Leo Hardware Reference Manual," Chapter 7.
Transfer direction - Read or write. Directs LeoCross to either transfer the contents of the shadow table to the active table or to transfer the contents of the active table to the shadow table. The bits are as follows:
0 = Active to shadow
1 = Shadow to active
Transfer command - Read or write. Directs LeoCross to execute the transfer operation immediately upon, but not before, the arrival of the vertical blanking interval. This bit is set by software and may be cleared by either of two events: By LeoCross when the transfer has been completed, or by software, indicating the command has been withdrawn. The bits are as follows:
0 = No action
1 = Transfer
Device status - Read only. Indicates whether the resource is available. This bit is set by LeoCross when it detects that software has posted the transfer command. The set bit indicates the resource is busy; either the transfer is pending or in progress. This bit is reset by either of two conditions. The first condition is the completion of a transfer operation. This event causes LeoCross to reset the status bit to indicate that the resource is available. The second condition results because the protocol permits software processes to withdraw transfer commands initiated by other processes or the same process. LeoCross resets the device status bit if software withdraws the transfer command and the transfer operation has not yet begun. The status bit is not reset if the transfer command is withdrawn after the transfer operation has actually begun. The bits are as follows:
0 = Table available
1 = Busy, table unavailable
Cursor enable - Read or write. Specifies the cursor shape, as follows:
0 = Cursor disabled, display selected buffer, overlay, fast clear or RGB data
1 = Cursor enabled, display selected cursor color
Three types of behavior are possible, as described below.
In this scenario, a software process requires access to a table. The process reads the tables' device status bit and discovers that the table is available. The process modifies the table and posts the transfer command. No other processes require access. The transfer command runs to completion and an interrupt is generated to signal the event.
Condition one accesses are defined as those that occur between the boundaries established by the end of one vertical blanking interval and the beginning of the next. Software process A reads the status register of a table and finds that the table is available. The process modifies the table contents and posts the transfer command. Software process B requires access to the same table. It reads the status and discovers that the table is busy. Process B withdraws the transfer command (which was posted by process A).
Because the command was pending and not actually executing, LeoCross clears the status bit. Process B again reads the status and discovers that the table is available. The process then modifies the contents of the table and posts the transfer command. This sequence may occur for any number of accesses provided Condition one exists. However, this description is limited to two accesses. Ultimately, the vertical blanking interval arrives and the posted command is executed. The entire contents of the table are transferred, so that all of the data belonging to the various processes is transferred. Withdrawal of a command has no effect on table contents. The transfer bit must not be posted before the LUT is done with the modifications.
Condition two accesses are defined as those that occur near the beginning of vertical blanking. Software process A reads the status register of a table and finds the table is available. The process modifies the table contents and posts the transfer command. Software process B requires access to the same table. Process B reads the status and discovers that the table is busy and withdraws the transfer command.
The withdrawal occurs while the transfer is in progress. Consequently, the table is unavailable and LeoCross does not clear the status bit. Process B reads the status and discovers the device busy state.
The LeoCross interrupt mechanism synchronizes LeoCommand accesses to shadow tables and data transfer between the shadow and active tables. The interrupt mechanism consists of:
The interrupt mechanism operates like this:
The VERT_INT signal is a composite signal that indicates that some combination of events, which ultimately must produce an interrupt, has occurred. This signal appears in the LeoCommand Leo System Status register as the CXBus CXint bit. If software has not masked this bit, LeoCommand generates an interrupt.
The reaction of software to this discovery is not dictated by this protocol in any way but one. At some point, the software must clear the LeoCross Interrupt Event register, the LeoCommand Leo System Status register, and finally, re-enable the interrupts.
LeoCross provides an Interrupt Clear Mask, which permits software to clear some, all, or none of the Interrupt Event register bits. This provision precludes collisions between clearing and update operations in the Interrupt Event register.
The Interrupt Event and Interrupt Clear Mask registers are described in detail in the "Leo Hardware Reference Manual."
The Plane Switching Network, shown in Figure 9-6, provides the same functions as a traditional frame buffer cross-bar switch. The network accepts the VRAM bit plane outputs and generates a single RGB data based on a set of window IDs. There are two different window IDs; one for image and one for overlay.
The P window ID, known as the PWID, is a six-bit input that selects one of 64 entries of the PWID table. Each PWID entry is 10 bits wide. The Q window ID, known as the QWID, is a four-bit input that selects one of 15 entries of the QWID table. Each QWID entry is 10 bits wide.
Only one of the window IDs can be valid at a time. The selector between PWID and QWID is when QWID is all 0's or not all 0's. When QWID is all 0's, the PWID input is used to select one of 64 values. When the QWID is not all 0's, the QWID input is used to select one of 15 values.
The Plane Switch Network also provides the following functions:
Figure 9-6 Lookup Table and Display Hierarchy
LeoCross displays each pixel according to the following precedence:
For each pixel on the display,
The LeoCross Cursor Processor inserts the cursor data into the pixel data stream at the appropriate moment. The Leo104 hardware cursor is fairly unique when compared with most other graphics accelerators. Rather than dedicating a number of memory planes to the task of storing the cursor image, Leo104 uses two 32 by 32 RAMs. This means that the hardware-generated cursor must be no larger than 32 pixels by 32 pixels. Any cursor size larger than this must be generated in software.
The cursor logic, shown in Figure 9-7, consists of the two RAMs and the cursor processor. The cursor RAMs are internal to LeoCross. One of the 32 by 32 RAMs holds the cursor color, the other holds the cursor enable. The cursor color information is one-bit per pixel, selecting between two available cursor colors. The cursor enable is also one-bit per pixel, enabling or disabling the display of the cursor color.
The cursor processor continuously compares the contents of the cursor coordinate address register to the screen coordinates produced by the video timing generator. When the two addresses are equal, the cursor processor introduces the contents of the cursor RAM into the video stream, allowing the cursor to appear on the display.
Figure 9-7 Cursor Logic Simplified Block Diagram
The cursor coordinate address comes from the CX Bus in the following format:
The cursor ordinate and abscissa specify the starting address (the upper left corner) of the cursor square, as shown in Figure 9-8. In this scheme, the first visible pixel in the upper left corner of the screen has a coordinate of X (abscissa) = 0 and Y (ordinate) = 0. The pixel address increases from the left side of the screen to the right side. The line address increases from the top of the screen to the bottom.
Figure 9-8 Hardware Cursor Addressing
The cursor processor has to deal with two complications. The first complication is the difference between the pixel frequency clock and the clock that operates the horizontal counter. As shown in Figure 9-9, the clock that operates the horizontal counter is always some fraction of the pixel clock, in the range of f/2 to f/8. This means that the numbers produced by the horizontal counter (abscissas given in image coordinates) and the abscissas of the cursor coordinate address register are not always congruent. It is therefore possible to specify an abscissa for which there is no corresponding horizontal counter value. Consequently, a simple comparison of the two abscissas will occasionally fail to correctly place the cursor origin in the horizontal dimension.
Figure 9-9 The Pixel Clock and its Derivatives
The second complication arises because the timing generator is required to accommodate two different display formats: sequential scan and interlaced scan. These two formats are accommodated by operating the cursor processor differently for each case. The difference affects both the horizontal and vertical dimensions. However, to reduce the complexity of the description, the horizontal dimension is described here while the discussion of the effects in the vertical dimension is given later.
The difference between sequential and interlaced scan formats is as follows:
If we now call a complete image a frame, then in the sequential format a field is equivalent to a frame, while in the interlaced format two fields constitute a frame. Note in Figure 9-10 that the interlaced format divides the image into two fields by assigning all even-numbered horizontal scan lines to the even field, and all odd-numbered horizontal scan lines to the odd field. These even and odd lines occupy different physical locations on the display and, when viewed, give the illusion of a single image.
Figure 9-10 shows the relationship of odd- and even-numbered scan lines relative to the top of the image field, referred to in the figure as the "Vertical reference." The relationship between the vertical reference and the start of a horizontal line differs as a function of the type of line. Odd-numbered lines always start at the left edge of the display field, while even-numbered lines start at the midpoint. This is different from the sequential format where both even- and odd-numbered lines appear in the same field and always start at the left edge of the display.
The cursor processor design in Leo takes advantage of some simple numerical relationships. In the sequential format, all of the required timing information can be obtained by a pair of modulo-n counters, one for each of the horizontal and vertical dimensions. The output of the counters are compared with stored values to produce specific events, such as the start and end points of sync pulses.
The counters operate in cascade. For example, when the horizontal counter reaches its modulus, its output returns to zero and the vertical counter is incremented by one. Therefore, it is possible to describe a horizontal scan as consisting of horizontal counter values in the range of zero to n. Consequently, horizontal dimension events, such as sync, lie somewhere in the range of zero to n.
To accommodate the interlaced format, the modulus of the horizontal counter is changed n/2 and the modulus of the vertical counter is changed to 2m. This results in a generation of the horizontal events at twice the frequency.
Figure 9-10 Interlaced Scan Format
Figure 9-11 shows the relationship between events in a single horizontal scan and the sense of the least-significant bit of the vertical counter (note that the vertical counter increments whenever the horizontal counter reaches its modulus). It is the sense of the vertical counter least-significant bit that identifies whether a horizontal event is in an odd or even field. When the least- significant bit is one, the field is odd; when the least-significant bit is zero, the field is even.
Note that both odd and even events are possible within a scan and that it is necessary to choose the appropriate one. This is done by admitting another datum. Recall that the vertical counter is also a modulo n counter and that, in this case, the modulus is set to 2m. This value is significant since it represents the number of vertical lines per field, required by the specific display format, multiplied by two.
Figure 9-11 Cursor Processor Single Horizontal Scan
The counter reaches its modulus when 2m \xb4 n/2 scan lines have been produced. When the modulus 2m is reached, the counter is reset to zero and a field bit is toggled. The value of this field bit and the value of the vertical counter least-significant bit determine if the odd-numbered or even-numbered horizontal event will be chosen at any given point. Thus, the correct event, odd or even, is always chosen and there is only one such event in the range of zero to n.
The problem with this scheme is that the cursor origin may be placed anywhere in the range of zero to n, but the horizontal counter only produces values in the range of zero to n/2, and it does so twice per horizontal scan. Therefore, if x is the abscissa of a point, in image coordinates, where the cursor origin is to be placed and if x \xa3 n/2, then the cursor origin may appear in two places in a horizontal scan. Otherwise, if x n/2, the cursor will not appear at all.
The cursor processor logic, shown in Figure 9-12, consists of six basic modules: Address Math, Comparator, Cursor Entry state machine, X Address state machine, Data Math, and Y Address state machine. These modules are described following the figure.
Figure 9-12 Cursor Processor Block Diagram
The Address Math module is the solution to the problem of accommodating interlaced scanning. The module transforms the cursor origin abscissa so that it can be directly compared to the values produced by the horizontal counter. It performs the transformation during the vertical interval, where there is sufficient time.
Figure 9-13 shows the horizontal aspect of a hypothetical interlaced scanning format. In this example, a horizontal scan consists of 14 elements, numbered 00 through 0D. The figure also shows the relationship of all possible cursor origin abscissas to the contents of the horizontal counter and the least-significant bit of the vertical counter. The least-significant bit of the vertical counter identifies the odd and even horizontal scans. Note that the horizontal counter cycles through its modulus, 06 in this example, twice for each complete horizontal scan.
Figure 9-13 Hypothetical Interlaced Scanning Format
As shown in the figure, a direct comparison of cursor origin and horizontal counter abscissas is possible for all values where the cursor origin abscissa is less than or equal to the modulus of the horizontal counter (this occurs in the first half of the horizontal scan). However, there can be no direct comparison where the cursor abscissa is greater than the horizontal counter modulus (as in the second half of the scan).
The address math module solves this problem through a simple subtraction followed by a multiplexer to choose either the difference or the minuend for the result. If the cursor origin abscissa is less than or equal to the modulus of the horizontal counter (indicating that the cursor origin is in the left half of the screen), the address math module performs the following subtraction:
a - b - 1
where
a is the cursor origin abscissa
b is the horizontal counter modulus
Figure 9-14 shows the result of this subtraction. For all values of abscissa that are less than or equal to the modulus, a negative difference results. Here, only the sign bit is of use For all values of abscissa that are greater than the modulus, the sign of the difference is positive and the magnitude is correct for direct comparison with the horizontal counter. The sign bit is used to choose either the difference of the abscissa and the modulus if the modulus is smaller, or the minuend if the modulus is larger. Note that the sign bit behaves much like the least-significant bit of the vertical counter shown in Figure 9-13.
Figure 9-14 Result of Subtracting Horizontal Counter Modulus from Cursor Origin Abscissa and Subtracting One
The address math module, shown in Figure 9-15, is implemented with a full adder that performs signed, diminished radix arithmetic. A slight modification has been made to yield the function a - b - 1 and opposed to simply a - b. This is done by making the carry input of the least-significant bit zero as opposed to one.
Figure 9-15 Address Math Module Block Diagram
The n shifter module in Figure 9-15 resolves the difference in resolution of the horizontal counter and the software-supplied abscissa by arithmetic means. The frequency of the video clock input to LeoCross is always one half of the pixel frequency (f/2) and this frequency may be further reduced by the programmable frequency prescaler (see "Horizontal Synchronization" on page 9-63). The frequency prescaler offers four divisors: 1, 2, 4, or 8. Consequently, to reconcile the different resolutions, the hardware divides the software-supplied cursor abscissa by either 1, 2, 4, or 8.
The divider is built from multiplexers whose data selection controls are connected to the signals that control the pre-scaler and whose data inputs are connected in a way that affects the required right-shift operations. See Figure 9-16. This allows the division to be performed in a static fashion without any explicit process controls.
Figure 9-16 n Shifter Module Block Diagram
The horizontal counter operates at some fraction of the pixel frequency and, therefore, counts groups of pixels rather than individual pixels. The number of pixels in a group is equal to the prescale selection:
The integer portion of the quotient reveals the number of the pixel group within which the abscissa is located. Figure 9-17 shows these relationships and the quotient is calculated, for example, for a dividend of 11 and prescale selections of 1, 2, 4, and 8.
Figure 9-17 Relationship of Abscissa Within Pixel Group
The two outputs of the address math module, integer and fraction, provide all the information necessary to place the cursor origin at the correct point in the horizontal dimension. The integer portion of the quotient is compared, in the comparator module, to the value from the horizontal counter. At some point, equality is detected, indicating that the correct pixel group position has been found. All that remains is to find the correct origin position within that group of one, two, four, or eight pixels.
The fractional portion of the quotient represents the number of pixels (or locations in the horizontal dimension) by which data must be offset to achieve correct alignment. The largest possible ratio of pixel to horizontal counter frequencies is eight. This means that perfect alignment can be detected for all values of abscissas that are evenly divisible by eight, in the worst case. Therefore, there are seven intermediate locations, which are specified by the fractional portion of the quotient.
Increasing the 32-bit cursor word size by seven bits yields a 39-bit field. Then the fractional portion of the quotient can be used to control the number of places that the 32-bit cursor data field is shifted within the 39-bit field, as shown in Figure 9-18.
Figure 9-18 Cursor Data Alignment within a Larger Word
The comparator module compares
When the values compare, the correct pixel group has been found and the Comparator generates the comp signal to the Cursor Entry state machine.
The cursor entry state machine introduces wait states in units of 2/f and controls the extraction process. The entry state machine determines the starting point of data extraction based on the two-bit fractional output of the address math module. The fractional portion of the quotient represents the number of two-pixel groups by which data must be offset in order to achieve correct alignment. As shown in Figure 9-19, the 32-bit cursor word is shifted 0 pixels for a fraction of 0, two bits for a fraction of 1, four bits for a fraction of 2, and six bits for a fraction of 3.
Figure 9-19 Cursor Data Alignment on Two Pixel Boundaries
The entry state machine is shown in Figure 9-20. The address math module fractional output determines whether the entry state machine takes zero, one, two, or three clocks to start the extraction. For example, for a fraction of 3, the entry state machine makes the transition from state ent0 to state ent1, then traverses states ent2, ent3, and finally ent4. On the transition into state ent4, the entry state machine generates the pstart signal. In state ent4, the entry state machine generates the start signal.
The entry state machine remains in state ent4 until it receives the return signal from the X address state machine.
Figure 9-20 Cursor Entry State Machine
The cursor X address state machine, shown in Figure 9-21, consists of 16 states, one for each pixel pair in the X row of the pixel RAM. The X address state machine starts the sequence of 16 states when it receives the start signal from the entry state machine. The state machine continues to the next state on each subsequent clock cycle. Each state generates a unique multiplex output signal to the data math module.
In state ext10, the X address state machine generates the return signal to the entry state machine. The next clock cycle after generating return, it asserts yadv (Y advance) to the cursor Y address state machine.
Figure 9-21 Cursor X Address State Machine
Figure 9-21 Cursor X Address State Machine (Continued)
Figure 9-21 Cursor X Address State Machine (Continued)
The Data Math module converts the 32-bit cursor color data and cursor enable data into two-bit chunks. The two-bit chunks are shifted out of the module serially. The Data Math module, shown in Figure 9-22, contains four shifters; two each for the cursor enable data and the cursor color data.
At this point in the cursor control logic, the cursor data must be shifted by either zero or one bit position, depending on the state of the frac (fraction) signal (it may help to review Figure 9-19 on page 9-39). If a one-bit shift is needed, the Data Math module inserts the necessary zero bit into the first position, then begins shifting the data bits to the outputs, two bits at a time.
The zero-bit filler state and the controls for shifting are provided by the X address state machine. The frac signal from the Address Math module, the least-significant bit of the fractional component of the quotient, determines whether or not to fill and shift.
Figure 9-22 Data Math Module Block Diagram
The Data Math module shifters are simply multiplexers. Figure 9-23 shows the a simplified form of one of the four odd pixel shifters and one of the four even pixel shifters.
With the frac0 signal low, the mux0 and mux1 signals control the output of the top four pixels of the multiplexers - odd bits out of the odd pixel shifter, even bits out of the even pixel shifter.
With the frac0 signal high, the shifters reverse roles - odd bits out of the even pixel shifter, even bits out of the odd pixel shifter. Note that, with the frac0 signal high, the first pixel out of the even pixel shifter is a hard-wired zero bit. This is the zero filler bit described earlier.
Figure 9-23 Data Math Module Shifters (Simplified)
The cursor Y address state machine, shown in Figure 9-24, is slightly more complicated than the X address state machine. The Y address state machine controls the generation of the cursor RAM Y addresses for either the interlace mode or the non-interlace mode.
Figure 9-24 Cursor Y Address State Machine Block Diagram
As shown, the Y address state machine consists of two parts: the state machine and a normalize module.
The Y address state machine, shown in Figure 9-25, consists of 32 states, one for each pixel in the Y dimension of the pixel RAM. In the non-interlaced mode, the state machine increments one state at a time through all 32 states. In the interlaced mode, the state machine increments one state at a time through 16 states.
The Y address state machine starts the sequence when it receives the yadv signal from the X address state machine. Each state generates an address to the normalize module.
Figure 9-25 Cursor Y Address State Machine
Figure 9-25 Cursor Y Address State Machine (Continued)
Figure 9-25 Cursor Y Address State Machine (Continued)
The normalize module provides two functions:
Address selection. Shown in simplified form in Figure 9-26, the normalize module selects either the address from the state machine or the address from the cursor address pointer register, under control of the transfer signal. The transfer signal is merely the inverse of the cursor-enable signal (crsen).
Figure 9-26 Normalize Module Address Selection
Interlaced addressing. For interlaced operation, the normalize module performs some necessary shift and add operations on the state machine address. These operations are necessary to accommodate the alternate even and odd addresses required by interlaced operation.
In interlaced operation, the state machine generates 16 sequential cursor Y addresses, rather than 32 as with non-interlaced operation. The interlaced addresses must also be increment by two so as to address all the even or all the odd rows. So, in interlaced mode, the state machine produces 16 sequential addresses (00 through 15), and the normalize module produces 16 even (00, 02, 04, etc.) or 16 odd (01, 03, 05, etc.) addresses. This is shown in Table 9-9. The selection of whether the normalize module produces odd or even addresses is under control of the field signal.
----------------------------------------------
Address from Even Interlace Odd Interlace State Machine Address Address ----------------------------------------------
00 00 01
01 02 03
02 04 05
03 06 07
. . .
. . .
. . .
0F 30 31
----------------------------------------------
To generate the correct addresses in interlace mode, the normalize module shifts the incoming address bits one space to the left and, depending on the state of the field signal, either adds one to the bits (odd fields) or doesn't (even fields). See Table 9-10.
-------------------------------------------------------------------------------------------
Input Adrs. from State Resulting Address Machine -------------------------------------------------------------------------------------------
Adrs. Bits Result of Left field = 0 field = 1 Shift No Add Add +1 -------------------------------------------------------------------------------------------
00 0 0 0 0 0 0 0 0 0 0 0 1
01 0 0 0 0 1 0 0 0 1 0 2 3
02 0 0 0 1 0 0 0 1 0 0 4 7
03 0 0 0 1 1 0 0 1 1 0 6 9
. . . . .
. . . . .
. . . . .
0F 0 1 1 1 1 1 1 1 1 0 30 31
-------------------------------------------------------------------------------------------
LeoCross generates the video signals to control several different video applications, such as 1280 \xb4 1024 at 76 Hz, non-interlaced and 1152 \xb4 900 at 76 Hz, non-interlaced. Several other video applications are supported. To support the many screen configurations, the Video Timing Generator consists of several programmable registers. Each event has a turn-on pixel point and a turn-off pixel point.
Each pixel on the screen has an x address, the pixel number on a line, and a y address, the line number the pixel is on. The top left corner of the screen is pixel number 0 on line 0. The pixel number increases from left to right and the line number increases from top to bottom.
To keep track of the pixel or group of pixels being processed, a vertical counter, a line counter or an x-address counter, are used. The first display pixel of the first line starts at the same rising edge of the clock that disables the vertical blanking signal. At that clock edge, both counters are set to zero - the pixel group 0 at line 0 is being processed. When the counter's values match the values of the event's registers, the event's signals are set or reset, depending on the types of registers.
A turn-on register and a turn-off register are two of the types of registers used in the Programmable Video Timing Generator. When values of the counters match the contents of the turn-on register, the event's signals are active at the next rising edge of the clock pulse. When values of the counters match the contents of the turn- off register, the event's signals are disabled at the next rising edge of the clock pulse. Figure 9-27 shows how the pixel location is generated. The values used to program the turn-on and turn-off are shown in tables in "Functional Timing" on page 9-88.
Figure 9-27 Pixel Location Generator
There are eight events in the Video Timing Generator, as shown in Figure 9-28:
The equalization pulse is enabled or disabled by bit 6 in Configuration Register #0.
Figure 9-28 Events Generator
The serration pulse is enabled or disabled by bit 5 in Configuration Register #0.
The control block uses these signals and control signals from the Configuration register #0 to generate the video signals and control signals. The CBLANK signal is a composite blanking signal, which is a combination of the vertical blanking signal and the horizontal blanking signal. Its polarity can be set to either active high or active low.
The control block also generates the composite sync, CSYNC, which is a combination of the vertical sync signal, the equalization signal, the serration signal, and the horizontal sync signal. Its polarity can also be set to either active high or active low.
The control block can request data from the VRAMs. It is therefore responsible for generating the VRAM shift-clock enable to an external logic block. The external logic block generates the shift-register clock. The VRAM shift-register output enable can always be active.
LeoCross is responsible for asking the LeoDraw ASICs to shift new data into the VRAM shift registers. LeoCross generates the XFER_REQ code, depending on the monitor in use, as follows:
The code generation is summarized in Table 9-11.
Table 9-11 XFER_REQ<2:0 Code Generation
-------------------------------------------------------------------------------------
Monitor Every VS Code Every odd/right Every even/left Every HS Code Skip Every HS VS Code VS Code -------------------------------------------------------------------------------------
NSNI 0x6 N/A N/A 0x5 None
NSI N/A 0x7 0x6 0x5 None
SNI 0x7 0x6 0x4 Fourth
-------------------------------------------------------------------------------------
The Video Support Logic, shown in Figure 9-29, contains the Retrace Counter and Refresh Counter.
The Retrace Counter is a 16-bit counter that is reset by system reset. Once system reset is disabled, the Retrace Counter counts up every time a frame is displayed. For a NSNI monitor, the counter is incremented by each vertical sync signal. For a NSI or SNI monitor, the counter is incremented every other vertical sync.
The value in this counter can be read via the CX Bus by setting a bit in the Configuration register #0, bit 15. At the next rising edge of the pixel/5 clock after the bit is set, the counter value is registered. The control bit is reset at the following rising edge of the pixel/5 clock. The value remains in the register until the next enable is set.
The Refresh Counter, a 10-bit register, keeps track of the refresh period for LeoDraw. The maximum period between each refresh is a function of the system clock. With a system clock of 40 nanoseconds, the period is 1024 \xb4 40, or 41 microseconds between each refresh cycle. The current specification is 512 refresh cycles for every 8 milliseconds, which is 15.6 microseconds between each refresh cycle. The counter starts when the Configuration register #0 bit 14 is set, and continues counting until the bit is reset.
Figure 9-29 Video Support Logic Block Diagram
The LeoCross Video Timing Generator creates synchronization signals that are asserted on five pixel boundaries. The RAMDAC requires that events be placed on two pixel boundaries. To provide synchronization, LeoCross uses two state machines that regulate the data extraction process, Exmach and Wmach, and a clock pre-scaler.
The two state machines are operated from a clock that is derived from the same clock that controls the loading of pixel data into the RAMDAC (DAC_LD and PIX_CLK_DIV2). The clock prescaler is programmable, via the Video Clock Generator Register, to divide the PIX_CLK_DIV2 clock by 1, 2, or 4. The rate at which the state machines operate is determined by the screen resolution. Figure 9-30 elaborates a little more on the clock prescaler.
Note that the extraction state machines operate at the pixel clock rate divided by two. The VTG operates at some multiple of that clock. For example, for a screen resolution of 1280 by 1024 at 67 Hz, the pixel clock is 135 MHz (f), the output of the RAMDAC into LeoCross (DAC_LD) is 67.5 MHz (f/2),the clock to the state machines is 67.5 MHz, and the clock to the VTG is 16.875 MHz.
The Pixel Clock Synthesizer is described in more detail in Chapter 11, "Pixel Clock Synthesizer."
Figure 9-30 LeoCross Clock Prescaler
Since the Video Timing Generator sync generator and the two state machines operate at different clock rates, it is necessary to describe the timing for determining the starting point for data extraction. Figure 9-31 shows three timing possibilities.
Case 1 in Figure 9-31 shows the relationship of an extraction signal to the sync generator clock to the two state machines when the ratio of the synch generator clock to the state machine clock is 1:1. Here, the synch generator produces the start signal at some horizontal counter value and the signal is detected by Exmach and Wmach on the subsequent clock edge. Detection can occur at only one point in the clock stream.
Figure 9-31 Data Extraction - Three Clocking Cases
In cases 2 and 3 in Figure 9-31, the ratios of the clock are 2:1 and 4:1 respectively. In cases 2 and 3, there is more than one point at which the state machines can detect the start signal. This variability causes changes in the position of pixels relative to horizontal blanking.
The Exmach state machine, shown in Figure 9-32, extracts image or overlay data and generates signals that control the 5:2 serialization multiplexer.
Figure 9-32 Exmach State Machine Block Diagram
The correct start point for data extraction is established by the state machine entry sequence, as shown in Figure 9-33. The entry sequence is a maximum of four states, this being the highest permitted ratio of synch generator and machine clocks. The point in the sequence at which execution jumps to the prime sequence is determined by the value of the Clock Prescaler field of the Video Clock Generator Register.
Figure 9-33 Exmach State Machine - Entry Sequence
Once the entry sequence is completed, Exmach enters the prime sequence, as shown in Figure 9-34. This sequence extracts the first two pixel groups from the VRAM in preparation for the extraction sequence and 5:2 serialization process.
Figure 9-34 Exmach State Machine - Prime Sequence
Throughout the extraction process, Figure 9-35, the loop counter tallies the number of pixel groups (each group consists of ten pixels) that have been extracted. When the counter underflows, Exmach enters the halt sequence.
Figure 9-35 Exmach State Machine - Extraction Sequence
In the halt sequence, Figure 9-36, the data remaining in the pipeline is processed.
Figure 9-36 Exmach State Machine - Halt Sequence
The Wmach state machine, Figure 9-37, extracts WID information and regulates the serial output enable controls for the VRAM which contains pixel data. The WID information contains encoded data that controls the LeoCross crossbar switch mechanism. This information is encoded in the Window ID planes (WID) of the Frame Buffer and is transformed, as required, by the LeoCross WID look-up table.
Due to the nature of the crossbar and serialization mechanisms, the Wmach state machine must extract the WID data from the Window ID planes in advance of the pixel data.
Figure 9-37 Wmach State Machine Block Diagram
Figure 9-38 Wmach State Machine Block Diagram - WID/FC Pipeline
The Wmach state machine input signals, shown as "SOE Selects from WID/FC Pipeline" on the left side of Figure 9-37, is the WID information. The LXinA0 and LXinB0 registers provide information pertaining to pixels in each of the five banks of the Frame Buffer. Together, LXinA0 and LXinB0 provide information for ten pixels.
The provided WID information, along with the state of the Wmach state machine, allows Wmach to select one of three segments of the Frame Buffer memory asserting the appropriate Serial Output Enable (SOE) signal. The three segments are the Overlay Buffer, Image Buffer A, and Image Buffer B.
Figure 9-39 shows the convention for naming the WID input signals.
Figure 9-39 Wmach State Machine Input Signals
The input signals are as follows:
The Wmach state machine produces three Serial Output Enable signals for each of the five pixel banks for a total of 15 signals. However, due to the nature of the state machine and timing considerations, Wmach produces a total of 30 signals, which are logically combined to produce the required 15 signals.
The 30 signals are divided equally into two groups: Group A and Group B. Each group is associated with one of the LXin registers: Group A is associated with LXinA0, Group B is associated with LXinB0.
Figure 9-40 shows the convention for naming the output signals.
Figure 9-40 Wmach State Machine Output Signals
The output signals are as follows:
The state diagrams show that group A and group B signals occur in conjunction with certain states of Wmach. The following macro expressions describe these states:
LzA = prm8 + ext0 + ext4 + hlt3 + hlt4
LzB = ext2 + ext3 + hlt1 + hlt2 + hlt6 + hlt7
The Wmach state machine entry sequence, shown in Figure 9-41, is identical to the Exmach state machine entry sequence. The entry sequence consists of a maximum of four states, this being the highest permitted ratio of Sync Generator to Wmach clocks. The point in the sequence where execution jumps to the prime sequence is determined by the value of the Clock Prescaler field of the Video Clock Generator Register.
Figure 9-41 Wmach State Machine - Entry Sequence
Once the entry sequence is completed, Wmach enters the prime sequence. The prime sequence, shown in Figure 9-42, extracts the first three pixel groups from the VRAM in order to decode the WID contents and to prepare for Exmach pixel extraction and subsequent serialization.
Figure 9-42 Wmach State Machine - Prime Sequence
Throughout the extraction sequence, Figure 9-43, the Loop Counter tallies the number of pixel groups (each group consists of ten pixels) that have been extracted. When the counter underflows, Wmach enters the halt sequence.
Figure 9-43 Wmach State Machine - Extraction Sequence
In the halt sequence, Figure 9-44, data remaining in the pipeline are processed.
Figure 9-44 Wmach State Machine - Halt Sequence
The following pages show the timing for the Programmable Video Timing Generator.
Figure 9-45 shows the horizontal timing variables. Table 9-12 lists the specifications for the horizontal timing.
Figure 9-45 Horizontal Timing Variables
Table 9-12 Horizontal Timing
--------------------------------------------------------------------------------------------------------
Monitor Event Names Pixel Loc. On Pixel Loc. Off No. of Pixels Period (mS) --------------------------------------------------------------------------------------------------------
1280 \xb4 1024 @ 76 Hz Valid pixel (vp) 0 159 1280 9.481
non-interlace
135 MHz/Pixel (Video
clock: 135 MHz/8 =
16.875 MHz)
Horz. blank (hb) 159 207 384 2.844
Horz. sync (hs) 163 171 64 0.474
Total pixels 1664 12.326
1280 \xb4 1024 @ 67 Hz non- Valid pixel (vp) 0 159 1280 10.940
interlace 117 MHz/pixel
(Video clock: 117 MHz/8
= 14.625 MHz)
Horz. blank (hb) 159 203 352 3.008
Horz. sync (hs) 161 175 112 0.9573
Total pixels 1648 14.086
1152 \xb4 900 @ 66 Hz Valid pixel (vp) 0 143 1152 12.387
93 MHz/Pixel
Non-interlace
(Video clock: 93 MHz/8 =
11.625 MHz)
Horz. blank (hb) 143 187 352 3.7858
Horz. sync (hs) 147 163 128 1.376
Total pixels 1504 16.172
1152 \xb4 900 @ 76 Hz Valid pixel (vp) 0 143 1152 10.971
105 MHz/Pixel
Non-interlace
(Video clock: 105 MHz/8
= 13.125 MHz)
Horz. blank (hb) 143 183 320 3.048
Horz. sync (hs) 145 161 96 0.9143
Total pixels 1474 14.038
1024 \xb4 768 @ 76 Hz Valid pixel (vp) 0 128 1024 12.136
84.375 MHz/Pixel
Non-interlace
(Video clock: 84.375
MHz/8 = 10.547 MHz)
Horz. blank (hb) 128 170 336 3.982
Horz. sync (hs) 132 148 128 1.517
Total pixels 1360 16.118
1024 \xb4 768 @ 60 Hz Valid pixel (vp) 0 128 1024 15.754
65 MHz/Pixel
Non-interlace
(Video clock: 65 MHz/8 =
8.125 MHz)
Horz. blank (hb) 128 168 320 4.923
Horz. sync (hs) 131 148 136 2.092
Total pixels 1344 20.677
960 \xb4 680 @ 108 Hz Valid pixel (vp) 0 119 960 9.61
99.9 MHz/Pixel
Stereo
(Video clock: 99.9
MHz/8 = 12.4875 MHz)
Horz. blank (hb) 119 159 320 3.203
Horz. sync (hs) 127 135 64 0.641
Total pixels 944 12.813
Shutter switch Switch at 54 MHz
960 \xb4 680 @ 112 Hz Valid pixel (vp) 0 109 960 9.482
101.25 MHz/Pixel
Stereo
(Video clock: 101.25
MHz/8 = 12.625 MHz)
Horz. blank (hb) 119 155 288 2.844
Horz. sync (hs) 122 128 48 0.474
Total pixels 1248 12.326
Shutter switch Switch at 56 MHz
768 \xb4 576 @ 50 Hz Valid pixel (vp) 0 147 768 51.3
14.75 MHz/Pixel
Interlace
(Video clock: 14.75/2 =
7.375 MHz)
Horz. blank (hb) 147 235 176 11.932
Horz. sync (hs) 158 193 70 4.746
Total pixels 944 64.0
640 \xb4 480 @ 60 Hz Valid pixel (vp) 0 124 640 52.16
12.27 MHz/Pixel
Interlace
(Video clock: 12.27
MHz/2 = 6.135 MHz)
Horz. blank (hb) 124 194 140 11.41
Horz. sync (hs) 133 161 58 4.727
Total pixels 780 63.57
--------------------------------------------------------------------------------------------------------
Figure 9-46 shows the vertical timing variables. Table 9-13 lists the specifications for the vertical timing.
Figure 9-46 Vertical Timing Variables
Table 9-13 Vertical Timing
-------------------------------------------------------------------------------------------------------
Monitor Event Names Line Loc. On Line Loc. Off No. of Lines Period (mS) -------------------------------------------------------------------------------------------------------
1280 \xb4 1024 @ 76 Hz Visible lines (vl) 0 1023 1024 12.621
135 MHz/pixel
Non-interlace
Vert. Blank (vb) 1022 1064 42 0.5176
Vert. Sync (vs) 1024 1032 8 0.0986
Total lines 1066 13.138
1280 \xb4 1024 @ 67 Hz Visible lines (vl) 0 1023 1024 14.283
117 MHz/pixel
Non-interlace
Vert. Blank (vb) 1022 1073 51 0.711
Vert. Sync (vs) 1024 1032 8 0.112
Total lines 1075 14.995
1152 \xb4 900 @ 76 Hz Visible lines (vl) 0 899 900 12.527
105.71 MHz/pixel
Non-interlace
Vert. Blank (vb) 898 941 43 0.598
Vert. Sync (vs) 900 908 8 0.112
Total lines 943 13.126
1152 \xb4 900 @ 66 Hz Visible lines (vl) 0 899 900 14.555
93 MHz/pixel
Non-interlace
Vert. Blank (vb) 898 935 37 0.598
Vert. Sync (vs) 900 904 4 0.0647
Total lines 937 15.153
1024 \xb4 768 @ 76 Hz Visible lines (vl) 0 767 768 12.379
84.375 MHz/pixel
Non-interlace
Vert. Blank (vb) 766 803 37 0.596
Vert. Sync (vs) 768 772 4 0.064
Total lines 805 12.976
1024 \xb4 768 @ 60 Hz Visible lines (vl) 0 767 768 15.879
65 MHz/pixel
Non-interlace
Vert. Blank (vb) 766 804 38 0.786
Vert. Sync (vs) 768 774 6 0.124
Total lines 806 16.666
960 \xb4 680 @ 108 Hz Visible lines (vl) 0 679 680 8.713
99.9 MHz/pixel
Stereo
Vert. Blank (vb) 678 719 41 0.525
Vert. Sync (vs) 681 685 4 0.051
Total lines 721 9.238
Shutter switch Between 680 and 719
960 \xb4 680 @ 112 Hz Visible lines (vl) 0 679 680 8.382
101.25 MHz/pixel
Stereo
Vert. Blank (vb) 678 720 42 0.518
Vert. Sync (vs) 680 688 8 0.0986
Total lines 722 8.899
768 \xb4 576 @ 50 Hz Visible lines (vl) 0 575 576 36.864
14.75 MHz/pixel
Interlace
Vert. Blank (vb) 575 623 48 3.072
Vert. Sync (vs) 580 585 5 0.320
Total lines 624 39.936
640 \xb4 480 @ 60 Hz Visible lines (vl) 0 479 480 30.510
12.2727 MHz/pixel
Interlace
Vert. Blank (vb) 479 523 44 2.797
Vert. Sync (vs) 485 491 6 0.381
Total lines 524 33.307
-------------------------------------------------------------------------------------------------------
For interlaced monitors, such as NTSC and PAL, additional timing specifications are required. Figure 9-47 shows the interlaced monitor timing. Table 9-14 lists the interlaced monitor timing specifications.
Figure 9-47 Interlaced Monitor Timing Variables
Table 9-14 Interlaced Monitor Timing
-----------------------------------------------------------------------------------
Event Names Line Loc. On Line Loc. Off No. of Lines Period (mS) -----------------------------------------------------------------------------------
Equalization interval #1 240 242 3 190.7
Equalization interval #2 246 248 3 190.7
Serration interval 243 245 3 190.7
Event Names Pixel Loc. On Pixel Loc. Off No. of Pixels Period (mS)
Equalization pulse width 133 139 30 2.45
Serration pulse width 133 123 + 4 54 4.40
-----------------------------------------------------------------------------------
Table 9-15 shows some additional Leo video timing specifications not shown in the previous tables, such as:
Table 9-15 Additional Leo Video Timing Specifications
----------------------------------------------------------------------------------------------------------------------
Pixel Rate Hfp Hsync Hbp Vfp Vsync Vbp ----------------------------------------------------------------------------------------------------------------------
Resolution (MHz) Pixels msec Pixels msec Pixels msec Lines msec Lines msec Lines msec ----------------------------------------------------------------------------------------------------------------------
640 \xb4 480 @ 60 12.27272720 1.63058 4.72662 5.052 3 190.667 3 190.66716 1017.0
768 \xb4 576 @ 50 14.750022 1.49270 4.74684 5.695 2.5 160.0 2.5 160.020 1280.0
960 \xb4 680 @ 108 99.900064 0.64164 0.641192 1.922 3 34.438 4 51.25134 435.636
960 \xb4 680 @ 112 101.250024 0.23748 0.474216 2.133 2 24.652 8 98.6132 394.44
1024 \xb4 768 @ 60 65.000024 0.369136 2.092160 2.462 3 62.031 6 124.06229 599.63
1024 \xb4 768 @ 76 84.37532 0.379128 1.517176 2.086 2 32.24 4 64.4731 499.7
1152 \xb4 900 @ 66 93.000032 0.344128 1.376192 2.065 2 32.344 4 64.68831 501.333
1152 \xb4 900 @ 76 105.750016 0.15196 0.907208 1.967 2 27.839 8 111.35733 459.348
1280 \xb4 1024 @ 67 117.000016 0.137112 0.957224 1.915 2 27.897 8 111.5941 571.897
1280 \xb4 1024 @ 76 135.000032 0.23764 0.474288 2.133 2 24.65 8 98.6132 394.4
----------------------------------------------------------------------------------------------------------------------
