Hi,
ManOfSteel wrote:Think for example about the tons of information about the hardware, their drivers, network and user settings being printed to screen at some point (like the start-up) as it is under unix-type OS. Everytime the text reachs the end of the 24th row, the OS scrolls the entire screen by moving 3840 bytes (80x24x2) and blanking one line (160 bytes). The same goes with every CR and LF.
In text mode, you'd only be moving ~4 KB (at most) which is trivial for anything that can handle protected mode (e.g. it won't even slow down Bochs noticeably).
It does cause problems when you're
pretending your in text mode though. For example, if you set a high resolution graphics mode during boot and you're trying to make it look like you're in text mode when you aren't. In this case it can be much much slower - mostly because of the much larger amount of video RAM you're shifting.
In this case, most video cards probably do support hardware vertical scrolling, which could make it look very smooth and improve performance a lot. Unfortunately you'll probably need to write a video driver for every video card before it'll work reliably.
However, there are some things that can be done. The first would be to use an oversized double buffer in RAM. For example, for 1024 * 768 video mode you could have a 1024 * 2048 buffer in RAM, and blit from RAM to display memory (rather than copying data from display memory to display memory). This would also mean you'd only need to scroll the buffer in RAM when you reach the end of the buffer - e.g. row 2048 rather than row 768.
Another approach is to update the display every N mS (if necessary), rather than every time it changes. It's likely that software will be sent to video in "chunks" - for example, a disk driver might send 6 lines of text at once. In this case, you'd normally scroll the screen 6 times, one after the other. This isn't too smart - it'd be better to keep track of what has been added since the screen was updated last. Then you'd work out how many lines to scroll, scroll several lines at once, then add several lines to the bottom. Depending on the text you're displaying, instead of scrolling for every screen line it could work out to an average of every 5 lines or something.
If you combined both of these, the screen scrolling could easily be 10 times faster than a "simple" system. The extra work it takes to implement and the amount of RAM you'd need to use for it might be a problem though.
There is one third technique, which is a little cheeky. Basically, no-one ever reads these screenfulls of text, and to be honest they make the OS look un-professional, so don't bother displaying it!
More accurately, there's 3 different types of users. There's the normal users, who never read it and don't want it in the first place - they'd rather see a "pretty" splash screen with the OS's logo or something.
Then there's system administrators. These people do want to see it (they're smart enough to know a "pretty" splash screen is useless), but they only want to read it when something has gone wrong, and then they'd rather only see the messages that are relevant to whatever went wrong rather than 10 screens of useless text.
Finally there's developers, who try to read this stuff but can't because it scrolls past so fast that they need a high speed camera to catch it.
It all sounds a bit silly to me...
A better idea would be to dump everything to a big long ASCIIZ string in memory and never display it (a "system log"). Then you can add extra code to handle error messages. These error messages would be sent to the system log too (just like normal stuff), but also displayed on the screen. Hopefully the error messages will be rare, and there won't be enough of them that scrolling the screen becomes a problem. After boot you'd dump the system log into a file (e.g. "boot.log"), so anyone who wants to read it can open it with their favourite text editor (or do
"cat boot.log | more").
Of course this sort of thing doesn't help when you're first writing your kernel - what you really need is
temporary "dump everything to the screen" code. Of course because it's temporary, any old hack will do...
Cheers,
Brendan
