VIDEO DISPLAY APPARATUS

Abstract: Address signals are generated corresponding to successive points of a raster-scan display field (4). Comparators (3) compare the addresses with limit addresses of window areas of the display and when an address falls within a window area, store addresses are generated for accessing stored video data (1).

Description: VUXO DISPLAY APPARATUS The present invention is concerned with video display apparatus. According to the present invention there is provided a video display apparatus comprising timing means for generating address signals representing successive points within a raster-scan display field; a store for containing video data; a plurality of comparators each arranged in operation to compare the address signals with window limit addresses representing the limits of a respective window area within the display field; and to produce an enabling signal when the relevant point is within that window; store addressing means responsive to the enabling signals to produce or store addresses corresponding to the relevant point(s) and output means for output of video data read from the store. In another aspect the invention provides a video display apparatus comprising timing means for generating address signals representing successive points within a raster-scan display field; a store for containing high-resolution video data capable of representing a plurality of grey-scale levels; means for storing data relating positions within the display field to store addresses; and store addressing means to produce store addresses corre.sponding to the point of the image to be displayed and output means for output of video data read from the store. Preferred features of the invention are defined in claim 2 to 11 below. One embodiment of the invention will now be described, by way of example, with reference to the accompanying drawings, in which- Figure 1 is a diagram illustrating indirect addressing; Figure 2 is a block diagram of a video display apparatus according to one embodiment of the invention; and Figure 3 is a more detailed block diagram of the di.splay controller used in Figure 2. Before discussion of the display apparatus, attention is directed to Figure 1 which illustrates the window addressable memory concept employed. The main advantage of such an indirect addressing scheme is that since the memory array is not bit mapped to the screen, it becomes possible to move pictures by simply changing the virtual address of the picture, rather than physically moving the picture data within the memory array. Although the lookup table approach could be used, it requires a large amount of memory and therefore the use of window addressable memories (WAMs) is preferred. Figure 1 presents the concept behind this approach to indirect addressing in schematic form. The picture data is stored as a continuous block in a memory array 1, with the start address of the data being stored in a start address latch 2. A window addressable memory 3 (shown for simplicity with only a single location) acts to determine whether the current screen write position x,y is within the rectangular picture boundary (illustrated at 4) or not. Each location consists of four comparators and four latches, with the latter storing the coordinates (x in, y min, x max, y max) of the picture bounding rectangle. As each new screen address is generated, (by an x and a y counter which are driven by the di.splay timing signals), it is compared with the values held in the latches, and the output (a single wire) of the window addressable memory indicates whether the screen address is within the picture window. If the current screen address is within the window, this output increments a "current address" counter 5, whose output is used as the read address of the picture data within the memory array. The current address counter is reset to the value stored in the start address latch 2 at the begining of every frame. If the screen address is outside the picture window, the output is used to select a background colour, which could be stored at a single address within the memory array. This basic architecture, allows a high functional performance to be achieved, in that a picture can be moved or .scrolled across the screen simply by changing the window information stored in the latches. In addition, frame stores for the display of either small or low resolution pictures need be equipped with only as much memory as is necessary to store the picture information. Alternatively, high performance frame stores could be constructed with sufficient memory capacity to store several frames of data, and the indirect addressing scheme would then allow rapid switching between previously downloaded frames through manipulation of the window information. A block diagram of the display apparatus is shown in Figure 2, comprising a controller 10, memory array circuitry 30, and interface circuitry including latches/buffers -40, output digital to analogue converters 50 and first in first out (FIFO) stores 60,61 and buffers 62,63 for interfacing to a host computer whose data bus is shown at 70. The memory array 30 is assumed to provide sufficient memory for a 540x480 pixel array, with 16 bits per pixel (8 bits luminance, plus 8 bits each for the u and v colour difference signals, shared by two pixels - ie the horizontal chrominance resolution is half that of the luminance). This implies a total capacity of 4.15 Hbits and a video output rate of 13.5MHz (ie 16 bits need to be read out every 74.1ns). The memory array might typically be organised as 64K x 64 bits - eg 16 off 64Kx4bit dynamic RAM chips - the data for four pixels being addressed simultaneously, latched, and multiplexed in latches/multiplexers 40 thereby rec icing the memory access time requirement. The data communication between the host computer CPU and the frame store is carried out using a first-in first-out store 60,61 (FIFO). This acts as a buffer which allows the CFU to communicate with the frame store at any time, rather than just during display blanking periods (but see below for "grab mode"). The FIFO could be implemented by using a fast static RAM, with a minimum cycle time of 75 nS or less. The FIFO would operate by using two cyclic counters acting as address generators. During data transmission from the CPU to the frame store, the write counter would increment until it was point to the location one below the read counter. A comparator would then inhibit the write coulter and a signal would be sent to the CPU to indicate that the buffer was full. This state would continue until the read counter was incremented by the frame store controller reading data out of the FIFO. A signal would then be sent to the CPU to indicate more space was available and transmission could recommence. The operation for transferring data to the CPU would be exactly the same except the two counters would interchange roles. A block diagram of the controller 10 is shown in figure 3. The key component in the device is the address translator unit 11, which operates to calculate the physical address of picture data from a virtual screen address of the picture. Pictures are represented and manipulated as "windows" of information, specified by a window nurπber and its bounding rectangle on the screen. Other circuitry includes a pair of counters 12 whose outputs represent the row and column of the current screen write position, a freespace ounter 13 which is maintained during CRJ write operations to indicate the position of unused memory within the memory array, read and write counters 14,15 which are used during CPU read and write operations, a refresh counter 16 which is maintained to provide systematic refresh of the dynamic memory array 30, a FIFO control unit 17 which supervises data transfer between the memory array and the CFU, a scroll control unit 18 and an overall control unit 19, which generates all required control signals and decodes commands from the CPU. Finally, a programmable timing chain 20 is included which is used to generate the display synchronisation and blanking signals and to control the position of a cursor on the screen. The address translator unit 11 is constructed from a window addressable memory 110, a priority decode unit 111 and an array of address counters 112, each with an associated latch 113 which stores the physical start address of its window within the memory array. Each start address latch is loaded with the contents of the freespace counter when its window is created and written to the memory array by the host CRJ. All address counters 112 are preset to the address stored in the latches 113 at the start of each field (but see below for interlace operation)frame. Each location within the window addressable memory 110.corresponds to a window number, and stores two pairs of x-y coordinates which represent the window's bounding rectangle on the screen, with a separate location being provided for each stored window. As explained above with reference to Figure 1, the outputs of the row and column counters are input to the memory 110 which evaluates whether the screen write position is within any of the stored windows. Three outcomes are possible, (a) .the current screen write position is in only one ' of the stored windows, (b) it is more than one of the stored windows and (c) it is in none of the stored windows. In the first case, the output from the selected address is used to select the output of the appropriate address counter 112 as the physical address to be supplied to the memory array 30, then the selected address counter 112 is incremented to maintain the position within the physical store. In the second case, the priority decode unit 111 is used to select one of the counter outputs as the physical address, and the address counters of all selected windows are incremented. The priority of window addressable memory sections 110a, 110b etc could be fixed, each with a 1-bit yes/no -output to the priority decoder, or could output the contents of priority word latches 114a, 114b etc. The priority decode unit would then operate on an array of words each representing the priority of its window. The priority of a window would be set as it was written into the frame store, and could subsequently be altered by the host processor. In this way, pictures can be overlaid and moved across one another. If the current screen position was not in any of the stored windows a further output of the priority decoder becomes active to indicate that the background colour, stored in a single memory location, should be selected. This is accomplished by setting the picture data address to the value stored in an on-chip background address latch 115. The window addressable memory may also include flag bits V,B,A in the latches 114a, 114b. A useful feature which can be provided is a 'viewport' facility, which defines the overall active area on the screen. This can be achieved by designating one or more window addressable memory location(s) - by setting flag bits V - as storing the bounding coordinates of rectangular viewport(s). If the current screen position was outside all of the defined viewports, the address of a border colour, stored and accessed in the same manner as the background colour, described above, would be output onto the controller's address bus. If the current screen position was within any of the defined viewports, the output address would be calculated on the basis of the information stored on the remaining (non-viewport) locations within the window addressable memory. In order to allow both normal (ie photographic) and block filled windows to be processed, it would be possible to provide an additional 1 bit "B" for each window, which would be set on creation of a window to indicate its type. The output of the latch would be used to disable the corresponding address counter when a block filled window is selected, so as to keep the output address pointing at a single memory location. To accommodate display sizes up to-1024 by 1024 pixels, with four pixels being stored at each physical memory address (with a 64-bit word size), the row and column dimensions of the window addressable memory would be 10 and 8 bits respectively, and each address counter and associated address latch would be 18 bits long. The length of the priority words P depends on the number of windows that can be implemented. Estimates of circuit areas indicate that it should be feasible to implement around 8 windows, implying that an appropriate priority word length,would be 3 bits. It would be useful to store one additional bit A in the priority word which would indicate whether a particular window was active, ie visible, or not. The priority unit iself can be implemented as maximum search CAM (content addressable memory), which subjects the priority words to a parallel maximum search and outputs the address of the maximum as its result. In order to set up or alter the priority information it would be necessary to write the complet set (for 8 windows = four 8 bit words), to the controller. Two further refinements of the basic architecture are required to cope with high resolution and variable display format windows. The first concerns the display of high resolution windows in which one frame of data is produced by two successive interlaced fields. In these cases it is envisaged that the data from one field of information (eg the odd numbered lines), would be stored in one continuous block of memory, and the data from the second field (that even numbered lines) stored in a second continuous block. To display such windows it would be necessary to duplicate the start address latch associated with each window in the address translation unit, and to load the current address counter in alternate fashion from these latches at the start of each field. The second refinement is to allow the display of variable display format windows, such as fixed colours from a colour pallette or monochrome. In these cases the window addressable memory and priority parts of the address translation unit would operate in the normal fashion, however since the windows would be stored in the same memory array as the normal 4.2.2 format windows, ie one in which 64 bits of information are accessed in each memory address cycle, some allowance must be made for the number of pixels that are displayed from each memory address. For example, in the 4.2.2 case each address increment corresponds to four pixels of information, whereas in the monochrome case each increment would corre-spond to 64 pixels worth of information. This variation in pixel rate can be accommodated by providing a programmable prescaling counter at the input of each current address counter in the address translation unit. In the two examples given above the prescaler would be set to divide by 1 (ie be bypassed) and 16 respectively. A further consequence of the requirement to simultaneously display variable format windows is that it would be necessary to provide additional external circuitry of suitable format at the memory array output, and also to provide the necessary control circuitry for the external devices on the controller chip itself. The minimum operational cycle time of all parts of the address translator is 4 times the dot clock period, ie approx 300 nsec for a 13.5MHz dot clock. The row and column counters 12 would be implemented as 10 bit counters to allow for a maximum display size of 1024 by 1024 pixels. Only the most significant 8 bits of the column counter would be supplied by the window addressable memory to allow for the fact.that 4 pixels are stored at each memory address in the array. The basic display resolution will be determined by the signals supplied from the timing chain. These will determine how many dot clocks per line and how many line clocks per field are passed to the column and row counters, respectively. Half resolution mode may be supported by having a selectable divide by two function on both clocks. The freespace counter would be implemented as an 18 bit counter and incremented as data is written to the array to maintain a pointer to the next free memory location. Some additional circuitry would be necessary to give notice to the CFU when all available space is used. The read and write counters would also be implemented as 18 bit counters. When a complete window of data is to be read from the memory array to t-he CPU, the read cointer would be loaded with the window start address, as held in the appropriate start address latch. If only part of a window is to be accessed, the CPU would -first haver to read the window start address from the controller chip, add an appropriate offset to it, then write this information to the controller read counter. In both cases the read counter would then be incremented as data is read from the array to the FIFO, with its output supplying the read address to the memory array during valid CPU access periods. When a complete window is to be written to the array from the CFU, the write counter would be loaded from the freespace counter and then incremented as data is written to the array, with the counter output supplying the write address to the memory array during v.alid CPU access periods. When part of an existing window is to be modified, the write counter would have to be loaded with an appropriate start address, calculated in the same way as described above for the read operation. In the indirect addressing scheme the memory array is not accessed in a sequential manner, and only those portions of the array which hold active picture data will be accessed in each frame. It is therefore necessary to provide circuitry which will systematically instigate refresh read cycles during part of the display blanking periods. This function is performed by the refresh counter 16, which will be cycled through the RAM column addresses. The FIFO control unit 17 has to supply the necessary control and address signals which will allow a static RPM to perform as a FIFO buffer between the CPU and the memory array. This can be achieved using a pair of counters, one which holds the current FIFO read address, the other the current write address. For a IK FIFO the counters would be 10 bits long. The scroll control unit 18 is implemented as a simple ALU which would operate on the window bounding box coordinates xmm, Xmax, Ymin, Ymax to effectively scroll a given window on the screen, the amount and direction of the ascroll being sent as part of commands from the CPU, as would the amount of scroll per frame (scroll rate). The main control unit 19 operates to decode and execute commands from the CPU, and to generate all control and timing signals that are required, both internal and external to the controller chip. It could be designed as a synchronous finite state machine and would be implemented using PLA's and random logic as appropriate. The timing chain and cursor control unit produces the necessary display blanking and synchronisation signals, and could also produce strobe sginals which enable a cross hair cursor to be displayed. The timing chain parameters are preferably programmable to allow a variety of video standards to be supported. As far as timing is concerned, the controller chip might be capable of two basic modes of operation, master or slave. When it was operating as master timing- generator in a di.splay system, it would generate the vertical and horizontal blanking and synchronisation signals from a simple clock input. A composite sync, signal to a standard format would also be generated, and provision would be made to allow mains synchronisation using a hold signal which would delay the vertical sync. pulse. In thise mode of operation all timing signals would be available at the chip boundary to allow synchrcniasation of any other di.splay controllrs in the system, and for use in driving the display itself via suitable external driver circuits. In slave mode, the controller chip would be supplied with the four main timing signals, namely vertical and horizontal sync, and vertical and horizontal blanking pulses, together with the dot clock input. Selection between the two timing modes could be achieved by setting a logic level on a mode select pin. It is envisaged that the actual timing signals would either be output or input via bidirectional drivers, to reduce pin count. The timing chain may be implemented as a set of programmable counters and comparators, with the degree of programmability being chosen to allow a sufficient variety of video standards to be supports, and programmed by a set of commands sent to the controller by the host CPU in the normal fashion. The cursor controller may be implasmented as a pair of programmable equality comparators, which operate on the outputs of horizontal and vertical counters in the timing chain. These comparators would be loaded with the cursor position by the CPU, and the logical 'or', of their outputs would be taken to the chip boundary where they would be used to switch in a cursor colour at the memory array output. A useful additional feature would be the inclusion of an extra pair of cursor comparators. This pair would again be loaded by the CFU and would serve to place a static cross hair marker on the screen, leaving the first pair free for normal cursor movement. This feature would be used to define windows on the screen. In order to illustrate the combined operation of the various components of the indirect addressing controller, the following sections described the command interface between the host CPU and the controller. It is envisaged that all commands would be sent to the controller via the host processor data bus 70, in a manner similar to standard microprocessor peripheral control. The hardware interface may be configured to suit 8 bit microprocessors, with the data bus to the controller chip being 8 bits wide. The commands explained in detail below are the main commands concerned with the creation and manipulation of picture windows. Other commands which could be supported are those for the setting of various parameters, such as timing information and cursor control, and those which provide basic functions such as software reset. (a) Write Window The basic CPU to memory array write operation is a create window command, which would be used to create a new window of information on the screen. Three basic types of window can be created, a viewport, a block filled window, or a photographic window. In all three cases, a window n-umber, which indicates which window addressable memory location/address counter is to be used, would be embedded within the command word. The create viewport operation would be achieved by the CRJ sending a command word, followed by a string of data words, which represent the viewport bounding box coordinates, to the controller. These coordinates woudl be written into the selected window addressable memory location, and the single bit viewport latch V associated with that location would be set to indicate the window type. The create photographic and create block filled window commands would both commence with the transmission of the appropriate command word to the controller. On receipt of this command the controller would first of all store the contents of the freespace counter in the selected start address latch and in the write counter, then reset the FIFO control unit. The controller would then indicate that it was ready to receive picture data from the CPU, which in turn would start to write data to the FIFO input. During di.splay blanking data would be transferred from the FIFO to the memory array, with the freespace and write counters being incremented in unison, the latter being used to supply write addresses to the memory array. The CRJ would indicate completion of the write operation (after the transfer of a single pixel of information in the block filled case) by sending further commands to the controller, which would include the window coordinates and priority of the data that has been transferred. These items would be stored in appropriate locations within the address translator. In the csse of photographic window creation, additional data which specified the display format of the window would have to be sent to the controller. For the creation of high resolution interlaced windows, the windows of data would be transferred in the normal manner, however, on creation of the second window, the freespace counter contents would be written into the alternate start address latch, and a single bit latch would be set to indicate the window type. In the block filled case the block filled latch in the selected window addressable memory location would be set. (b) Modify Window A further write window command that may be supported is the modify window command, which would be used to change the contents of part of an existing window. To perform this operation the CRJ would first of all read the start address of the window from the controller chip. It would then calculate an offset based on the window size which takes it to the desired point within the window. The CRJ would then send the modify window command to the controller followed by an address, formed as the sum of the start address and the offset, which the controller would store in the write counter. The controller would reset the FIFO control unit, and the CRJ would then proceed to write data to the FIFO input. The controller chip would then transfer the data from the FIFO to the memory array. It would be the responsibility of the CPU to perform memory management calculations to ensure that the amount of data transferred did not exceed the capacity of the window. (c) Read Window Two basic types of read window command would be supported, one which allows the data to be specified by window number, the other specifying the data by address. The first type of read operation would be instigated by the CRJ sending a read window command to the controller chip. A window number, which indicates irfύch window addressable memory location/address counter is to be used, would be embedded within the comand word. On receipt of this command the controller would first of all reset the read counter to the contents of the selected window's start address latch and reset the FIFO control unit. During display blanking periods data would be transferred from the memory array to the FIFO, with the read counter being used to supply read addresses to the memory array. Once some data has been written into the FIFO the controller would indicate that it was ready to send daa to the CRJ. The CRJ would access this data by supplying a simple read clock to the FIFO control unit. The CPU would terminate the read operation once .sufficient data has been accessed, by sending a stop command to the controller. The second type of read operation, which would be performed when it was required to read part of a window at some offset from the window start, would be performed in a similar manner to the one described above, except that in this case the read counter would be loaded with the appropriate address by the CPU at the start of the operation. This address would be calculated by the CRJ in the same way as described above for the modify window command. (d) Move Window Two types of move window command could be supported, relative and absolute. The first type would be implemented using the scroll control unit. The CPU would send a move window command to the controller, (with the window number embedded in- the command as before), followed by dx and dy data words which specify the magnitude of the move. At the start of the next frame, the ALU within the scroll control unit would add the dx and dy data into appropriate components of the selected window coordinates, and then return the results to the window addressable memory. The absolute move window operation would be performed by the CRJ transmitting new window coordinates to the controller, which would overwrite the old coorodinates to the selected window with these values. (e) Scroll Window The simplest way to implement the scroll window function is for the CRJ to send a dx and a dy increment to the controller, followed by two data words which specify how many times each has to be applied. The scroll control unit would then operate to add the increments into the selected window coordinates once per frame, until the speicified number of increments have been made, (f) Grab Mode Grab mode is required to fill the memory array with real time data from a video camera. To implement this function normal controller operation, apart from mmory refresh, would be suspended. The freespace counter would be reset, then incremented as data was written into the array, the counter's output being used to supply write addresses to the array. The input FIFO would be bypassed in this mode of operation. At the end of the operation it would be necessary for the host CRJ to write the window coordinates of the grabbed frame to the controller chip. An additional feature that might be provided is to permit "transparent" areas within a window thereby allowing part of a lower priority window to become visible. This could be achieved by providing an additional bit in the memory, or (preferably) reserving a special code - eg the luminance range could be limited to 0000 to FFFE (hex), FFFF indicating transparency - so that a window selected by the address translator can be temporarily deselected. One problem with this approach is that of memory access times, since, the memory having been read and a transparent pixel found, a further memory access is required to obtain the data for the next lower priority window. If more than one overlapping tran.sparent area is permited to occur, the problem becomes much worse, and the number of .such layers needs to be limited. In order to alleviate this problem, it is proposed that windows with transparent pixels be marked with a transparent attribute. When a transparent window has the highest priority the controller alternately addresses a memory slice (64bits) from the- upper window followed by a slice from the underlying window. The data selector will require a second 64 bit latch and multiplexer to enable the pixel colours from either slice to be selected for display. When a pixel from the multiplexer of the upper window is detected to be transparent the pixel from the second window multiplexer is selected. Transparency can only operate if neither window required the full memory bandwidth (13.5MHz/16 bit). Since two fetches have to be made before any pixel is displayed there is now a two cycle time delay acrosss the whole display line. In fact for low resolution windows the controller could be designed to send the same data slice every 300ns. If the mode does not change between slices the pixel pointer in the selector will simply progress to the next pixel. When the mode changes the pointer is reset to pixel 0 of the slice. Note a new window (and new mode) can only start with a new slice at pixel 0. The display mode of each data slice must be loaded into the data selector in order that the active pixel from both slices are kept in synchronisation. To have transparency between windows where one or both contains photographic information, as full resolution cannot be supported, a 6.75MHz photographic mode is required. To avoid the need to have a special mode it is possible to generate 6.75MHz data by storing alternate pixel in consecutive slices. Normally with a non-transparent window both lices would be loaded into the two multiplexers and pixels would be selected alternately -from either multiplexer output. Thus, display data accessed following access to a transparent area be displayed at a lower resolution; eg by reading out the data corresponding to alternate pixels. Brief mention has been made of graphics; in general, provision can be made for some windows to be of lower resolution. This can be achieved by providing a latch for each window specifying the format. Clearly both the number of bits per pixel and the number of pixels can be varied. As mentioned above, a full-resolution display might have 8 bits per pixel and 512 or even 1024 pixels per line (8+8 bits 256 or 512 chrominance), whilst a graphics display might have the same or lower spatial resolution, but only 8 or even four bits per pixel specifying one of a range of colours provided by a colour lookup table. Text of course could also be provided, and, the use of a "transparent" background could provide text or graphics overlay over a full resolution image. Where (say) a 16 location colour lookup table is employed, only 16 colours from perhaps a wider range of colours are available, and here provision may be made for changing the contents of the lookup table during the course of a single field scan. It is proposed that this be achieved by storing a substitute colour lookup table in a normal display window, the window being flagged as transparent or inactive by setting the flag A in the flag register 114, so that, although read out in the normal way its contents are not displayed but loaded into lookup table store.

Claims: CLAIMS 1. A video display apparatus comprising timing means for generating address signal representing successive points within a raster-scan display field; a store for containing video data; a plurality of comparators each arranged in operation to compare the address signals with stored window limit addresses representing the limits of a respective window area within the display field and to produce an enabling signal when the relevant point is within that window; store addressing means responsive to the enabling signals to produce store addresses corresponding to the relevant point(s), and output means for output of video data read from the store. 2. An apparatus according to claim 1 including priority control means arranged in the presence of more than one enabling signal to-determine which window area is to be displayed, and to control the store addressing means accordingly. 3. An apparatus according to claim 2 in which the comparators are assigned a fixed order of priority. 4. An apparatus according to claim 2 in which each comparator has an associated register for storing a priority code, the priority control means being arranged to determine the priority of the comparators in dependence on the values of the stored priority codes. 5. An apparatus according to claim 2, 3 or 4 including means for recognising when the video store contains information representing a transparent area, the priority control means being arranged in the event of such recognition to enable the store addressing means corresponding to the active window (if any) of next lower priority. 6. An apparatus according to claim 5, arranged in response to such priority transfer occurring once or more than a predetermined number of times in respect of the same display point to reduce the display resolution. 7. An apparatus according to any one of the preceding claims in which the store addressing means comprises a start address register which can be preset with the address of the store location containing video data of a first point of the associated window, and a store address counter which is arranged to be loaded with the contents of the start address register at the start of each field scan and which is progressively incremented whenever the associated enabling signal is present. 8. An apparatus according to claim 7, for generating an interlaced display, in which each addressing means has a pair of start address registers which are employed on alternate fields. 9. An apparatus according to claim 7 or 8 in which the display resolution is different for different windows and/or is variable, and the rate at which the store address counters are incremented is controlled in accordance with the required resolution. 10. An apparatus according to claim 9, in which at least some windows have, or are capable of having, a display format in which the video data c-omprises codes designating ones of a restricted range of colours determined by means of a colour lookup table. 11. An apparatus according to claim 10 in which one or more of the windows is capable of being rendered inactive for display purposes, the corresponding data in the video store being nevertheless read out and used to change the content of the colour lookup table. 12 A video display apparatus comprising timing means for generating address signals representing successive points within a raster-scan display field; a store for containing high-resolution video data capable of representing a plurality of grey-scale levels; means for storing data relating positions within the display field to store addresses; and store addressing means to produce store addresses corresponding to the point of the image to be displayed and output means for output of video data read from the store.

Inventors: HUDSON GRAHAM P, REID JAMES R C, TRICKER DENNIS JOHIN, HUDSON, GRAHAM, P., REID, JAMES, R., C., TRICKER, DENNIS, JOHIN
Applicants: BRITISH TELECOMM, BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY
Application year: 1986
Main classification: G09G1
IPC codes: G09G5