On Wednesday, November 24, 1999 6:36 AM, Simon Wood wrote:
: Unless your hardware provides BIOS for driving it like a vga/svga you will
: probably need to write (get some else to write) a display driver
: specifically for it.
No - first we can assume MDA as the lowest common denominator, not VGA.
Currently, the most-used ELKS console drivers assumes a memory-
mapped text screen at B800 or B000 (this is read from the BIOS at
startup). There is, however, a BIOS console (which needs updating)
that uses BIOS calls for character display. We could very easily
enhance this BIOS console driver even to the point that the VT100
escape sequences emitted by the upper level console driver (that I
rewrote to run a cooler vi) would work. In order to do this, we need the
following low level calls (all provided by the BIOS, but could also
be provided by a programmer for ELKS on non-BIOS systems:)
o move cursor
o put character
o put character and attribute
o scroll screen
o clear screen (if none, for loop putting spaces)
:
: For the Psion stuff the screen is just memory mapped and I wrote a simple
: driver to render text (all 8bit wide) directly onto it. This unfortunately
: requires a font to be held somewhere in the memory (in the kernel code
: segment for the psion though I'm thinking of moving this).
Ideally, the Psion specific stuff could just have the above entry
points and run under the standard console driver. In fact, it may
be that way already. Thus, the Psion console port is just an implemention
of the above interface only, not another console driver.
:
: I was thinking that it would be better to abstract a little from this and
: try and get a 'framebuffer' style interface going. This would help
: development on various platforms that don't have a vga/svga plug in card.
Certain previous discussions on nanogui suggested strongly
that the kernel not take on responsibility for any graphics operations.
The only system call that Microwindows makes, for instance, is two ioctl()'s
to tell ELKS that the VC is going into/out of graphics mode, but
Microwindows
handles the graphics mode conversions. ELKS on receiveing the ioctl's
just prohibits a VT switch, since there aren't any mechanisms to tell
Microwindows to redraw the window on switch yet, and not much memory.
: Presumably all our frame buffer would need to do is simple text (console
8*8
: ??) and dots & lines (micro-windows).
The problem with the framebuffer abstraction is that all that it really
provides is an mmap()'d linear address for the physical video memory.
Mmap() is not supported and never will be under ELKS, so really
all you'd get from this would be that ELKS would return the address
of the physical display, and all the graphics drivers would still have to
be present in MIcrowindows, just like they are now for regular Linux and
X11.
Greg
