> > Hmm, have you considered rendering the screen from a text copy of
> > screen instead of scrolling? I'm not familiar enough with the G364
> > here are a couple of reasons it may be faster:
> > o The read access time to the v-ram can be long enough to
> > ruin the performance completely. Optimizing copy loops
> > in the driver is just waste of time.
> > o Writes to the board might be pipelined so it can sustain
> > a greater bandwith than reads.
> > o Cached reads clobber the cache even if it's increases the
> > read speed some.
> > o Uncached reads is a pain if you have to do a lot.....
> > o By rendering chars scanlinewise writes to the vram can be
> > minimized. And of course optimizing scanline length
> > on how long the lines are..
> > o And many more reasons..
> > It might be easier to get rerendering working than some kind of
> > scrolling. Also hardware scroll looses if you want to implement
> > regions as in VT emulation.
> > Also, you don't have to consider vram configurations so much.
> > You could measure the character rendering speed by filling the
> > with N characters without scrolling N times and time it.
> > Just a thought....
> > Per
Per's considerations are surely right. Actually, to minimize vram access
the 1BPP code writes always (ok, whenever possible) a 32bit word at time
into the buffer, ie a scanline of four consecutive characters. This
won't make region scrolling easier or faster, but there are perfectly
usable terminals (ANSI) implemented without it.