Efficiency of scrolling in 80x25 text mode

[bubach]

How about not limiting yourself to software implementations and just changing the location in video ram where the video card starts displaying, so you never need a copy? The topic title seems to assume a VGA after all...

+1.

Geezer said:

For hardware scrolling, you instruct the VGA to use a different memory location for the framebuffer. CRTC registers 12 and 13 contain the MSB and LSB of the framebuffer offset, relative to B0000h, B8000h, or A0000h. Hardware scrolling can not continue indefinitely (eventually the framebuffer will extend beyond the end of video memory).

The framebuffer memory can also be divided into virtual consoles (VCs). 32K of video memory is enough for eight 80x25 VCs. The VCs can be spaced 4000 bytes apart (80x25x2), and the hardware scrolling code snippet below can be used to select which VC is currently displayed. (Linux VCs use a different method.)

Hardware scrolling by changing the framebuffer base address:

Code: Select all

        /* scroll up one line */
	#include <dos.h> /* outportb() */
        unsigned short crtc_adr = 0x3D4; /* 0x3B4 for monochrome */
        unsigned short offset = 80;

        /* the CRTC index is at crtc_adr + 0
        select register 12 */
        outportb(crtc_adr + 0, 12);
        /* the selected CRTC register appears at crtc_adr + 1 */
        outportb(crtc_adr + 1, offset >> 8);
        outportb(crtc_adr + 0, 13);
	outportb(crtc_adr + 1, offset & 0xFF);

[Brendan]

Hi,

How about not limiting yourself to software implementations and just changing the location in video ram where the video card starts displaying, so you never need a copy? The topic title seems to assume a VGA after all...

Not sure what makes less sense - assuming VGA compatibility will exist in a time when the rest of the world is slowly but surely shifting to UEFI and abandoning the legacy BIOS (and a potentially large amount of the ugly backward compatibility hacks that went with it); or stubbornly persisting with text mode when most people are running resolutions of 1920*1080 or higher and expect to be able to watch high definition movies on their telephone.


Cheers,

Brendan

[gerryg400]

Depending on the implementation, 4 ISA bus I/O port accesses may not be much quicker than a 4k memcpy.

[ATXcs1372]

Thanks for all the replies!

I understand VGA would make this all a lot easier and as Brendan said, I should probably go into a higher resolution mode. That being said, I will... eventually. I'm still in the process of laying out inter-process communication as well as a (U)EFI loader (although it's moving slowly) among other low-level things that I'd rather focus on than making it look pretty.

Copying from an off-screen buffer did increase the efficiency around 20% which is nice for anyone running across this thread.

[JamesM]

Thanks for all the replies!

I understand VGA would make this all a lot easier and as Brendan said, I should probably go into a higher resolution mode. That being said, I will... eventually. I'm still in the process of laying out inter-process communication as well as a (U)EFI loader (although it's moving slowly) among other low-level things that I'd rather focus on than making it look pretty.

Copying from an off-screen buffer did increase the efficiency around 20% which is nice for anyone running across this thread.

If you set the caches to write-combine you should increase that more - it'll only write a cache line at a time that way.

[Combuster]

If you set the caches to write-combine you should increase that more - it'll only write a cache line at a time that way.

Which is something you generally do not want on the VGA framebuffer - after all it has side-effects on reads and writes.

[DavidCooper]

Combuster's pointed you towards the fastest way of doing it - each char has to be written to two places in screen memory instead of one, but it never needs to be moved after that as the hardware scrolling does the rest. Even so, simply writing 4KB to the screen a few times a second is going to take up so little processor time that most people wouldn't worry about it other than making sure they don't read from screen memory and minimising the number of times the screen is redisplayed: there's little point in a redisplay more than ten times a second at the most. Either way, you're going to need an off-screen buffer if you want to be able to read back through stuff that's gone off the top of the screen.

Another thing you might want to consider (but probably don't need to) is using a graphics screen and hardware scrolling - it will take much longer to write each character but the hardware scrolling will make up for it. The advantage of this is that you can then scroll by one pixel-line at a time and make it massively easier to read the content of a rapidly scrolling screen which can be made to move relatively smoothly instead of in jumps, though it needs a lot of rapid timer interrupts to coordinate it. If reading a lot of the stuff going up the screen is going to matter to you, using this method will certainly make a difference to your quality of life, but otherwise it probably isn't going to be worth the trouble.

[sandras]

Hello, everyone.

I was thinking about asking for your thoughts about this earlier. And now, that I've seen this topic, I think I can post it here.

Instead of scrolling the text, I do something different. I overlay new text on top of the old one. Imagine: the kernel boot's up, it starts printing from the top of the screen, prints out the whole screen worth of text and reaches the bottom, and when there is no more space left for text, instead of copying everything one line higher, it starts printing from the top of the screen again, overlaying the oldest line of tect. I admit it, I implemented it this way, because at the beginning I had problems doing it the usual way. But when I saw that the readability, at least for me, is the same, as with a traditional text scrolling, I just left it this way. Now, I have not bench marked it, but I believe everyone would say, that this way, there's less job to do for the computer. I believe I can't be the first one implementing it this way. Has anyone seen it like this anywhere or implemented it this way?

Now, for me the usual way of scrolling the console seems nasty, implementation-wise. I realize, that the scrolling is done relatively rarely, but it just kind of bugs me, that I should copy, 4kb of data, to see one more line and lose another one. I plan to keep it the way it is. And I believe it will be usable even with some sort of scroll-back buffer. But of course, that is not my focus right now. Any thought's about this way of doing the text scrolling? I am still thinking what could be wrong with this kind of scrolling.

Have a nice day. : )

Edit: I forgot to mention, that when there's lot's of text scrolling fast, it looks much nicer than scrolling the usual way. I'm not sure what's that called. Flicker I think. It flickers less.

[Combuster]

That method is as old as Pype.Clicker's OS (10 years ago). My personal problem with it is that you can't see from the screen which message came last.

[sandras]

That method is as old as Pype.Clicker's OS (10 years ago). My personal problem with it is that you can't see from the screen which message came last.

I thought someone would bring that up. The thing is, that, well, again, at least for me, it seems pefectly clear which message came last. Then Again, maybe it's just me, maybe testing it on actual users would show bad results. Of course, it depends whether they'd have ever used CLI or not. On the other hand, now I realize, i have yet to unexpectedly see such a console and decide where the text ends.

[Yoda]

Correct me if I'm wrong, but afaik using VGA hw you can do pixel-perfect scrolling even in text mode.

Yes. There were old DOS text viewers that did this job.

[Solar]

On the other hand, now I realize, i have yet to unexpectedly see such a console and decide where the text ends.

You are intimately familiar with the system, what messages it is likely to print in which order etc.

Most "normal" people already have problems deciphering "normal" command line output with any degree of competence. Just yesterday I had some trouble making sense out of the post-mortem of a Python script, because I am unfamiliar with the language and environment - and I don't consider myself "normal" when it comes to working the command line.

You could make it somewhat better by printing line X, then clearing line X+1, and setting the cursor to the beginning of line X+1, so that there is always a free line under the current line.

Of course, that breaks as a method to keep track of the "current" line if your output contains empty lines.

All in all, I prefer scrolling. And seeing how it's a matter of 20% in performance, I wouldn't even bother doing anything fancy about it, because the scrolling of the output shouldn't be anything that's happening on the critical path, and even at 20% slower than optimum should be enough for most purposes.

[sandras]

You are intimately familiar with the system, what messages it is likely to print in which order etc.

Most "normal" people already have problems deciphering "normal" command line output with any degree of competence. Just yesterday I had some trouble making sense out of the post-mortem of a Python script, because I am unfamiliar with the language and environment - and I don't consider myself "normal" when it comes to working the command line.

Point taken.

You could make it somewhat better by printing line X, then clearing line X+1, and setting the cursor to the beginning of line X+1, so that there is always a free line under the current line.

Of course, that breaks as a method to keep track of the "current" line if your output contains empty lines.

I think I would do something like inverting the current lines color. So it is clearer on which line the output ended. I think that could easily be made independent of color's or hardware. Coloring the line would be done at a lower level.

[bubach]

Even if hardware scrolling isn't faster and copying 4kb of data is bothering you I don't see how you could ever proceed. I have no idea how you could even get hung up over such a trivial thing. How much memory do you think is shuffled around when scrolling webpages, or downloading torrents? 4kb is a fart in space.

Get some perspective and put some effort where it really counts instead.

[sandras]

Even if hardware scrolling isn't faster and copying 4kb of data is bothering you I don't see how you could ever proceed. I have no idea how you could even get hung up over such a trivial thing. How much memory do you think is shuffled around when scrolling webpages, or downloading torrents? 4kb is a fart in space.

Get some perspective and put some effort where it really counts instead.

Eh, don't mind me, I'm a little OCD. Actually, these OCD'isms oftenly keep me from doing things more efficiently. I mean like focusing on stuff that really matters, not optimizing code. On the other hand, developing something (you can't really call it a kernel, at least now), that does not rely on other people's code, give's an outlet for such behavior. And yes, I do know, that it's a drop in the sea, those four kilobytes, when the machine I'm typing this on has 512mb ram. I do have a machine with 20mb ram. To fill even that space with code that actually does something useful would be quite a challenge. My point - yes I know, and I still can't help but care about a few bytes here and there. : )

Edit: I did however recently start to organize the work in the way that the most crucial things come first, and started to be more concentrated on the big picture rather than details which are most likely to change in the long run anyway.