Efficiency of scrolling in 80x25 text mode

[bubach]

Haha well I know how it is and wasn't trying to sound harsh. But if it's more the principle of the thing and not performance as such, hardware scrolling would work for "elegance" - right?

Anyway, my point is that not using scrolling at all doesn't really solve anything and you have to try to balance the code elegance and efficaciousness with the user experience and interface.

[sandras]

Do not worry, no offence was taken at any point in time.

Well, as for the elegance thing. I don't really get what is elegant in doing the scrolling in hardware. Now that I think of it, I could not really define elegance. But I do actually find doing stuff in software neater. Don't get me wrong, I'm not just sitting and staring at my vga text mode "driver", but for example, I do implement my cursor in software too. I was curious to benchmark it against a hardware cursor, but I got sidetracked. I wanted to benchmark the thing because I read that interacting with IO ports, through which one controls the vga text mode hardware cursor, is slow. And wanted to see how that compares to interacting with video memory. It's the first time I write code that can access the hardware directly, so I'm kinda curious about the hardware.

[DavidCooper]

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 text.

I missed that one - Sandras has come up with a more efficient method by cutting out the scrolling altogether, and it can be made more efficient still by changing the colour of the display every time it jumps back to the top - that saves the need to go back to change the colour of the previous line every time a new line is written.

[xenos]

There's only one problem, you cannot change attributes on a line with a memset. You have to go through every other byte in the memory and update it. Of course, you could keep previous line in the buffer, then update it and the next line with proper text and attributes, then memcpy the whole 2-line blob onto the screen, but that becomes hairy once you have to wrap around at the screen edge.

If I get this right, this is just what DavidCooper is trying to avoid. There is no need to change the attribute bytes of the previously written text. Only the attribute of the currently written text is changed whenever screen writing starts from the top. You write a page in white, and when the page is filled, you start writing from the top again, but now you do it in red.

[bubach]

I've always used the hardware cursor and never even had a thought that it might be "slow", I mean... a 286 doesn't have problems with the cursor or even software/hardware scrolling, so why care now?

But I'm curious about doing the cursor in software, mainly for the future where I might use a higher resolution VESA mode for the console. What character do you use, it's not the same as underscore, or is it? Also, the blinking you can't do that too or wait.. is that a bit in the color byte for blinking? Obviously won't work for VESA but... Alright, enough with the off topic.

[gerryg400]

I haven't done any actual tests lately but doesn't updating the cursor in hardware take 4 ISA IO port writes ?

That's 4us or more than 10000 cycles. Seems slow to me.

[sandras]

For the cursor I just inverted the color. If Normal text is 0x07, then cursor is 0x70. I did not do the blinking as I realized, I was spending my time inefficiently. But I guess one would just use one of the timers to show and hide the cursor periodically.

Edit:

I haven't done any actual tests lately but doesn't updating the cursor in hardware take 4 ISA IO port writes ?

That's 4us or more than 10000 cycles. Seems slow to me.

Yes you have to access IO ports four times. Or at least that's what I did.

[Brendan]

Hi,

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.

If you're planning to support high resolution graphics modes in the future (where you might be shifting "1920*1600*4 bytes = 11.7 MiB" each time you scroll), then you should design your code with this in mind.

If you were using a high resolution graphics mode, then you'd probably want (at least) 2 different types of buffers. The first buffer is just a big string in memory. When you "printf()" you append the new text to the big string in memory, update a pointer to the end of the string, update a pointer to the first character that would be displayed, and update a "number of lines to scroll" variable.

The second buffer contains pixels and is what you blit to display memory. When you update the screen, you check the "number of lines to scroll" variable. If it's more than the number of lines that fit on the screen then you clear your pixel buffer and draw everything from "pointer to the first character that would be displayed" to "pointer to the end of the string"; then do "last pointer to end of string = pointer to end of string". Otherwise, you scroll the pixel buffer (if necessary), and draw characters from "last pointer to end of string" to ""pointer to end of string"; then do "last pointer to end of string = pointer to end of string". In either case, once you're finished you blit the pixel buffer to display memory.

If someone adds 1234 lines of text to the big string, you don't scroll (by 1 line) 1234 times, and if the screen only holds 50 lines of text then you don't even draw 1184 of those lines (you only draw the last 50 lines that fit). Also notice that if you change the video mode (or window size) you can redisplay the big string to suit the new video mode (including adjusting "line wrap" to suit the new "number of characters per line"). You can even implement scroll back without too much trouble.

Now; for text mode you can do exactly the same thing as above, except that the pixel buffer is a "character and attribute" buffer instead.

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.

If you're planning to support UEFI in future, then you should design your code with this in mind. Lots of hardware (video cards, disk controllers, USB controllers, etc) have legacy modes for the purpose of "IBM PC compatibility". For UEFI, the firmware has no need to enable any of these legacy modes. For example, if the system has 2 video cards, then both of them can be configured by the firmware like any other normal PCI device (e.g. using the device's BARs in PCI configuration space), the PCI host controller and PCI bridges could be configured without the "legacy IO port forwarding" and "legacy VGA window at 0xA0000 forwarding" stuff, the memory map can be configured in a nice clean way (e.g. big chunk of contiguous RAM), etc. Eventually, all of this legacy crap can be removed from the hardware itself, so that hardware becomes cheaper to design. That is probably the single biggest advantage of UEFI - it's like a strong wind blowing dust and spider webs out of the 80x86 architecture.

For video, UEFI functions let you setup a video mode and give you a frame buffer to use. If your code uses "address of frame buffer", "frame buffer format" and "bytes between lines" fields as an abstraction, then it's relatively easy for the same code to support ancient VGA (PC BIOS), very old VBE (PC BIOS), slightly old UGA (EFI) and newer GOP (UEFI) without any changes in the graphics code at all (just different boot code to setup a video mode to suit each case).


Cheers,

Brendan

[Brendan]

Hi,

I haven't done any actual tests lately but doesn't updating the cursor in hardware take 4 ISA IO port writes ?

That's 4us or more than 10000 cycles. Seems slow to me.

That depends. On an 8 MHz 80286, 4 us is only 32 cycles.

The biggest mistake people make for cursors is forgetting to turn them off when software isn't expecting user input.


Cheers,

Brendan

[DavidCooper]

Another thought on the non-scrolling method - if you spot something on the screen which disappears before you have time to read it properly and you want to go back to look for it, knowing the location it appeared at on the screen will make it much easier to find it again as you work your way back through previous pages, and if each page is a different colour rotating through a wider range of colours than just two, that'll help you track down the right page much more easily too.

[sandras]

In Rio, Plan 9's windowing system / window manager, the text does not scroll when there's more output, than can fit in to the console, you have to scroll it yourself, using, I think, Arrow keys. This way, when there's lots of text coming at you, you stay at the start of the output. I believe that's where you want to stay most of the time, when this is the case. In my eyes, another, a bit rarer case, is that you want to be at the end of the output, and the rarest, that you will want to find something in the middle. I found that this, the Rio way, is very convenient. Have in mind, that when there's much output in the console, and you have to scroll back up, you can't clearly see where the output began. That's why I usually press Enter quite a few times, before I execute a command that I expect will output a lot of data, when using the usual kind of console. When you want to find something that's in the middle of the big output you just got, it almost does not matter whether you're automatically scrolling, or having the user do it, when he's ready. Well, if anything, having the user do it makes it more pleasant for him / her, as there's no annoying Enter bashing needed in case of long output. And you do know, instantaneously, where's the start of the output, as you you're right there and the same goes for then end of the output - you either, as in Rio, get a big white space, or you could just stop scrolling if there's no more text, even if the user requests scrolling.

The summary is this:

* When there's lots of output, and you want to get to the other end of it, in Rio, you just have to manually scroll down and you instantly see where the other end is, when it comes, while in a usual kind of console, you have to scroll up, and you can't very clearly see where there's the other end, unless you did predict there will be a lot of output and did extra work by pressing Enter several times to leave a notice to yourself, that this is where the output began.

* When you want to find data in the middle of the output, Rio, again makes it more convenient, making it clear where both ends are.

* You usually start reading text from the beginning.

I think now, that there's the bad case for Rio, when you scrolled down manually and want to get back to the beginning, and you do not clearly see where's the beginning of the output just like in the usual kind of console. But this is the downfall of Rio, there are no points for the usual kind of console, for that.

I think, that if your doing it the Rio way, and still are worried about quickly getting to the bottom of the output, you could just provide a shortcut, a button in the window or something like that, that would get you directly there. You could do the the same, or rather the opposite, depends on how you look at it, for the usual kind of console, but the argument, again, is that you are most likely to need to get to the start of the output anyway, so you might as well stay there.

[clavin123]

i implement what xenos said of writing with red
now is there anyway on bochs to benchmark and compare with the older style of scroll?

[sandras]

now is there anyway on bochs to benchmark and compare with the older style of scroll?

When I was bench marking memset(), I simply executed each memset() a certain amount of times and timed them using PIT on real hardware, because (I don't know if that's the same for Bochs) QEMU showed quite varying times compared to real hardware. If times on real hardware were different between runs, they did at most differ by one or two ticks. The divisor I sent to the PIT was something like 1600, I guess.