Hello,
> > Hmm, have you considered rendering the screen from a text copy of
the
> > screen instead of scrolling? I'm not familiar enough with the G364
but
> > 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
depending
> > on how long the lines are..
> >
> > o And many more reasons..
> >
> > It might be easier to get rerendering working than some kind of
hardware
> > scrolling. Also hardware scroll looses if you want to implement
scroll
> > 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
screen
> > 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.
/pab
|