Interface Methods For A High Performance Raster Refresh Buffer A Kossow January 1985 A critical issue in the design of a high-performance raster display is the method used for updating pixel data on the screen. Currently, the AED displays perform all drawing primitive operations under the control of the local 6502 processor. To increase the performance of repeating patterns and solid fills, a 'stipple board' was added. The board reduces the time of drawing pixels by reducing the time required to write pixels into the refresh buffer (approx 1uS / pixel). The direct control of the refresh buffer by the local 65816 processor in the 1280 terminal would introduce a severe performance bottleneck in drawing performance because of the disparity between the speed at which pixel data can be written (~300ns) and the speed that the 65816 can compute what to do next (~2000ns). As an example, drawing a square 100 * 100 pixels would take 20 mS to draw under direct control of the 65816, compared to 3.3 mS written as fast as the refresh buffer could write, and 330 uS using 10 pixel at a time writes. Because of the disparity in next pixel calculation time with the 65816 and the write speed of the refresh buffer, the decision was made early in the development of the 1280 to incorporate hardware to perform some of the primitive drawing operations for the 816. The original design of the 816 interface had a large number of discrete counters and registers which allowed the refresh buffer to directly synthesize refresh buffer addressses to draw vectors and filled rectangles. An equivalent circuit to the stipple generator board was also included in the data path to the refresh buffer, along with an 8 bit ALU, to speed up pattern fills and character generation. The parts count for a discrete solution to generating refresh buffer addresses and generating repetitive patterns appears very large. Also, the design and checkout time of these cast-in-hardware algorithms is greater than an alternative approach, a micro-programmed refresh buffer interface. A microprogrammed refresh buffer interface has the following advantages: - Shorter hardware development / checkout time - Parallel microcode and hardware development ( The drawing algorithms would be implemented by the software group in parallel with the hardware effort ) - The operations performed by the refresh buffer interface could be easily expanded later without adding more parts, just by adding more microcode - Micro diagnostic routines could be included - Much higher level operations ( such as complete initialization of the refresh buffer or clipped vectors ) can be implemented in the microcode. Implementation of very complicated commands are impractical to implement directly in hardware because of limitiations in parts count. - Firmware required on the 65816 to perform drawing is much simpler because most of the time-critical or complicated work is done in microcode. The firmware and microcode development can also proceed in parallel once the functional specification for the refresh buffer interface ( which is directly under the control of the microcode ) has been defined. - The interface between the 'outside world' and the refresh buffer is programmable, making upgrading to a new processor simpler. A Microprogrammed Interface Implementation The interface between the refresh buffer and the local cpu would occur directly under microprogrammed control. A pair of sixteen bit input and output registers would be shared between the data bus of the 65816 processor and the data path of the microprogrammed controller. A block of 256 locations in 65816 address space would map to the register pair. The address presented by the 65816 would be translated into a starting address in the microcode which would perform the operation requested. The operation could be a simple register read or write, or could be a high-level operation such as panel fill. A 'busy' control line would be readable from the 65816 side to inhibit processor read or write requests while the microcode is busy. All control of the refresh buffer passes through the microprogrammed interface. This permits the person writing firmware on the 65816 a level of abstraction above the physical refresh buffer hardware. As an example, the updating of the lookup table rams occurs by specifing the starting address in lookup table ram of the first red, green, or blue entry to update. The three bytes of lookup data would be written into the specified table location during blanking, the pointer would be advanced to the next lookup table address, and busy would be negated. Another possible macro command for the lookup table would intialize the color tables to the AED (or 4115) standard table values, or to a monochrome ramp. Upgrading the 1280 for 4115 Emulation Using the microprogrammed interface, NO changes would be necessary to the control, memory, and ecl boards of the current refresh buffer to upgrade the 1280 to handle 4115 / display list capabilities. All changes would be made to the terminal's processor board. The micro progammed interface would directly interpret requests to draw and clip vectors and rectangles in screen coordinate space. The processor board would be modified to include a much larger RAM array (for the display list) and a hardware multiplier / divider to accelerate rotation, translation, and scaling of points in world-coordinates and would scale the transformed points to screen coordinate space for the refresh buffer to display.