Craig,

The ref: to the Atari i took as a model of "scale, complexity, and footprint".

I too would suggest an "API" approach, i might propose a more abstract one, however. The goal attempting to assure binary compatability across platforms of differing scale and i/o device type.

As an example, if the video subsystem is a stand-alone capable device (with variation of capability ranging through text LCDs; Palm type bitmapped LCDs, TV character displays, to VGA displays), then it might be that the API addresses a logical entity which is a "Display Channel".

Code executing upon the "central processor" could then;

"Open a Text Display Page" of N-chars x N-lines upon the Display Channel. The result would be either a NULL Value or a "handle" to the device for further communication. Of note, the API was a means of forwaring the request/response the "handle" was returned by the display device to the requesting process on the central processor "via" the API.

Now this primitive "client/server" exchange could imply that the requesting process's Text Display Page of 80x24 chars/lines would be serviced by a 40 char x 2 line LCD implementing a "view port" into this larger page.

Similarly, code executing upon the central processor could attempt to "Open a Graphic Page of 800x600 pixels". Again the Display device itself would return either a Null Value or a "handle" to the device. The code executing upon the central processor would never really know the graphic commands/data where being displayed upon a 128x64 LCD or 3" portable TV or 19" VGA. Again the graphic data is a logical frame for which the display device performs as a view port.

So all i/o from store to keyboard exist upon logical channels. These channels could all propagate via a high-speed serial xface or a parallel x-face or some mix of the two. In fact as code executing upon the central processor addresses an "API", and if the devices themselves also addressed a device side "API" you could implement the channels any number of ways.

regards,
p