>   Ok the eventual plan is to get the SHARK and RISCPC running on wscons
> instead of there own custom kernels....
> 
> For SHARK a bitmap wscons should be fairly straight forward to implement
> thought from past experience with the rcons code I am concerned about
> drawing and scrolling speed.

This has been discussed a bunch on other lists recently; I've also
looked at rcons from the point of view of performance tuning... in
short, given how framebuffers are typically wired into a system, it's
got a lot of room for purely MI performance tuning.

there are two pieces to it:

 1) rcons only writes a glyph at a time to the display.  This likely
involves one or two read-modify-write operations for each row of
pixels in the character.  These tend to be very slow for many bus
architectures, which may be fast in terms of moving bulk data but
require time to turn around between reading and writing..

(It's also extremely over-general for the job of emulating a
vt100-class display -- it allows proportionally spaced fonts,
right-to-left and top-to-bottom font painting, etc., etc.,).

Fixing it to blit a scan line at a time, so that there's at most one
R-M-W cycle at each end of a string being painted, with the
intervening characters done as just writes, should speed things up
significantly.

 2) the current wsemul-to-display glue only passes a glyph at a time
down to the underlying layer, which makes it harder (but not
impossible) to avoid problem #1

Anyhow.. in terms of getting there.. once 1.4 settles down, if someone
else builds a (admittedly painfully slow) bitmap wscons for the shark,
I'll definitely be in a position to do the MI performance tuning.

					- Bill