DISPLAYCONTROLLERDATASHEETDOC
DISPLAYCONTROLLERDATASHEETDOC
DISPLAYCONTROLLERDATASHEETDOC
1
1
1
Display Controller Data Sheet
Lissy Bland and Jeff Hoel
Dragon-88-06 March 1988 
© Copyright 1988 Xerox Corporation. All rights reserved.
Keywords: display controller, color monitor, color maps, color, Dragon, DynaBus, DBus;
Maintained by: Bland.pa, Hoel.pa
XEROX   Xerox Corporation
    Palo Alto Research Center
    3333 Coyote Hill Road
    Palo Alto, California 94304

For Internal Xerox Use Only
Display Controller Data Sheet
1.0 Brief Description
The Dragon Display Controller displays an image stored in main memory on the screen. A processor can communicate with the Display Controller over the DynaBus, using IOWrite and IORead commands, to initialize the Display Controller, change images, move the cursor, or read status registers. Once the Display Controller is initialized, it acts autonomously to fetch the image, using ReadBlock commands to display the image on the screen. The output of the Display Controller serves as input to an industry standard colormap/DAC chip, which converts digital pixels into analog red, green, and blue signals for a color monitor.
In a typical application, the Display Controller might fetch more than 100 Megabytes of image data per second, consuming more than half the bandwidth of the DynaBus. To achieve this throughput, the Display Controller must be able to make a new request before being granted the previous request. There can be up to six such outstanding requests. To minimize the impact of this traffic on the latency of other bus requests, Display Controller requests are normally made at lowest priority, so that the requests of other devices can be granted first. The Display Controller has an on-chip FIFO, making it possible to output pixels to the screen at a predictible rate even though they are being fetched at a highly variable rate. If the FIFO becomes dangerously close to empty, the Display Controller issues requests at high priority until that condition no longer exists.
The format of the screen is determined by a microprogrammed sequencer within the Display Controller; both interlaced and non-interlaced formats can be supported. Pixels can be 1, 2, 4, or 8 bits. A three-color, 16 x 16-pixel cursor is also supported. It is interesting to note that the Display Controller does not participate in any way in creating the image to be displayed. That is the job of the processors.
2.0 Pin-Out
[Artwork node; type 'Artwork on' to command tool]
3.0 Block Diagram of the Chip
[Artwork node; type 'Artwork on' to command tool]
4.0 Detailed Description of Each of the Functional Blocks
4.1 DynaBus Transactions Involving the Display Controller
Command Generator
The Command Generator initiates transactions on the DynaBus for two reasons: 1) to fill its Video Data FIFO using the ReadBlockRequest (RBRqst) command; and, 2) to interrupt a processor, using either the IOWriteRequest (IOWRqst) or BIOWriteRequest (BIOWRqst) command, depending upon the contents of the Control Parameters register (see Section 4.5). These commands are paired with replies that are named ReadBlockReply (RBRply), IOWriteReply (IOWRply) and BIOWriteReply (BIOWRply), respectively.
Command Decoder
The Command Decoder accepts two commands: IOReadRequest (IORRqst) and IOWriteRequest (IOWRqst). The commands are paired with a replies, named IOReadReply (IORRply) and IOWriteReply (IOWRply), respectively. These commands are used to read and write the Display Controller's internal registers, to write its internal memories, and to download information to an external colormap/DAC chip. (For a detailed description of the internal registers and memories, see Section 4.3. The colormap/DAC interface is described in Section 4.5.)
The Display Controller can process at most one IO command at a time. It must not receive a new IO request before it has issued a reply to the previously received IO request, if any. System software must assure that this restriction is observed.
Dynabus Commands
All DynaBus requests interpreted by the Display Controller are two cycles long. The first cycle contains 32 bits of header information and a 32-bit address. (See Figure 1). The use of the second is command dependent.
[Artwork node; type 'Artwork on' to command tool]
Figure 1: Encoding of Header Cycle
Replies to these DynaBus commands may be two or five cycles long. Note that bits 0-4 and 7-63 of the reply's first cycle are identical to those bits in the request packet. All requests generated by the Display Controller are in kernel mode (Mode/Fault=0), and the Display Controller expects all requests it receives to be in kernel mode, as well. If the Display Controller receives an IOWRqst or IORRqst in user mode (Mode/Fault = 1), the reply indicates an error by setting the Mode/Fault bit of the header cycle to 1, and setting the FaultCode to 1, IOAccessFault. (See the DynaBusLogicalSpecifications, Appendix C for more information about the Fault Codes.) If the Display Controller receives an IOWRply, BIOWRply, or RBRply with Mode/Fault=1 (fault), the FaultCode is ignored.
Here are the specifications for the DynaBus commands that the Display Controller generates or decodes:
4.1.1 ReadBlockRequest (RBRqst)
[Artwork node; type 'ArtworkInterpress on' to command tool]
4.1.2 ReadBlockReply (RBRply)
If there is no error, the second through fifth cycles contain data.
[Artwork node; type 'ArtworkInterpress on' to command tool]
When the ReadBlockRequest results in an error, the FaultCode is always IOAccessFault, 001.
[Nectarine figure; type 'Artwork on' to a CommandTool]
4.1.3 IOReadRequest (IORRqst)
[Artwork node; type 'ArtworkInterpress on' to command tool]
4.1.4 IOReadReply (IORRply)
No Error:
[Artwork node; type 'ArtworkInterpress on' to command tool]
On Error:
[Artwork node; type 'ArtworkInterpress on' to command tool]
4.1.5 IOWriteRequest (IOWRqst)
[Artwork node; type 'ArtworkInterpress on' to command tool]
4.1.6 IOWriteReply (IOWRply)
No Error:
[Artwork node; type 'ArtworkInterpress on' to command tool]
On Error:
[Artwork node; type 'ArtworkInterpress on' to command tool]
4.1.7 BIOWriteRequest (BIOWRqst)
[Artwork node; type 'ArtworkInterpress on' to command tool]
4.2 The Display Controller IO Address Space
The Display Controller is considered a small DynaBus device, so it is allocated an IO address space of 1024 words. This address space is subdivided as follows:
Offset (hex) Use   
000-1FF Colormap/DAC; see Section 4.2.2.
200-23F Cursor Shape Memory; see Section 4.2.3.
240-27F Microcode Memory; see Section 4.2.4.
280-288 Registers; see Section 4.2.1.
289-3FF Unused
4.2.1 The Display Controller Registers
The following table describes the nine internal registers of the Display Controller. The Offset, in HEX, is relative to the base address in the IO address space.
Offset Reg Name R/W Description
280 FramePtrBase R/W 32 bits. The FramePtrBase contains the beginning block address for the information to be displayed on the screen. The image is always aligned on a block boundary, where a block is 8, 32-bit words. Because the FramePtrBase uses byte addresses, the 3 least significant bits are always zero, and actually are not stored.
281 FramePtrLimit R/W 32 bits. Contains the the block address of the last block of image data to be displayed. The 3 least significant bits are always zero, and actually are not stored.
282 InterruptStatus  R/W 6 bits. The 3, high-order bits represent the 3 Interrupts. The 3 low-order bits are a mask. A one in the mask enables the corresponding interrupt (3/0, 4/1, 5/2) to occur. A Read reads all 6 bits of the register and has the side effect of clearing the top 3 bits. A write writes only the lower 3 bits of the register.
283 BitsPerPixel R/W 2 bits. Allows the number of bits/pixel to be set as follows:
   Value Meaning
    0 1 bit/pixel
    1 2 bits/pixel
    2 4 bits/pixel
    3 8 bits/pixel
284 CursorX R/W 12 bits. The x-coordinate of the cursor. Represents non-negative value. The precise mapping from value to screen position is dependent on the microcode to some extent, but a smaller value is to the left of a larger value and the units are pixels.
285 CursorY R/W 12 bits. The y-coordinate of the cursor. Represents non-negative value. The precise mapping from value to screen position is dependent on the microcode to some extent, but a smaller value is above a larger value and the units are normally scan lines.
286 RBRqstEn R/W 1 bit. Normally, RBRqst is asserted during system initialization of the Display Controller and remains asserted thereafter.
287 VGenEn R/W 1 bit. (Video Generator Enable). This bit is used during system initialization. When VGenEn=0, the microcode's NextAddr register is reset to zero. When VGenEn=1, the NextAddr register is allowed to operate normally.
288 IntOffset R/W 10 bits. These are the 10 least significant bits, Offset, of the IOAddress of an interrupt request (IOWRqst or BIOWRqst). (The 12 most significant bits, DevType, are always 001H; the 10 remaining bits, DevNum, are supplied from DBus register 2, bits 6-15.
4.2.2 The Brooktree Bt458
An external Brooktree Bt458 colormap/DAC chip occupies address range 000-1FF. This address space is subdivided as follows:
Offset (hex) Use   
000-0FF Pixel Colormap
100-103 Overlay Colormap
104 Read Mask register
105 Blink register
106 Command register
107-1FF Unused
Figure 2 illustrates the format of the 32-bit data word that serves as input to the Pixel Colormap and Overlay Colormap. Only the least significant 8 bits of the 32-bit data word are used when loading the Read Mask, Blink, and Command registers.
[Artwork node; type 'Artwork on' to command tool]
Figure 2: The 32-bit data word
4.2.3 The Cursor Shape Memory
The cursor occupies a 16 x 16 pixel area on the screen. Two bits are used to describe each pixel, so that the cursor requires 512 bits of memory. The 512 bits are stored as 64, 8-bit words, occupying address range 200-23F. Words are stored in left-to-right (fast) and top-to-bottom (slow) order. Because two bits are stored per pixel, four values are possible. Values 1, 2, and 3 are used to specify colors, while the value 0 makes the pixel transparent. The cursor is displayed using the color/overlay facility of the Brooktree Bt458.
4.2.4 The Microcode Memory
The Display Controller contains a microprogrammed sequencer for controlling the screen format. The sequencer has an IterationCounter for setting the number of cycles each microinstruction will take and a LoopCounter which permits one level of programmed loop. Each microinstruction has a NextAddr field that specifies the next microinstruction; this field can be modified by various conditional jump mechanisms to be described below. Each microinstruction also contains a CountData field, used to load either the IterationCounter or the LoopCounter; two internal control bits; and eight control bits that control things outside the sequencer itself.
The microprogrammed sequencer operates at a rate which is 1/4th the pixel rate. For this reason, there are certain limits placed on the screen format. For example, the number of pixels in a scan line must be divisible by four. The width of the border in pixels must also be divisible by four.
The microcode memory consists of 64 words that are 28 bits wide. It occupies address range 240-27F. One IOWRqst instruction can download one word of microcode memory to the Display Controller. Figure 3 gives the format for the 28-bit microcode word.
[Artwork node; type 'Artwork on' to command tool]
Figure 3: The format of the 28-bit microcode word.
The following table lists the fields of the microcode word and their meanings:
Field Meaning
NextAddr first 6 bits. Points to the next microcode word.
CounterData next 12 bits. CounterData is used to load either the IterationCounter or the LoopCounter, depending on the value of LoadLoop in the previous microcode instruction. The value is a negative number, represented in two's complement. Subsequently the counter is incremented until it reaches a value of FFF.
LoadLoop  bit 18. If LoadLoop = 1, then on the next microde instruction LoopCounter ← CountData and IterationCounter ← FFF. If LoadLoop = 0, then on the next microcode instruction IterationCounter ← CountData.
CondJump  bit 19. Normally the address of the next microinstruction is specified by the NextAddr field of the current microinstruction. However, under certain conditions to be discussed in detail below, this address can be forced to be odd. This feature provides a kind of conditional jump capability. Here are the conditions that will force the address to be odd:
 CondJump = 1 AND LoopCounter = FFF
 CondJump=0 AND T0=1 AND (NextAddr=38 OR NextAddr = 3A)
 CondJump=0 AND T1=1 AND (NextAddr=3C OR NextAddr = 3E)
nHSync bit 20. Holds value of the nHSync bit.
nBlank bit 21. Holds value of the nBlank bit.
VideoData bit 22. If VideoData = 1, pixels are fetched from the FIFO and sent to the PixOut outputs.
CursorData bit 23. If CursorData = 1, the logic that controls the cursor display is instructed to provide cursor pixels, which are sent to the COut outputs.
Border bit 24. If Border = 1, the COut outputs are forced to 3's, regardless of the cursor. If desired, this feature can be used to display a border around the portion of the screen that contains ``real'' data.
NewLine bit 25. If NewLine = 1, LoopCounter is incremented (unless it is loaded with the contents of CountData, as specified by LoadLoop bit of the previous microinstruction). Typically, this corresponds to starting a new scan line.
nVSync bit 26. Holds value of the vHSync bit.
ProgInt bit 27. If ProgInt = 1, an interrupt request bit will be set and an interrupt will occur on the DynaBus as soon as the corresponding interrupt mask bit is set. There are 2 microcode interrupts:
 Interrupt 0:
 If NextAddr < 20H, then bit 0 of the InterruptStatus register is set. Also, as a side effect, FramePtr, the internal register that points to the next block of image data to be fetched from main memory, is initialized to the contents of FramePtrBase.
 Interrupt 1:
 If NextAddr e 20H, then bit 1 of the InterruptStatus register is set.
4.2.4.1 An Example of Microcode
The following microcode demonstrates all the functionality that would be required for a toy display with 20 visible scan lines containing pixel data and 8 scan lines during vertical retrace. Each scan line takes 16 cycles. Each visible scan line contains 32 data pixels and 8 border pixels on each side.
Adr NextAddr Assert Ctrl Bits Counters/Timers
00 Start: Jump ScnE1
  IT←-1
Vertical Retrace Interval:
02 VR1S1: Jump VR1S2 nHSync nBlank IT←-2
34 VR1S2: CJmp VR1S1,VR1E1 nBlank NewLine IT←-14
03 VR1E1: Jump VR1E2 nHSync nBlank LoadLoop IT←-1
05 VR1E2: Jump VSyI1 nHSync nBlank V.Timer←-2
06 VSyI1: Jump VSyI2 nBlank IT←-8
07 VSyI2: Jump VSyS1 nBlank nVSync IT←-6
08 VSyS1: Jump VSyS2 nHSync nBlank nVSync IT←-2
0A VSyS2: CJmp VSyS1,VSyE1 nBlank nVSync NewLine IT←-14
09 VSyE1: Jump VSyE2 nHSync nBlank nVSync LoadLoop IT←-1
0B VSyE2: Jump VSyO1 nHSync nBlank nVSync V.Timer←-2
0C VSyO1: Jump VSyO2 nBlank nVSync IT←-7
0D VSyO2: Jump VR2S1 nBlank IT←-7
0E VR2S1: Jump VR2S2 nHSync nBlank IT←-2
10 VR2S2: CJmp VR2S1,VR2E1 nBlank NewLine IT←-14
0F VR2E1: Jump VR2E2 nHSync nBlank LoadLoop IT←-1
11 VR2E2: Jump ScnS1 nHSync nBlank V.Timer←-20
Scan Line:
20 ScnS1: Jump ScnS2 nHSync nBlank  IT←-2
22 ScnS2: Jump ScnS3 nBlank IT←-1
23 ScnS3: Jump ScnS4 nBlank CursorData Border IT←-1
24 ScnS4: Jump ScnS5 VideoData CursorData Border IT←-1
25 ScnS5: Jump ScnS6 VideoData CursorData IT←-6
26 ScnS6: Jump ScnS7 VideoData IT←-1
27 ScnS7: Jump ScnS8  IT←-1
28 ScnS8: Jump ScnS9 Border IT←-2
29 ScnS9: CJmp ScnS1,ScnE1 Border NewLine IT←-1
21 ScnE1: Jump ScnE2 nHSync nBlank LoadLoop IT←-1
1A ScnE2: Jump VR1S2 nHSync nBlank ProgInt V.Timer←-2
Here is the binary encoding of the above microcode:
Hex Binary Equivalent divided into fields
 Next Addr Counter Booleans
87FFC00 100001 111111111111 0000000000
13FF8C0 000100 111111111110 0011000000
0BFC944 000010 111111110010 0101000100
17FFEC0 000101 111111111111 1011000000
1BFF8C0 000110 111111111110 0011000000
1FFE040 000111 111111111000 0000100000
23FE842 001000 111111111010 0001000010
2BFF8C2 001010 111111111110 0011000010
23FC946 001000 111111110010 0101000110
2FFFEC2 001011 111111111111 1011000010
33FF8C2 001100 111111111110 0011000010
37FE442 001101 111111111001 0000100010
3BFE440 001110 111111111001 0001000000
43FF8C0 001000 111111111110 0011000000
3BFC944 001110 111111110010 0101000100
47FFEC0 001001 111111111111 1011000000
8BFB0C0 100010 111111101100 0011000000
8BFF8C0 100010 111111111110 0011000000
8FFFC40 100011 111111111111 0001000000
93FFC58 100100 111111111111 0001011000
97FFC38 100101 111111111111 0000111000
9BFE830 100110 111111111010 0000110000
9FFFC20 100111 111111111111 0000100000
A3FFC00 101000 111111111111 0000000000
A7FF808 101001 111111111110 0000001000
83FFD0C 100000 111111111111 0100001100
6BFFEC0 011010 111111111111 1011000000
13FF8C1 000100 111111111110 0011000001
4.3 The DBus Interface
The Display Controller has 4 registers that can be initialized and/or read over the DBus. Their addresses (path numbers) are as follows:
Addr 0: Chip Identification
 16 bits, RO. Indicates the type and version of the Display Controller. The 16 bits are broken down into 3 fields: a 4-bit header, a 6-bit chip type, and a 6-bit version number. The current Chip Identification Number for the Display Controller is: 0101 0010 0000 0000.
Addr 1: DynaBus DeviceID
 10 bits, R/W. Specifies the DynaBus Device ID for the DisplayController. This is a unique identifier loaded during system initialization.
Addr 2: Control Parameters
 34 bits, R/W.
The 7 fields of this register are as follows:
[Artwork node; type 'ArtworkInterpress on' to command tool]
1. InterruptReason (5 bits):
 InterruptReason specifies the data that will be sent with an interrupt request, as follows: data = 2 (31-InterruptReason). (The processor examines InterruptStatus for further details.)  
2. Broadcast (1 bit):
 Broadcast is set to 1 for broadcast interrupts and to 0 for directed interrupts.
3. DynaBus DeviceID (10 bits):
 If Broadcast=0, DynaBus DeviceID is the DeviceID of the cache that will receive all interrupt requests from this Display Controller. If Broadcast=1, all caches receive these interrupt requests, and this field is ignored.
4. CriticalMask (7 bits):
 The CriticalMask permits software to set the level at which the FIFO is considered critically empty. For example, if the CriticalMask is set to 1100000, the FIFO is considered critically empty when it is less than 1/4 full, and the Display Controller will start making requests at high priority when the FIFO is less than 1/4 full. The following table gives the correspondence between masks and the level at which FIFO is considered empty.
Mask Level at which FIFO is considered critical
0000000 full
1000000 1/2 full
1100000 1/4 full
1110000 1/8 full
1111000 1/16 full
1111100 1/32 full
1111110 1/64 full
1111111 1/128 full
5. MaxHPR (3 bits)
 Specifies the maximum number of outstanding high priority arbitration requests. If this limit is reached, no more arbitration requests for RBRqst packets will be generated at high priority until a high priority grant is received. Since the arbiter has a hard limit of 6 such outstanding requests, and since Display Controller should be free to issue an arbitration request at any time for a reply packet or interrupt packet, it is recommended that MaxOARHP always be programmed to be d 4.
6. MaxLPR (3 bits)
 Specifies the maximum number of outstanding low priority arbitration requests. If this limit is reached, no more arbitration requests for RBRqst packets will be generated at low priority until a low priority grant is received. Since the arbiter has a hard limit of 6 outstanding requests, it is recommended that MaxOARLP always be programmed to be d 6.
7. MaxORBR (5 bits)
 Specifies the maximum number of outstanding RBRqst packets. If this limit is reached, no more RBRqst packets will be sent until a RBRply is received. The intent is to keep the Display Controller from making more requests if it is clear that the memory is not responding, but Max ORBR can be used to some extent for performance tuning. The constant represents a two's complement number; only positive numbers make sense.
Addr 3: Fault Status
 (2 bits), R). These bits get set by fault conditions and cleared by the DBus's nDReset signal. When a fault bit is asserted, SStopOut is also asserted.
bit 0 IOWRplyFault. Asserted when the reply packet to an interrupt request packet has its fault bit asserted.
bit 1 RBRplyFault. Asserted when the reply packet to a RBRqst packet has its fault bit asserted.
4.4 The Video Data FIFO
The Video Data FIFO stores pixels to be displayed on the screen. Whenever all of the conditions listed below are true, the Display Controller will issue arbitration requests for ReadBlockRequests to fill the FIFO:
1. RBRqstEn=1
 Normally, RBRqst is asserted during system initialization of the Display Controller and remains asserted thereafter.
2. FIFO not nearly Full
 Whenever the number of blocks in the FIFO plus the number of outstanding RBRqsts equals 120 or more, further arbitration requests for RBRqsts are temporarily inhibited until the FIFO becomes less full. Normally, RBRqst is asserted during system initialization of the Display Controller and remains asserted thereafter.
3. FramePtr d FramePtrLimit
 FramePtr is an internal counter that points to the next block of data to be requested. At the beginning of each frame, it is initialized to FramePtrBase. After each RBRqst, FramePtr is incremented until it goes beyond FramePtrLimit. Note that the data received from RBRqsts do not necessarily arrive in the order requested, but because data is stored in the FIFO by address, the order in which it arrives is not crucial.
 When FramePtr > FramePtrLimit, RBRqsts are also inhibited. Under certain conditions the Display Controller will make arbitration requests for a few more RBRqsts per frame than it can actually use. When the arbiter grants such an ``excess'' RBRqst, the Display Controller does not assert HeaderCycleOut, so no RBRqst is sent. The DynaBus cycles are not used.
4. (Critical AND (HPR < MaxHPR)) OR (~Critical AND (LPR < MaxLPR))
 The arbitration system on the DynaBus permits up to 6 high priority requests and 6 low priority requests to be pending from any single device. Limits lower than these may be imposed on the Display Controller via the MaxHPR and MaxLPR registers. A high priority request for a RBRqst will not be made if HPR, the internal counter that contains the number of pending high priority requests, is equal to MaxHPR. Likewise, a low priority request will not be made if LPR, the internal counter that contains the number of pending low priority requests, is equal to MaxLPR.
 Critical is an internal signal that reports whether the FIFO is critically close to empty; it determines whether an arbitration request for RBRqst should be made at high or low priority. Requests are normally made at low priority; however, if the FIFO becomes critically close to empty, requests are made at high priority until that condition is corrected.
5. ORBR < MaxORBR
 ORBR is an internal counter that contains the number of outstanding RBRqsts, that is to say, the number of RBRqsts issued by the Display Controller minus the number of RBRply's received. If this number gets too large, further RBRqsts will be inhibited. The primary reason for providing such a feature is to prevent useless bus activity when it is clear that the memory is not responding. MaxORBR could also be used for performance tuning, but that's not the main reason it's there.
4.5 Brooktree Bt458 Interface: Digital to Analog Signal Conversion
The Display Controller outputs information to the Brooktree Bt4581. The Brooktree Bt458 converts this digital information into analog voltages to be displayed on the screen. The Display Controller also loads values for the Bt458's Color and Overlay Palettes. These tables are loaded using the IOWrite commands so that the color palettes may be changed without re-initializing the system. The following table shows the connections between output wires of the Display Controller and Input wires of the Bt458. Note the following:
1. The Bt458 allows a 40-bit bus for pixels to be displayed on the screen, P0-P7(A-E), and a 10-bit bus for the cursor overlay, OL0-OL1(A-E), but that the Display Controller only uses the A-D wires of these busses. The E wires should be connected to ground.
2. Numbering conventions for the two devices are reversed: For the Display Controller, 0 is the most significant bit. For the Bt458, 0 is the least significant bit.
3. For mapping the Display Controller's one-dimensional PixOut to Brooktree's two dimensional P, Brooktree's letter dimension is the slow dimension. Thus, for example, PixOut[1] = P6A, PixOut[2] = P5A, etc. The same mapping is used for COut and OL.
—————————————————————————————————————
1"Bt451/458 125 MHz Monolithic CMOS 256 X 12/24 Color Palette RAMDACTM," Brooktree Product Databook 1988 (SanDiego, 1987), pp. 5-19 to 5-44.
 
Display Controller Bt458
DACData[0..7] D7-D0
nCE CE*
R/W (always R = low) R/W
C0, C1 C0, C1
PixOut P7-P0(A-D)
Cout OL0-OL1(A-D)
nHSync or nVSync nHSync
nBlank BLANK*
VCK LD*
4.6 The Brooktree Bt438: Pixel and Clock Control
The Brooktree Bt4382 is a clock generator for the Bt458. Its CLOCK and CLOCK* connect directly with the corresponding signals of the Bt458. The Bt438's LDD clock signal is hardwired to generate a clock that runs at 1/4 the rate that pixels are displayed on the screen. The LDD clock is connected to the LD* wire of the Bt458 and the VCK clock signal of the Display Controller.
—————————————————————————————————————
2"Bt438 250 MHz Clock Generator Chip for CMOS RAMDACsTM," Brooktree Product Databook 1988 (SanDiego, 1987), pp. 6-53 to 6-64.
 
5.0 Detailed Description of Each Pin
5.1 DynaBus Pins
The following table describes the DynaBus pins of the Display Controller:
Pin Name I/O Pin Description
RequestOut O 2 bits, indicates arbiter request code. The following values are used:
  00: no request (rescind bus hold)
  01: unused by DDC (bus hold)
  10: low priority, two-cycle request
  11: high priority, two-cycle request
SpareOut O 2 bits, driven to 0 when DataOut is driven, floated otherwise. Present only for compatibility
SStopOut O DynaBus synchronous stop request (stops arbitration). Driven when a reply packet is received with a fault indicated.
SharedOut O Always driven to 0. Present only for compatibility
OwnerOut O Always driven to 0. Present only for compatibility
HeaderCycleOut O Driven high when the header cycle of a packet is emitted on DataOut, driven low when data cycles are emitted on DataOut, floated when DataOut is floated.
ParityOut O Parity of DataOut. Not yet implemented, always driven to 0.
DataOut O 64-bit wide DynaBus data output. Floated except when Grant is assserted (with 1 cycle of pipeline delay)
Grant I Packet grant from the arbiter. All grants received by DDC are for two-cycle packets. Data emission on DataOut starts on the next cycle.
HiPGrant I Indication by arbiter that packet granted on the next cycle will be a high priority request. Valid only on the cycle preceding the beginning of a new Grant.
LongGrant I Ignored, present only for compatibility
SpareIn I 2 bits, ignored, present only for compatibility
SStopIn I Synchronous stop line from DynaBus. Ignored , present only for compatibility
SharedIn I Ignored, present only for compatibility
OwnerIn I Ignored, present only for compatibility
HeaderCycleIn I Asserted (high) on header cycles coming from the DynaBus
ParityIn I Parity on DataIn. Not yet implemented.
DataIn I 64-bit wide DynaBus data input.
Clock I DynaBus clock input. This is one of three clocks used inside the Display Controller. The other clocks are VCK, for the circuitry that must be in step with the pixel clock, and DShiftCK, the DBus clock.
CkOut O Clock feedback output. Used to adjust the clock skew based on internal clock buffering delay.
TestEn I 1 bit. This signal is used to reduce the number of pins that need to be contacted for testing purposes. It relates only to the operation of the DynaBus data lines. When TestEn is de-asserted, the DataIn and DataOut pins are completely independent of each other. When TestEn is asserted, the DataOut signals are connected internally to the DataIn pins, so that when a DynaBus request is granted, the DataIn pins are driven with the DataOut signals.
5.2 DBus Pins
The following table describes the DBus pins of the Display Controller. The reader is referred to the DBus specification for details.
Pin Name I/O Pin Description
DSelect I DBus selection. This line is asserted (high) when the Display Controller should perform a non-address operation on the DBus.
DSerialOut O Data emitted serially on the DBus by the Display Controller. This line is floated except when DSelect is asserted.
DSerialIn I DBus serial input data and address
nDReset I System reset (active low)
nDFreeze I Ignored by Display Controller
DExecute I Used to load the Fault Status Register before scanning it out.
DAddress I When high, address bits are presented serially on DSerialIn. The last three bits presented specify the DBus internal register selected.
DShiftCK I DBus shift clock
5.3 Video Interface
Refer to the Bt458 documentation for more details about these pins.
Pin Name I/O Pin Description
DACData[0..7] O Data path that downloads information from the Display Controller to the Bt458 Digital Analog Converter (DAC). For each IOWRqst received, the Display Controller downloads four bytes of information to the Bt458: address, red data, green data, and blue data.
nCE O Chip Enable. This output is asserted once for each byte downloaded to the Bt458.
C0 and C1 O Command control outputs that are decoded as follows:
  C0 C1 Function     
  0 0 load address
  0 1 load pixel palette
  1 0 load misc regs
  1 1 load overlay color palette
R/W O Read/Write control output. In the current implementation of the Display Controller, it is always low which specifies a write. To write, nCE must also be asserted.
PixOut O 32 bits. PixOut (Pixels out) is the main output data path of the Display Controller. It represents four 8-bit pixels.
COut O 8 bits. Cursor Out. It represents an overlay of four 2-bit pixels, for displaying the cursor and border.
nHSync O 1 bit. nHSync is a microprogrammed output typically used for synchronizing the video monitor. It could be connected to the Bt458's SYNC* input to provide sync-on-green synchronization, in which case both horizontal and vertical synchronization must be provided. Alternatively, it could be connected directly to the horizontal sync input of a suitable video monitor.
nVSync O 1 bit. nVSync is a microprogrammed output which can be used to provide a vertical synchronization signal to a video monitor that requires independent horizontal and vertical sync signals.
nBlank O 1 bit. nBlank is a microprogrammed output typically used to blank the video output during horizontal retrace and vertical retrace intervals. It is typically connected to the Bt458's BLANK* input.
T0 I 1 bit. Sampled by microcode which may do a conditional jump based upon its value. T0 may also be used to synchronize the Display Controller with an external event, such as a laser printer's start-of-scan-line signal, or to synchronize multiple Display Controller's.
T1 I 1 bit. Sampled by microcode which may do a conditional jump based upon its value. T1 may be used to synchronize the Display Controller with another external event, such as a laser printer's start-of-page signal. 
VCK I One of the three main clocks for the Display Controller. It runs at 1/4 the rate that pixels are being displayed on the screen.
 
6.0 DC Characteristics
Pin Name Signal Type Voltage  Current
Group Out 5V output L 0.5 2 mA
  H 4.0 0
Group TSOut 5V tri-state output L 0.5 2 mA
  H 4.0 0
Group In 5V input L 0.5 2 mA
  H 4.5 2 mA
Pin Type Pin Name
Group Out CkOut, Cout, C0, C1, DACData, nBlank, nCE, nHSync, nVSync, OwnerOut, PixOut, RequestOut, R/W, SharedOut, SpareOut, SStopOut
Group TSOut DataOut, DSerialOut, DBusOut, HeaderCycleOut, ParityOut
Group In DAddress, DataIn, DExecute, DSelect, DSerialIn, DShiftCK, Grant, HeaderCycleIn, HiPGrant, LongGrant, nDFreeze, nDReset, OwnerIn, ParityIn, SharedIn, SpareIn, SStopIn, TestEn, T0, T1, VCK
7.0. AC Characteristics
A. Definitions
[Artwork node; type 'Artwork on' to command tool]
Figure 4: Input Signal Characteristics
Ts (setup time) = the mimimum time a signal must be stable before the rising edge of the clock.
Th (hold time) = the mimimum time a signal must be stable after the rising edge of the clock.
[Artwork node; type 'Artwork on' to command tool]
Figure 5: Output Signal Characteristics
Tcycle = the time interval between successive rising edges of the clock
Tpd (propagation delay) = the waiting time after the clock is high until an output becomes valid.
Tm (maintenance of old data) = the time after rising edge of next clock cycle that old data remains valid.
B. Values
Qualififed Pin Name Tmin Ttypical Tmax
Tcycle 20ns 25ns 27ns
Ts.DynaBus In (setup.DynaBus In)  3ns 
Th.DynaBus In (hold.DynaBus In)  1ns
Tpd.DynaBus Out (propagation delay.DynaBus Out)  5ns
Tm.DynaBus Out (maintain.DynaBus Out)  2ns
   
   
8.0 Application Schematics of the Circuit
[Artwork node; type 'Artwork on' to command tool]
9.0 Physical Pin-Out For Each Package
No Name  No Name No Name No Name
4 nGrant.0 37 nOwnerOut 73 TIOvdd 110 ArbReqOut.0
5 nRequestOut.0.0 38 nSharedOut.0 74 TIOgnd 111 OtherArbIn.0.0
       
       
       
[Artwork node; type 'Artwork on' to command tool]