Proposed Configuration

This is our original intended configuration. The two 4414s with the attached RAM had enough RAM capacity for 2 frames at 2-bit grayscale. The grayscale would be acomplished by alternating frames. Both the buffer chips would only have a very simple interface to the video memory. The separate 4414/8515 would be used to synchronize the two buffer chips and to translate more complex user instructions into the simple instructions the buffer chips can recognize.

With the resouces availible on the third 4414/8515 we thougth about the posibility of specializing it for sprites or hard wiring a character set into it. We also thought about implementing specific graphics instructions such as line drawing or triangle drawing. And at one time (when we were feeling exspecially masochistic) we even threw around the idea of implementing a simple rendering engine. However, since we scarecly had enough resources on the 4414, the feasibility of these enhancements is questionable.

the thing that is not specific from the above diagram is the organization of memory in relation to the display. There are several configurations each with it's own advantages and disadvantages.

• Each Buffer only drives half the display: That is, there is one MCU that drives the upper half of the display at all times, and one that drives the lower half at all times. This configuration contains a fairly simple decode function, but both processors are tied up for each frame.
• One Primary, One Secondary: This is where one MCU controlls the primary frame and the other the secondary frame. This also has an easy decode function, and has the advantage that only one processor is tied up at any one time. However, this configuration requires a fairly complex synchronization protocol. Also, it's fairly hard to read from the active frame to construct the secondary frame.
• Interleaved Frames: This is where each MCU has one frame of the 2 frames required for 2-bit color. This configuration requires that the frames refreshed alternate between the two buffer processors. The decode is easy, the load is on only one processor at any given time, and the data for the relevant active and secondary frames are local on the MCU. The main problem with this configuration is the synchronization.

Our proposed instruction set was fairly ambitious. We might have been able to implement it if we could have thought of a practical way to interface with the buffer/refresher chip. our proposed instructions were:

• set_pixel_in_primary : sets one pixel value in the active frame
• set_pixel_in_secondary: sets one pixel value in the secondary frame
• stream_pixels_in_primary: stream in a number of pixel values starting at the specified address of the primary frame
• stream_pixels_in_secondary: stream in a number of pixel values starting at the specified address of the secondary frame
• clr_primary : clears primary frame
• clr_secondary: clears secondary frame
• read_primary: reads pixel value from primary frame
• read_secondary: reads a pixel value from secondary frame
• read_stream_primary: read a stream of pixel values starting at a given pixel from the primary frame
• read_stream_secondary: read a stream of pixel values starting at a given pixel from the secondary frame
• copy_Primary_2_secondary: copy the primary frame into the secondary frame
• copy+Secondary_2_primary: copy the secondary frame into the primary frame
• invert_primary: inverts all the pixels in the primary frame
• invert_secondary: inverts all the pixels in the secondary frame
• flip_frame: turns the secondary frame into the primary frame and vice versa
• reset: Resets the display