WO1991000587A1 - Video image controller for low power computer - Google Patents

Abstract

A controller (15, 17) for a computer LCD display in a low power computer refreshes the display (not shown) directly from a bit map memory (202). One of the two memory (201) stores character codes and attributes, and the other (202) stores the bit maps which are represented as pixels in the display. Whenever characters are sent to the caracter code memory (201) by the microprocessor (16), they are translated by the circuitry of the controller (30.000) to bit maps in the bit map memory (202). Refreshing the display directly from a bit map memory (202) requires fewer read operations than refreshing by reading a character code, attributes and a font table. Reducing the number of read operations per byte refreshed reduces power consumed by refreshing the screen from the bit map memory, the microprocessor (16) must be turned on to update the character code memory (201), whereas the microprocessor (16) may be turned off when the display is not being updated for saving power.

Description

VIDEO IMAGE CONTROLLER FOR LOW POWER COMPUTER

FIELD OF THE INVENTION

This invention relates to electronically displayed images, particularly to liquid crystal displays for displaying information held in computer memory, and to means for generating an image to be displayed.

BACKGROUND OF THE INVENTION

In personal computers, there are two widely used methods of generating images to present information to the user of the computer, generally called character mode and graphics mode.

In graphics mode, a computer program directly controls each bit in a bit map. This bit map is transmitted to a computer monitor to provide the image on a screen. The computer programmer must provide the necessary software to generate the bit map, and memory space must be allocated for storing this bit map. For a typical monitor displaying 640 x 200 pixels (picture elements) , each pixel on the screen corresponding to one bit of memory, 128,000 bits or 16,000 bytes of bit map memory must be provided. In bit map graphics programs for controlling a cathode ray tube, the tube is typically scanned twice for each refreshment of the screen, once for displaying odd rows of pixels and once for displaying even rows of pixels. In order to accommodate this interlaced scanning technique, graphics memory has typically been divided into a section for controlling even rows and a section for controlling odd rows. A liquid crystal display does not need or use this interlaced scanning technique, thus for a liquid crystal display the two separate portions of memory are scanned alternately to produce input to display drivers which control the image in sequential order of the rows.

Users commonly want to display text on the screen, for example when using word processing, spread sheet and data base programs. A common standard compatible with a large base of widely used software is to display 25 lines of 80 characters per line. The information for such a display can be more compactly stored in a character memory as a set of ASCII characters. Each character takes one byte of memory, thus 2000 bytes of memory are needed to identify the characters on the screen. An additional 2000 bytes describe attributes of the characters. A black and white standard called monochrome display adapter (MDA) expects these 8 bits in an attribute byte to indicate whether the character will be bold, underlined, in inverse colors, blinking, blanked, or attributes off. A color standard called color graphics adapter (CGA) expects these attributes to indicate bold, blinking, foreground color (3 bits) and background color (3 bits) . For a description of the MDA and CGA adapters, see P. Norton and R. Wilton, The New Peter Norton Programmer's Guide to the IBM PC & PS/2. Microsoft Press, (1988) . Thus 4000 bytes of memory can store the information for describing a screen of text characters, instead of the 16,000 bytes needed for describing a graphics screen. For each of 256 characters which can be selected by 256 different 8-bit bytes, a character font is provided, usually in a read-only memory (ROM) , which is less expensive than a volatile memory. Every time the monitor screen is refreshed, the ASCII character, its attribute, and part of its corresponding bit map are read for every row of pixels displayed on the screen. That is, for the first line of characters to be displayed on a screen, the 80 characters in the first line are read, the corresponding attributes are read, and the top row of bits in the character ROM are read and sent to the display for driving the top row of pixels in the display. These 80 characters and their attributes are then read again, this time the second row of bits in the character ROM being read for each of the 80 characters and sent to the display. For a character memory in which the characters are 8 bits tall, each character, attribute, and part of the character font are read 8 times.

In order to refresh the screen one time, three bytes are read for every 8 pixels on the screen, leading to 48,000 bytes which are read every time the screen is refreshed. Most computers now use CMOS circuitry in order to reduce power. Yet for CMOS circuitry where most of the power is consumed during steps which involve switching CMOS transistor pairs, the power consumed by a display controller operating in character mode which reads 48,000 bytes for every screen refresh is considerably higher than the power consumed by a display controller operating in graphics mode which reads only 16,000 bytes for every screen refresh.

Since a large volume of software has been written for this character mode it is important that a new video controller be compatible with this existing software.

SUMMARY OF THE INVENTION The primary purpose of the present invention is to save power used to drive a computer display. The method and structure of this invention save power by refreshing a display screen in character mode directly from a bit map memory, in contrast to the conventional method of generating screen refresh data directly from character memory. Further, power is saved because the computer processor is able to be turned off while the display is on. The present invention uses both a character memory and a bit map memory when operating in character mode. The screen is refreshed by circuitry which reads directly from the bit map memory. The character memory is in a location and has a format compatible with typical existing software. Translation circuitry hardware updates the bit map memory from the character memory whenever a software program changes the character memory. According to the present invention, the screen is always refreshed from the bit map memory whether software is operating the computer circuitry in character mode or in graphics mode. Importantly, the computer does not participate in refreshing the display screen. When the computer is operating in character mode, the character memory receives the character and attribute bytes, in a location and format which make the structure and method of the present invention compatible with a multitude of existing software programs. The present invention includes circuitry which translates these character and attribute bytes into a corresponding bit map stored in the bit map memory. Additional steps and circuitry are required to convert from the character memory to the bit map memory. The power saving occurs because in most cases, the display screen is refreshed orders of magnitude more frequently than the screen content is changed, and the steps necessary to replace a character in the bit map are infrequently performed compared to the steps necessary to refresh a screen. The present invention is preferably used with a computer in which other power saving measures are also taken, including turning off the clock signals to a microprocessor while the microprocessor is executing a program. Such a computer is described in commonly assigned copending patent application serial no. 07/373,440, attorney docket no. M-924, entitled "COMPUTER POWER MANAGEMENT SYSTEM", incorporated herein by reference. In this case, a separate clock controls refreshing the screen from the bit map memory while the microprocessor clock is off. The computer appears to a user to be operating, yet the power consumed by the microprocessor waiting for such external activity as pressing a key or sending a bit from an external modem has been saved. In such an environment, a large portion of the total power consumed by the computer could be consumed by driving the display, and measures to save power consumed by driving the display can produce a significant saving in total power consumed by the computer. According to the present invention, the bit map memory is only updated when a change is made to the character memory (which includes both characters and attributes) . Since the great majority of screen refreshes occur without any change in the character memory, a significant savings in power used to drive the display can be made by driving the display from the bit map memory.

A buffer stores characters or attributes and their addresses which are to be updated in the character memory. When an address provided by the CPU is recognized as within the range of the character memory, a translate flag is switched to "true", indicating that a translation needs to be performed to update the bit map. The address of the character or attribute to be updated is then examined to determine whether it is a character (even numbered address) or an attribute (odd numbered address) . The character/attribute pair is fetched from the character memory and updated in the character memory. For MDA or CGA compatible software, setting bit 3 of the attribute byte to "1" indicates the character is to be bold. In a liquid crystal display it is not possible to display a bold character by using a higher intensity beam, as is done in a cathode ray tube display. Therefore a different set of character fonts in which the character lines are wider are used for bold characters. Thus if bit 3 indicates the character is to be bold, the character font is taken from a second set of character fonts. The other attributes are applied to the character in translating to the display bit map. For example, the bit stream may pass through eight two input AND gates (or other appropriate logic gates) , eight two input XOR gates and through circuitry which generates an underline. If the character is to be blanked, a low signal is applied to the other input of each AND gate. If the character is to be shown in inverse color, a high signal is applied to the other input of each XOR gate. The character address is applied to an address translation table which gives a corresponding bit map address for the character address. This address determines the location in the display bit map of the upper row of character bits. The first byte of the character is written at this address in the display bit map as adjusted by the appropriate attributes. If there are 80 characters per line, the next byte of the character is written at an address higher by 80 than this first byte, which places this second byte directly beneath the first byte. This process is repeated for all bytes of the character. Circuitry controls this translation function, under timing control of the microprocessor clock. The amount of time required to perform these translation steps is small compared to the idle time in many computer programs. For example the translation time is a very small part of the time between keystrokes made by a typist typing 100 words per minute in a word processing program. It is also a small part of the time used for transmitting bytes on a 1200 baud modem or even a 9600 baud modem. Once the above described updating of the display bit map is performed, the microprocessor clock can be turned off and the liquid crystal display screen updated without intervention of the microprocessor.

As another power saving feature, the blinking of a cursor, which typically occurs 2 to 4 times per second, can be performed without intervention of the microprocessor, that is without consuming the power which occurs when the microprocessor is turned on.

In one embodiment, a cursor size is identified by a user who indicates the height of the top and bottom of a cursor blink. For example, a blinking underline or a full blinking block may be chosen as cursor sizes. The cursor location in the display bit map is stored in a latch circuit. A clock signal, preferably 32.768 kHz, is divided down and sent to circuitry in the display controller to alternately replace and not replace the character or part of the character at which the cursor is located with a blank space determined by the cursor size.

Other characters may be identified as blinking by the attribute of the character. If any characters have their blinking attribute set, all characters will be scanned periodically, in one embodiment every 1/4 second, to determine which are blinking. For a blinking character, the state of the character is determined, then changed. If the character appears normal it will be replaced with a blank; if the character has been replaced with a blank it will be rewritten as the normal character. Provision is made in this circuitry for blink control to be disabled by a software command.

As another novel feature of this invention, the same bus which provides bytes from the display bit map to the display column driver circuits during screen refresh is also used by the microprocessor for updating the display bit map. Control signals from the microprocessor indicate to the display bit map when it is receiving data for being updated. However, since the function of refreshing the screen is performed without microprocessor control (to save power) , this refresh function continues during the short bursts of time in which the display bit map is being updated by the microprocessor. Instead of the data from the display bit map indicating whether pixels in certain columns are to be on or off which is expected by the column drivers, the bus carries data for updating the bit map, as applied under control of the high frequency microprocessor clock. This data is erroneously applied briefly to columns of the liquid crystal display. However, these signals, which might be observed as "snow" on a cathode ray tube will not be detected on a liquid crystal display if the response time of the liquid crystal display material is longer than the time required to update the display bit map .

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1. System diagram of a computer in which the video display controller of the present invention preferably operates.

Fig. 2. Block diagram of block 15 of Fig. 1 showing the four types of memory used by the video controller of the present invention, character memory, a table of character fonts, an address translation table, and display bit map memory.

Fig. 3a. Block diagram of major functions performed by the video display controller of the present invention.

Fig. 3b. Block diagram showing the translation block of Fig. 3a in more detail. Fig. 3c. Timing diagram for signals generated by synchronization block 30.010 of Fig. 3a.

Fig. 4a. Block diagram showing the steps performed by the translation block of Fig. 3b.

Fig. 4b. Block diagram showing the steps performed by the synchronization block of Fig. 3a.

Fig. 4c. Block diagram showing the steps performed by the blinking controller of Fig. 3a.

Fig. 4d. Block diagram showing the steps performed to control blinking of the cursor. Fig. 4e. Block diagram showing the step performed to control the moving and sizing of the cursor.

Fig. 5. shows the schematic overview of the blocks in Figs. 3a and 3b which perform the steps shown in Figs. 4a-4d. Figs. 6a-6w show detailed schematic drawings which implement the schematic overview of Fig. 5.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

In a preferred embodiment of the present invention, which is compatible with an IBM XT computer, the character display shows 25 rows of 80 characters per row. In application software which is MDA (monochrome display adapter) or CGA (color graphics adapter) compatible, 2000 characters are stored. Each character takes 1 byte. For each character a second byte gives attributes. For black and white displays which are MDA compatible, these attributes include inverse, blinking, bold, blanked black, blanked white, underlined, and normal. For color monitors which are CGA compatible these attributes include blinking, bold, foreground color, and background color. Memory for storing these character attributes takes another 2000 characters. Therefore a display page takes 4000 bytes of memory. This is called character memory because each byte represents a character or its attributes. By contrast, the bit maps for displaying a character take 8 bytes per character for a total of 16080 bytes for a display page, and each byte represents an actual pattern of bits to be displayed.

One preferred embodiment is both MDA compatible and close to CGA compatible in that it presents a black and white display of data specified by a program using CGA codes. The preferred embodiment offers two character modes, one using 40 characters per line and the other using 80 characters per line, and the CGA graphics mode, these modes being software selectable. When operating in character mode, the information in character memory is converted, in accordance with the present invention to a bit map memory which is read by display drivers for controlling pixels (picture elements) in a display. In one embodiment, if the bit is 1, the pixel is black, and if the bit is 0 the pixel is white. If one wishes to display the letter "A" (the ASCII code representing an "A" is "41"), one types an "A" on a computer keyboard, and the computer detects a "41". The bit map related to the "41" is read from a character font table and loaded into a display bit map at the location where the "A" is to appear, whereupon it can be scanned and presented on the display. Fig. 1 shows a system diagram of a computer in which the preferred embodiment of the present invention operates. This system diagram is described in detail in commonly assigned copending patent application serial no. 07/373,440, attorney docket no. M-968, entitled

"PORTABLE LOW POWER COMPUTER" which is incorporated herein by reference. The present invention is directed to LCD RAM 15 and to a portion of peripheral ASIC 17 of Fig. 1.

Fig. 2 shows a block diagram of block 15 of Fig. l including both character memory 201 loaded by a computer program and the display bit map memory 202 from which data for driving the display are taken, as well as character font table 203 and translation address table 204 for translating information in character memory 201 to information in the display bit map memory 202.

The standard block representing a character is 8 bits by 8 bits, forming a square of 64 pixels. Character font table 203 is preferably a ROM memory, which stores 8 such bytes for every displayable character and some representation of most non-displayable characters, including 128 standard ASCII characters and 128 characters which may be particular to a system. This character font table 203 includes a second set of 256 bit maps for the bold characters. To convert from the character memory 201 to screen bit map memory 202, which is read by display drivers for applying voltages to a display screen, requires that the bit map related to the particular character be read from the character font table 203 and translated using attributes of the character, then loaded to the proper location in the screen bit map memory 202.

Overview of Steps Used in Updating Bit Map 202

Fig. 3a shows a block diagram of a preferred circuit of the present invention which updates character memory 201 and bit map memory 202 in response to instructions from the CPU (computer microprocessor) to update character memory. In this block diagram the steps for applying attributes to an existing character are carried out, and steps for loading a new character with existing attributes are carried out. These steps are carried out without intervention of the microprocessor. Translation block 300 applies the static attributes including bold, underline, blanked and inverse during the process of translating from the character memory 201 to bit map memory 202.

The blink attribute is implemented by updating the bit map memory 202 every time the blinking characters change state. The logic in block 30.070 is provided to accomplish this blinking function.

Likewise, the blinking of the cursor is implemented by updating or overriding bit map memory 202 when the cursor blinks. The cursor essentially overlies another character on the screen. The cursor location is preferably stored in a cursor location register and is alternately displayed or not displayed overlying the character where the cursor is located. Blinking and moving the cursor is handled by the logic in block 30.050.

Synchronization block 30.010 generates synchronization signals divided from pulses of a display oscillator located in block 11 of Fig. 1. These signals synchronize loading of data from display bit map 202 into the liquid crystal display.

Address MUX (multiplexer) 30.020 provides addresses on a common address bus XA[0..14] for two functions, the loading of data into character memory 201 and bit map memory 202 when an update is being performed in response to instructions from the CPU, and the refreshing of the liquid crystal display screen when the memories are not being updated. (The labels of buses indicate the number of lines included in the bus. The notation [0..13J indicates the bus is 14 bits wide, for example. This bit-width notation is used throughout the description and figures.)

Data MUX (multiplexer) 30.090 feeds data back from the video controller to the CPU. Data from character memory 201 is used by the CPU for scrolling the screen, for example, and also for moving the cursor.

Description of Translation Block 300

When an address is placed by the CPU on address bus ADDR[0..19], a sequence of steps is initiated in translation block 300. For example, if an address of an attribute in character memory is placed on address bus ADDR[0..19], this attribute must be written to character memory 201 and also used to generate a change to a character in bit map memory 202. Translation block 300 initiates a series of steps which involves placing a series of addresses on display address output bus XA[0..14] in combination with placing a series of data on data output bus LCDDTA[0..7]. One of the addresses to be placed on display address output bus XA[0..14] is the address of the attribute placed by the CPU on bus ADDR[0..19] and which has been latched into an address latch in video display load 30.050.

Description of Translation Block 300. in connection with Flow Diagram Fig. 4a

Fig. 4a shows a block diagram of steps for translating character memory data from character memory 201 of Fig. 2 into data in display bit map memory 202. When the CPU does a write operation to an address within the range of the display page, the translation flag in step 401 is set to true, and the sequence for updating bit-map memory 202 of

Fig. 2 begins.

As shown in step 402, when the CPU address indicates there is a character to be translated, the character or attribute sent by the CPU is written into character memory 201.

As shown in block 403 of Fig. 4a, the address is inspected to determine if it is even or odd. In accordance with MDA or CGA, in the 4000 byte character memory 201 of Fig. 2, characters are loaded into even bytes and their attributes are loaded into odd bytes. Thus if the address is odd, an attribute has been written, and if the address is even, a character has been written by the CPU.

As shown in step 404, the corresponding character (which has not changed) must be fetched so that the proper character/ attribute pair may be used for generating the desired character representation in bit map 202. Likewise, if the address is even, a character has been written, and as shown in step 405, the corresponding attribute (which is not changed) must be fetched to obtain the proper. character/ attribute pair for generating the desired representation of the character in bit map 202.

Next, as shown in step 406 of Fig. 4a, the address in character memory 201 to which the character or attribute was sent is read and applied to translation address table 204 to obtain a corresponding address in the bit map memory 202 to place the font of the character. The address in the translation address table 204 is the address of the top row of the character which in the embodiment described here is 8 rows tall.

Next, as shown in step 407, the character byte of the character/attribute pair to be translated (which is a number from 0 to 255) is multiplied by 8 to form an ll-bit address in font table 203. The 8-byte bit map memory block for the letter "A", as stored in font table 203 is shown at the left of Table I. If no attributes are applied, the eight bytes in the memory block will be read into screen bit map memory 202 with the orientation shown on the right of Table I.

Table I

row 8 As shown in step 408, the attribute portion of the character/attribute pair is inspected to determine if bit 3 of the attribute is "1", indicating the character is to be bold. If so, the address in the character font table 203 is increased by 2048 (256 characters times 8 bytes per character) , arriving at the address of the bold version of the same character.

In steps 410-418, the eight bytes taken from the character font table 203 are used to generate corresponding bytes in bit map memory 202. In step 410, a counter which indicates which of the eight bytes in the character font is being translated is set to zero. As shown in step 411, the first byte is then fetched from the character font table 203 at the location specified in step 407 or 409. This byte has a pattern of 0's and l^#s corresponding to the black and white space at the top row of the character. For example, if the character to be translated is the letter "A", for which the ASCII code is "41", and attribute bit 3 is zero, the first byte 00011100 in the font shown in Table I will be provided to a circuit for applying attributes, as shown in step 413. The font table 203 address is then incremented by 1. This is shown as step 412 but may occur anywhere in the loop for translating the eight bytes of character font table 203 data. The circuit for applying attributes in step 413 can blank the byte of the character currently being translated. This blinking is performed in response to a blinking attribute bit by applying zeros to inputs of eight two-input AND gates through which the byte is passed (or logical ones to inputs of eight two-input OR gates through which the byte is passed) and may invert the color of the byte by applying logical ones to eight two-input XOR gates through which the byte is passed.

To display an underlined letter "A", a software program being executed causes the attribute byte associated with the byte "41" representing the "A" to indicate an underline is to be provided. An underline is applied by applying logical ones to the eight two-input OR gate through which the last byte only of the character is passed. In this case when the character in location 41 is read from the character font table 203, the byte representing the lowest portion of the letter A is replaced with all l's as the character from font table 203 is loaded into bit map memory 202.

As shown in step 414, after passing through the block for applying attributes, the adjusted byte is written to bit map memory 202 in the location fetched in step 406 from address translation table 204. After this byte is written to bit map memory 202, the bit map memory address is incremented by 80, which in a bit map memory 80 bytes wide produces a location directly beneath the previous location. As shown in step 417, the counter i is incremented by 1, and the process is repeated for reading the second byte from the font table 203 into the bit map memory. When all eight bytes have been read, adjusted and loaded into bit map memory 202, the translation of that character into the bit map is complete, and the translate flag is set to zero or false.

Description of Translation Block 300 of Fig. 3a in Connection with Fig. 3b

Fig. 3b shows in more detail translation block 300 of Fig. 3a. If an address is within the range of character memory 201, as determined by decode block 30.040, then a shift register in block 30.100 begins sending pulses which initiate a sequence of steps to control blocks 30.050, 30.110, 30.080. If the address on bus ADDR[0..19] is within the range of character memory 201 or bit map memory 202, it is latched in address latch U277,U276 of block 30.052. This address appears on bus DADR[0..13] and is available to address MUX 30.020 for use when selected by control signals to address MUX 30.020. DADR[0..13] is used in step 402 (Fig. 4a) to write characters or attributes to character memory 201. The address is also used in steps 404 and 405 to read characters or attributes from character memory 201.

For the first 8 clock cycles, sequence control block 30.100 causes address MUX 30.020 to apply the address on 5 bus DADR[0..13] to address MUX output bus XA[0..14]. The fifteenth bit of the output bus selects between character memory 201 (bitl4 = 0) and bit map memory 202 (bitl4 = 1) . Here the fifteenth bit is zero to select character memory 201. 0 In the first two clocks of the sequence provided by block 30.100, (step 402 of Fig. 4a), the data on bus EXPI[0..7] from the CPU are latched in latch U2 of block 30.030 and are available on bus LCDDTA[0..7] to be applied to the address on address bus DADR[0..13]. If the data 5 written by the CPU is a character (least significant bit of ADDR[0..19] is zero) it is latched in latch U250 of block 30.050. If the data written by the CPU is an attribute (least significant bit of ADDR[0..19] is one) it is latched in latch U3 of block 30.030. 0 For the third and fourth clock cycles, (steps 404 and 405) the address of the corresponding attribute or character is applied to output bus XA[0..14] by inverting the least significant bit on the DADR[0..13] address bus. This fetches the corresponding character or attribute, 5 which is latched into its respective latch.

In the fifth through eighth clock cycles, the address latched in latch U276/277 (step 402) is applied by sequence controller 30.100 to address translation table 204 and a translated address is read out (two bytes take four clock

30 cycles) on bus DSPDTA[0..7] and latched into latches U263 and U274 of block 30.055.

Sequence controller block 30.100 now starts the 5-bit counter of block 30.057. This five bit counter is appended to the 8-bit character code latched in latch U250 of block

35 30.050 to form an 11-bit address plus two control bits

(step 410) . The 11 most significant bits are the address in the font table of the top byte of the font to be loaded into the bit map memory 202. Adding three bits to the 8- bit character code multiplies the character code by 8 (step 407 of Fig. 4a) and generates the row address in the font table. The least significant bits are the control bits. The higher of these two control bits, which is called ROMAC, switches multiplexer U266/U275 in block 30.055 between the font table address (which is read) and the bit map address (which is written to) .

The third bit of attribute latch U3 is connected as the high bit of 12-bit font address ROMADDR[0..11] . If the attribute in attribute latch U3 of 30.030 has a "1" in bit 3, (meaning the character is to be bold) , then the high bit R0MADR11 is set to "l" and the address of the font table is increased by 2048, as shown in step 409 of Fig. 4a. In steps 411-417 block 300 reads the eight bytes from the font table 203 and writes them to bit map 202. Logic in block 30.110 causes address MUX 30.020 to apply bus VDADDR[0..13] to output bus XA[0..14]. The high output bit switches between 0 to 1 during this sequence, switching to 0 when the font table 204 is being read and to 1 when bit map memory 202 is being written to.

To fetch a byte from the font table, address ROMADR[0..11] in block 30.050 is applied to bus VDADDR[0..13] (which is applied in turn to address MUX output bus XA[0..14]) in response to a high ROMAC signal. A high ROMAC signal also indicates that the operation is a "read" and that the data read from the font table 203 is to be latched in latch U2 of block 30.030 (step 411).

On clock cycles 11 and 12, block 30.030 applies the inverse, blanking attributes using block 30.035 to the data latched in latch U2 (step 413) .

On clock cycles 11 and 12, the address used to write the attribute-modified data to the bit map memory 202 comes from latches U263 and U274 on bus LALAT[0..13] . (During clock cycles 11 and 12 ROMAC is low, causing the

LALAT[0..13] signal to be presented on the VDADDR[0..13] output bus of MUX U266/U275.) At the end of clock cycle 12, the LALAT[0..13] signals have passed through ADD80ALU block 30.080 to add 80 (step 415) to the address stored in latches U263/U274 (also under control of ROMAC) . When ROMAC goes high, the new value is latched and the 5-bit counter in block 30.052 increments the font table address by 1 (step 412) .

If the font table row address is equal to 8, all rows have been translated. The five-bit counter sends a signal saying the terminal count has been reached, and translation stops.

Description of Synchronization Block 30.010 of Fig. 3a Synchronization block 30.010 of Fig. 3 provides a series of synchronization signals for applying data to the rows and columns of the liquid crystal display. Synchroni- zation block 30.010 also sends the liquid crystal display address currently being loaded to address MUX 30.020 on bus LCDADDR[0..13] . Fig. 4b shows the steps performed by synchronization block 30.010 of Fig. 3. Two column driver clocks drive eight column driver chips (not shown but shown in copending application serial 07/374,340, attorney docket no. M-806, invented by John P. Fairbanks, Andy C. Yuan, and Lance T. Klinger entitled "POWER SYSTEM AND SCAN METHOD FOR LIQUID CRYSTAL DISPLAY", and incorporated by reference), each column driver chip driving 80 columns of the 640 column display. It is preferred to clock two or more sets of column drivers separately in order to save the power for switching the data through a long shift register in the column driver circuitry. If 640 columns of data are shifted through a single shift register, the transistors at the input of the shift register are switching constantly while the display is being driven, and thereby consume power. By using more than one shift register, the number of transistors being switched can be reduced. In the present embodiment, two shift registers are used. Thus, the transistors in one shift register can be held static while the other shift register is loaded. Other embodiments having more and shorter shift registers may save additional power by holding a larger number of transistors static. However, providing more shift registers requires additional pins for applying additional clock signals, thus presently preferred is an embodiment using two shift registers. As shown in block 421, for the first 40 data bytes (actually 320 columns) the display clock signal is applied to column clock 1, and column clock 2 is held low. Steps 422 and 423 indicate that a column counter is incremented to 40 while this first column clock is driven by the display clock. Likewise, as shown in blocks 424, 425, and 426, the second column clock is driven by the display clock while the column counter is incremented from 41 to 80. When the column count reaches 80, as indicated by the "yes" output of step 425, step 427 indicates that a row clock pulse is sent, indicating that the next row is to be driven. The row count is concurrently incremented. Also concurrently incremented in step 427 is a phase count. Here, phase refers to the polarity of voltage applied across pixels in the display screen. The polarity of voltage applied across pixels of the display is periodically reversed in order to avoid degrading the display. A phase signal controls this polarity reversal. It is possible in the present embodiment for software to select whether this phase signal is reversed every 1, 2, 4, or 8 rows. The value placed by software in a register in peripheral ASIC 17 determines the number of rows which will be driven at the same polarity. As shown in block 432, this phase count is compared to the number of rows to be driven at the same polarity. When the phase counter reaches this value, as shown in block 433 the phase is reversed and the phase counter is set to zero. Instead of the conventional 200 rows in a 25 line display the preferred embodiment of the present invention adds one additional row for displaying a status line at the bottom of the display, giving 201 rows of 640 pixels each, or 128,640 pixels. As shown in step 428, the newly incremented row count is compared to 200. There are 200 rows in the display, however, the row count begins at 0, thus when the row count equals 200, the 201st row has been sent to the display, the 20lst row being the status row in the present embodiment. Because the data are first shifted into column drivers which subsequently latch the data onto the columns, the displaying of the data occurs during the time a subsequent row is being sent to the display drivers. Therefore after step 428 an extra row count is done while the first row of a new screen refresh cycle is being sent to the display column drivers. At step 430, when the answer to the question "row count = 201?" is "yes" the row counter is reset and a frame synchronization pulse is sent causing the display screen to begin latching data into the first row. Bit map memory 202 is addressable by the circuitry method described in connection with Figs. 3a and 3b and also directly from the CPU by applying the bit map address on bus ADDR[0..19] and the data on bus EXPI[0..7]. This direct address method is always used in the graphics mode and is also used for loading data into row 201 of the bit map memory in either of the character modes. It is also possible to overwrite character data in bit map 202 when operating in one of the character modes, thereby producing a screen which shows both characters and graphics.

In the presently preferred embodiment, data in row 201 are generated by the CPU by writing directly to bit map memory 202 (even though the software is operating in character mode) . The BIOS (basic input/output system) uses this status row 201 to indicate such information as the disk is being accessed, the caps lock is on, the number lock is on, and the alarm is set.

The display must be refreshed periodically to maintain the on or off state of the pixels. Refreshing of the display screen preferably occurs 50 times/sec. An oscillator having a frequency of approximately 800 kHz controls the refresh logic, generating timing signals which control speed of refreshing. To refresh the display, the display drivers read 1 byte (8 pixels) every 1.25 microseconds from the display bit map memory 202. That is, on every clock cycle a byte of data from bit map memory 202 is read into the column driver shift register. Since pixel data are read 1 byte at a time, 128640 pixels / 8 pixels per byte = 16,080 bytes are read per refresh. These bytes go to two shift registers each of which comprise a sequence of Seiko SED 1631/DAA column driver chips. These shift registers are loaded with 320 bits (40 bytes) each, which are then latched onto respective columns of the display. After the 80 bytes for one row have been read into the shift register, as shown in step 427, a row clock pulse, divided by 80 from the column clock signal, causes the column data just shifted into position to be loaded onto the column latches, whereupon the data for the next row begin shifting into position. When the row count reaches 199, all 200 character rows (numbered 0 through 199) have been read and loaded into the column drivers. In this figure, row 200 is the status row. After the status row (row 200) has been read, as shown in step 428, the bit map address is set to zero (step 429) . But since the data in the column shift registers is not latched and applied to the columns until after all columns for the row are present in the shift registers, an additional step, step 430, counts to 201 before sending the frame synchronization pulse to cause the display to move to the top of the page.

Bytes are provided sequentially from bit map memory 202 to display drivers located in block 14 of Fig. 1, which apply voltages at appropriate times to control the states of the 128640 pixels (in one embodiment) in the display. The display drivers of block 14 are described in detail in commonly assigned copending patent application serial no. 07/374,340, (attorney docket no. M-806) incorporated herein by reference. Most pixels have a 1:1 relationship to bits of data in the bit map. However, in the present preferred embodiment using 130,560 pixels, the status line, which occupies one row of bits in bit map 202 is displayed on a line four pixels high in order to improve visibility.

Description of Blink Scan Block 30.070 of Fig. 3a

The 8th bit (bit 7) in an attribute byte of character memory 201 indicates that the character is blinking. The presently preferred embodiment of the invention maintains an indicator of whether the display includes any blinking characters. If any characters are blinking, all characters are scanned periodically to determine which characters are to blink and to update bit map memory 202 in those locations.

Fig. 4c shows the steps performed by blink scan block 30.070. As shown in step 441, a timer determines whether the period for switching the blinking characters (every 1/4 second in the present embodiment) has passed. When this period has passed, as shown in step 442, a flag indicating that a blank should be written in the locations of blinking characters is switched to its opposite state. The blink scan address, that is, the address in character memory 201 which stores character/attribute pairs, is set to zero. Fig. 4c shows in step 443 that the flag for indicating whether the display includes any blinking characters is inspected. Alternatively, this flag may be inspected before step 442. If there is at least one blinking character, the answer to the question in block 443 is yes, and the 7th bit of the first attribute byte is read in step 444 and inspected in step 445 to see if the value is "1" to indicate that the character is to blink. This attribute is stored in location 0001 of character memory 201 and refers to the character in location 0000 of character memory 201. If this character is not set to blink, in step 446 the blink scan address is incremented and the process is repeated for the next address pair in character memory 201. When an attribute indicates its character is set to blink, in step 447 the state of the "write a blank" flag is inspected. If the flag is set to "1", a blank character is written to bit map 202. To write this blank character, the address is translated as discussed in connection with Fig. 4a and a font of all zero's (or in another embodiment, all ones) is written to the translated address. If the "write a blank" flag is set to "0", the character stored in the character/attribute pair currently being scanned is translated as shown in Fig. 4a, with other attributes applied as discussed in connection with Fig. 4a, and written to its location in bit map 202. This process is repeated for all character attribute pairs in character memory 201. Thus the entire page of memory 201 currently displayed is scanned for blinking characters and those characters in memory 202 are updated every 1/4 second (or other interval) to support blinking characters. This update is still infrequent compared to updating the memory every time the screen is refreshed, which is the method conventionally practiced, and allows the blinking function to be supported while a low power display control is realized. There are actually four pages of character memory stored in character memory 201, only one of which is stored at a time in bit map memory 202 for display to the screen. Since only one of these pages is actually translated to bit map memory 202 and displayed, it is only this displayed one of the four pages in character memory 201 which is scanned for blinking characters and used to update memory 202.

Description of the Cursor Control Block 30.060 of Fig. 3a

Cursor control block 30.060 controls both the blinking and the moving of the cursor. The cursor address is stored in cursor control block 30.060 as both a character memory address and a bit map memory address. The register in cursor control block 30.060 storing the character memory address of the cursor can be read by the CPU, which happens when a command to move the cursor appears. The register in cursor control block 30.060 storing the bit map memory cursor address is used for comparing to data being sent to the display in order to apply the cursor address to this data.

Cursor Blink

It is possible to implement the cursor blink in a manner similar to that of other blinking characters discussed above. The cursor may be of a size different from the entire block occupied by the character, in which case the amendment of the bit map at the location of the cursor must take into account the size and shape of the cursor as well as its location. However, the cursor is frequently present when there are no other blinking characters, so a logical arrangement which does not require updating the entire bit map for one cursor location is preferred. It is more efficient to have the cursor stored separately from bit map 202, and that is the embodiment described in detail here. Further, it may be desirable to have the cursor blink at a frequency different from that of other blinking characters.

As shown in Fig. 4d, in step 461, the bit map address of the byte currently being sent to the display column drivers for displaying to the screen is compared to the cursor location. This cursor location has been translated from that supplied by the CPU to the video controller, so that the cursor location can be directly compared to the location of the byte being sent to the screen. This step may be implemented in a variety of ways. According to one method, a cursor location and size are translated to a set of one to eight bit map locations occupied by the cursor. If the cursor has a size taller than one row of an eight row character, more than one byte will be found to match the cursor location, and when the blink is active will be replaced with a cursor indication. Although it is possible to replace a bit map byte with any other byte (for example, the cursor could be a blinking X alternated with the character in the cursor location) , the embodiment described here in detail simply allows for defining the top and bottom of the cursor and forming the cursor as a solid block within these limits in accordance with a software program which conventionally expects a Motorola 6845 integrated circuit chip used with an MDA or CGA card. According to this embodiment in which the location of each bit map address of a multiple byte cursor is stored, when one of the cursor locations matches the address of the byte being transmitted to the column drivers, a time flag is tested to see if the cursor is active (i.e., if the cursor blink is currently on) . If so, the byte is substituted for the binary byte being transmitted to the column drivers of the display. This method has the disadvantage that the cursor appearance cannot be changed when the cursor is superimposed over an inverse character, which might cause the cursor to be difficult to observe. In a variation of the above embodiment, the inverse attribute feature of the character at which the cursor is located is read at the time the cursor is moved and latched by cursor block 30.060. The steps shown in Fig. 4d take advantage of this inverse feature, blanking with a black overlay (byte 00000000) when the character is inverse. The steps of Fig. 4d require cursor block 30.060 to store only the addresses of the top row of the cursor location and of one of the seven font table rows below it, and additionally to store the upper and lower limits of the cursor block. As shown in step 461, the bit map address of the byte currently being transmitted to the column drivers is compared to the address of the cursor location, this address being the bit map address of the top row of the character where the cursor is located. When these addresses match, step 462 is performed, which determines whether the cursor block covers the row being transmitted (the top row at this point) . If the cursor does not cover the top row of the character, no replacing of the current byte being transmitted will occur. The method moves to step 467, which determines whether the eighth row of the character at which the cursor is located has been transmitted. If not, a 1 to 8 counter is incremented and the address to be compared to the address of the byte being transmitted to the column drivers is incremented by 80. The method then moves back to step 461 where the bit map address is again compared to the cursor location. Eighty bytes later, these addresses will again match, the character byte being transmitted will now be on cursor row 2, and cursor row 2 will again in step 462 be compared to the cursor size markers. If the cursor row is now found to be within the specified top and bottom of the cursor, the method moves to step 463 in which the time is examined to see if the cursor is currently active (being superimposed on the bit map character) . If the cursor is not currently active, the method proceeds to step 467 and then to step 468 where the cursor row and the cursor address for comparison are again incremented.

At a later time in the process, step 463 will indicate that the cursor is active, that is, that the cursor blink is to be superimposed on the character in the cursor location. In this case, the flag which was set when the cursor location was stored is tested to see if the character in that location is inverse. If so, step 466 causes the character row to be replaced by the byte 00000000. If the character is not inverse, it is replaced in step 465 by the byte When the eighth row of the cursor is reached, step 467 causes the method to move to step 468 where the cursor row is reset to 1, and the cursor location is reset to the first row of the cursor location. The top row of the original cursor location may be stored for reuse when the eight rows have been compared, or the cursor location may be decremented by 560 when the eight rows have been compared. Cursor Move

The moving and sizing function is illustrated in Fig. 4e. The movement of the cursor is controlled by the CPU, which initiates this process, as shown in step 481, by addressing a series of registers on address bus ADDR[0..19]. There are two bytes of data to indicate a cursor address and successive bytes must be sent from the CPU to specify a new cursor location. Therefore the CPU first provides the address of an index register. This index selects between two cursor registers in the cursor block 30.060. Corresponding data sent to this index register indicate whether the high or low byte of the cursor address will be sent to the cursor register or the height of the top and bottom of the cursor will be sent. These registers are directly comparable to the Motorola 6845 registers for which MDA and CGA software is written. When the index indicates part of the cursor address will be loaded into the cursor location high byte register or the cursor location low byte register, as shown in step 483, signals from system ASIC 18 (Fig. 1) are checked to determine whether the address is to be read or written to. If these signals indicate this data is to be written, the cursor location is latched from the data on bus EXPI[0..7] . If the address is to be read, as shown in step 484, data in the addressed register is sent to the CPU via bus CRSR[0..13] to data MUX 30.090. If the operation is a write, step 485 indicates the data on data bus EXPI[0..7] are latched in the cursor location register (high byte or low byte as specified by the Motorola 6845 compatible index register) . When data for the new cursor location have been latched, the register indicating whether the program is operating in 40x25 mode is checked as shown in step 486. If so, as shown in step 487 the cursor location address is doubled. This address is in character mode format and must be translated to bit map memory format. Therefore, as shown in step 488, the address translation of the address in the two bytes of the cursor location register in 30.060 is read from address translation table 204 using the cursor location address. As shown in step 489, the attribute of the character where the cursor is to be located is also read and latched into cursor block 30.060, in order to determine whether the character is inverse and whether the cursor should be displayed as all black rather than all white .

Circuitry for Implementing Cursor Blink and Cursor Move

The above blinking and moving steps shown in Figs. 4d and 4e are implemented by cursor control block 30.060. The cursor blinking function is accomplished without updating bit map 202. Cursor block 30.060 receives signals on bus LCDADDR[0..13] which address the data currently being sent to refresh the screen. These address data are compared with a cursor address (translated to bit map formap) stored in cursor block 30.060. When the addresses match, cursor block 30.060 sends a signal to translation block 300 to turn off the chip select signal to bit map memory 202 and applies the cursor data (00000000 if the character is inverse and if the character is normal) to bus LCDDTA[0..7] . The column drivers read continuously from this bus, therefore they will read the substituted data which have been applied by translation block 300 under control of cursor control block 30.060. The cursor moving function is accomplished by interaction between the CPU and cursor control block 30.060 in which the cursor location is sent to the CPU by causing data MUX 30.090 to apply the data from bus CRSR[0..l3] to bus DSPD[0..7] which leads to the CPU, and sending (by setting index registers to indicate which parts of the cursor address and size parameters will be sent) through data bus EXPI[0..7] to the cursor registers in block 30.060 the bytes indicating the new cursor location.

Description of Address MUX decode Block 30.110

The blink data bus BLKADDR[0..13] has the highest priority of signals to address MUX 30.020. The cursor bus (for moving, not showing the cursor) CRSR[0..l3] has next highest. Character translation bus VDADDR[0..13] has third priority. Actually these second and third priorities are equal because the CPU will send either a new character or a new cursor location but not both at the same time. If two signals contend for the bus at the same time, for example a blink and a translation, a "busy" feedback signal causes the translation to be put on hold. This prioritizing is implemented in blocks 30.100 and 30.110 of translation block 300.

Function of Address MUX 30.020 of Fig. 3a

When characters and attributes are not being translated or updated, the address provided by address MUX 30.020 on bus XA[0..14] is the address LCDADDR[0..13] provided by synchronization block 30.010. (The 15th bit on bus XA[0..14] selects between memory 201 and memory 202.) The address on bus LCDADDR[0..13] has the lowest priority on address MUX 30.020, that is the address on LCDADDR[0..13] can be overridden by the other devices using address MUX 30.020. However, because the time spent updating memory is small in most applications, most of the time, the address provided by address MUX 30.020 is LCDADDR[0..13] . The address on bus XA[0..14] determines what data are read by the column drivers in response to clock signals DPCLK[0..4] from synchronization circuit

30.010. These five clock signals (shown in Fig. 3c) are a frame synchronization signal FRSYNC sent at the beginning of every screen refresh cycle, a row clock signal ROWCLK sent after all column data for one row have been loaded, a phase clock signal PHCLK which changes polarity of the voltage applied to pixels in the display and is currently sent after each 1, 2, 4, or 8 rows have been loaded, and two column clock signals C0LCLK1 and C0LCLK2, one of which controls loading of the first forty columns and one of which controls loading of the second forty columns. Data placed on these 80 columns are selected from bit map 202 location addressed by the address MUX output address.

Every 1/4 second, if there are blinking characters to be displayed, the LCDADDR[0..13] signals will be overridden by the signals on the BL ADDR[0..13] bus from blink scan block 30.070, under control of the blink request line from blink scan block 30.070 to translation block 300 which in turn causes a signal on a line in data bus DC[0..40] to place the address BLKADR[0..13] on output bus XA[0..14]. After the BLKREQ signal is sent, addresses on BLKADDR[0..13] scan the range of the character/attribute pairs in memory 201 causing memory 201 to place character and attribute data on bus DSPDTA[0..7] to be loaded into translation block 300 and translated, as discussed earlier.

When translation is occurring, either as a result of blinking characters being updated or as a result of new data being loaded into the character memory by the CPU, translation block 300 uses address MUX 30.020. For fetching a character from memory 201, translation block 300 causes data on bus DADR[0..13] , which is the least significant 14 bits of the address provided on bus

ADDR[0..19], to be placed on bus XA[0..14] thereby causing data from that address in character memory 201 to be placed on bus DSPDTA[0..7] for latching by translation block 300. A similar process occurs for fetching an attribute. When translation block 300 has fetched the character and attribute on bus DSPDTA[0..7] , a translated group of eight bytes are output on bus LCDDTA[0..7] and loaded into memory 202 as addressed on line VDADDR[0..13] and selected by address MUX 30.020 in response to signals on lines ADRMX1 and ADRMX0 from block 30.110 in translation block 300. If a translation is occurring at the same time blink scan block 30.070 indicates an update is to be done, the blink scan takes priority and the translation is delayed.

In addition to causing bit map data on data output bus LCDDTA[0..7] to be written into bit map memory 202, address MUX 30.020 causes character data on translation data output bus LCDDTA[0..7] to be written into character memory 201. The least significant fourteen bits of the untranslated address provided on 20-bit CPU address bus ADDR[0..19] is provided by translation block 300 on bus DADR[0..13] to address MUX 30.020. This is the address of the character memory and is used to update the character or attribute in character memory 201 and also to fetch the corresponding character or attribute from character memory for use in updating the bit map. When the character and bit map memories are not being updated, which is most of the time the computer is turned on, address MUX 30.020 provides the address of the liquid crystal display byte currently being refreshed. When this address is the address of a byte in bit map memory 202, bit map memory 202 places that byte onto data output bus

LCDDT [0..7] . This byte is read by LCD driver circuitry and loaded into a column driver shift register for driving columns of the display screen. This LCD driver circuitry is described in detail in commonly assigned copending application serial no. 07/374,340, attorney docket no. M- 806, entitled POWER SYSTEM AND SCAN METHOD FOR LIQUID CRYSTAL DISPLAY, which is incorporated herein by reference.

As a novel feature of the present invention, data output bus LCDDTA[0..7] is used for both updating memories 201 and 202 and for loading data into the display driver shift registers. Since data from this bus are loaded to the column driver shift registers continuously under control of synchronization signals from synchronization block 30.010, erroneous data will be loaded onto the column drivers when the memories 201 and 202 are being updated. However, the time needed to update these memories is much shorter than the response time of the liquid crystal display screen, so the erroneously loaded data are not observed by the user of the computer and are replaced with correct data on the next refresh cycle of the display screen.

Description of Data MUX 30.090 of Fig. 3a

Data MUX 30.090 feeds data back from the video controller to the CPU. Data from one character memory 201 is used by the CPU for scrolling the screen, for example, and also for moving the cursor. Control lines from translation block 300 and cursor block 30.050 cause data MUX 30.090 to place on CPU data output bus DSPD[0..7] data from locations in memories 201-204 (as selected by address MUX 30.020) or from cursor block 30.050 on bus CRSR[0..l3] in response to a request from the CPU.

Detailed Schematics

Fig. 5 shows that portion of peripheral ASIC 17 (Fig. 1) which implements the functions shown in Fig. 3a. Fig. 5 is an overview schematic including block diagrams which are shown in detail in Figs. 6a through 6w.

Numbering in the lower right corner of Figs. 5 and 6a through 6w is hierarchical. The number in the lower right corner of Fig. 5 ends in three zeros. Eleven blocks are shown in Fig. 5, each numbered with a number ending in a zero. At least one figure of Figs. 6a through 6w describes the eleven blocks of Fig. 5 and has a number in its lower right corner corresponding to the number on the block of Fig. 5. Within some of Figs. 6a through 6w are sub-blocks also labeled with reference numbers not ending in zero. Subsequent figures labeled in the lower right corner with corresponding numbers shown the content of these blocks. Line, bus, and block names and numbers in Figs. 3a and 3b correspond to those having the same names and numbers in Figs. 5 and 6a through 6w. Each figure includes, in addition to the blocks, a list of signals entering and exiting that block, each signal name surrounded by an arrow. Signals on buses more than one bit wide have names specifying the number of lines in the bus. For example, in Fig. 5 at the upper left, the signal from the CPU giving the address to be dealt with, ADDR[0..19] is on a 20-bit bus. The next signal, which is data from the CPU, is EXPI[0..7] and is on an 8-bit bus.

Figs. 5 and 6a through 6w show in detail a presently preferred embodiment of the invention. The circuit of Figs. 5 and 6a through 6w has been manufactured using an application specific integrated circuit chip as implemented by LSI Logic Corporation. Names of lines, buses, and gates meet the specifications of LSI Logic Corporation and can be used to generate a net list of gates to be connected in an ASIC chip. The circuit of Fig. 5 and 6a through 6w has been tested and shown to successfully perform the video controlling functions of this invention.

In Fig. 5, blocks 30.010, 30.020, 30.060, 30.070 and 30.090 perform the functions discussed in connection with correspondingly numbered blocks in Fig. 3a. The remaining six blocks perform the functions of translation block 300 of Fig. 3a.

LCD control register block 30.040 performs the functions of a Motorola 6845 chip which is used in a conventional MDA/CGA system. Registers indicate whether the computer is to operate in graphics or text mode and which of two text modes 25x40 or 25x80 is to be used. They also hold data to indicate which page is currently in the display window.

Video display load block 30.050 implements the function shown in step 402 of Fig. 4a of writing characters and attributes to character memory 201 when the address on ADDR[0..19] is in the range of character memory 201 (there are actually two ranges, one for black and white MDA mode and another for color CGA mode) . If the data loaded in response to the address on ADDR[0..19] is an attribute, video display load block 30.050 latches the corresponding character, reads the translation address from translation address table 204 (step 406 of Fig. 4a) , multiplies by 8 the character code received on bus EXPI[0..7] to form the address in font table 203 (step 407 of Fig. 4a) , adds 2048 to this address if the attribute is bold (steps 408 and 409) and increments this address (step 412 of Fig. 4a) . Step 415 of incrementing the bit map memory 202 address by 80 is performed in Add 80 ALU 30.080 of Fig. 5. Data control block 30.030 latches the attribute entered on bus EXPI[0..7] or read back from memory 201 on bus DSPDTA[0..7] and decodes this attribute, providing bit map data on bus LCDDTA[0..7] .

Display control blocks 30.100 and 30.110 generate control signals which clock the operations performed by other blocks. Figs. 6u through 6w show in detail the operation of these blocks. Signal and block names correspond to those used in Fig. 3a and Fig. 5.

The invention is not limited to the embodiment shown in detail in Fig. 5 and 6a through 6w. Other embodiments will become obvious to those skilled in the art in light of the above discussion and are intended to fall within the scope of the present invention.

Claims

CLAIMSWe claim:

1. A video controller for a liquid crystal display comprising: means for generating characters to be displayed by said liquid crystal display; a character memory for storing character codes of said characters in locations representing locations on said liquid crystal display at which said characters are to be displayed; a display bit map memory having bits which correspond on a one-to-one basis with pixels in said liquid crystal display; means for translating said characters codes in said character memory into bits in said display bit map memory; and means for refreshing said liquid crystal display by reading said bits from said display bit map memory.

2. A video controller as in Claim 2 in which said character memory is MDA compatible.

3. A video controller as in Claim 2 in which said character memory is CGA compatible.

4. A video controller as in Claim 1 in which said character code is used by said means for translating as an index to a font table, said font table providing data which is copied into said bit map memory.

5. A video controller as in Claim 1 in which said means for refreshing comprises circuitry not controlled by a microprocessor clock.

6. A video controller as in Claim 1 in which said means for translating and means for refreshing use a common bus in which use occurs concurrently.

7. A video controller as in Claim 1 including separate clocks for translating and refreshing.

8. A video controller as in Claim 1 including at least one additional row in said display bit map not generated from said character map, said additional row for displaying information other than characters.

9. A video controller as in Claim 8 in which said display bit map includes 201 rows, one of which is for status information.

10. A video controller as in Claim 1 further comprising a bus for loading said character fonts into said display bit map memory, said bus being simultaneously used by said means for refreshing said display.

11. A video controller as in Claim 1 further comprising means for periodically replacing some of said bits in said bit map memory which correspond to blinking characters in said character memory for which attributes indicate said characters are to be blinking.

12. A video controller as in Claim 1 further comprising means for storing a cursor address which matches an address in said bit map memory and periodically replacing data sent to said liquid crystal display when said means for refreshing said liquid crystal display is refreshing from an address in said bit map memory which matches said stored cursor address.

13. A method for controlling a liquid crystal display comprising the steps of: generating characters to be displayed by said liquid crystal display; storing in a character memory said characters in locations representing locations on said liquid crystal display at which said characters are to be displayed; translating said characters in said character memory into bits in said display bit map memory; and refreshing said liquid crystal display by reading said bits from said display bit map memory.