OSDev.org

My aim for the OS I'm working on is a "scientific testbed" (low overhead, number precision, ability to act as a node for a central command server) so there will be a lot of information onscreen and I'm concerned about the efficiency of scrolling text in a CLI environment. Currently, I just copy all the memory from [(0, 1) through (80,25)] to [(0,0) through (80,24)] and continue printing at (0, 25) but that means I have to copy almost 4K every time the text needs to be scrolled (which is frequently).

Is this the "best" way to do it because the overhead is minimal compared to the power of modern processors, or should/can a paging trick be used to map 0xB80A0 (second row) to 0xB8000 and just copy actual text memory when the video memory is close to full and start over? Is there another method?

Copying of the 4K seems to be the most common and almost all I can find, but I'm not sure if that's because it's the easiest or just not worth dealing with.

It's much faster if you copy text from off-screen buffer, instead of reading from video and write back. reading from video memory is very slow.

ATXcs1372 wrote:or should/can a paging trick be used to map 0xB80A0 (second row) to 0xB8000 and just copy actual text memory

Paging on x86 require 4KiB alignment.

Copying of the 4K seems to be the most common

Usually you only refresh screen once per scroll or page up/down.
On the other hand, you may also delay screen update upon new line is print on screen, by buffering the output and do some frame rate control, so it do not slow down your calculation-intensive task.


It's better to improve the navigation (like smarter scroll, seek-to-page, adaptive scroll distance, etc), so you don't need to refresh screen at very high frequency.

bluemoon wrote:It's much faster if you copy text from off-screen buffer, instead of reading from video and write back. reading from video memory is very slow.

This is how the stdin buffer for applications currently works, but are you suggesting I have a "universal" or even kernel-only I/O buffer to copy "a full screen" from? If video memory is much slower to access, I can see how reading+writing would be worse than just writing and this would make sense.

bluemoon wrote:On the other hand, you may also delay screen update upon new line is print on screen, by buffering the output and do some frame rate control, so it do not slow down your calculation-intensive task.

It's better to improve the navigation (like smarter scroll, seek-to-page, adaptive scroll distance, etc), so you don't need to refresh screen at very high frequency.

Where is a good place to look into this? I have only read intensively about VGA as text mode seem(ed) fairly simple. The wiki doesn't have much related to this in the text-mode sections and while it has only been a few minutes, I can only find resources related to VGA on the topics of refresh rate and smarter scrolling. Don't get me wrong, I'm going to keep researching and I'm thankful for your help, it's just that every once in a while there's that hidden gem.

EDIT: Does text mode use standard VGA ports? That would make this easier...

An off-screen ring buffer with a pointer to the current top of screen should do the trick.

gerryg400 wrote:An off-screen ring buffer with a pointer to the current top of screen should do the trick.

Or an offscreen 80xN buffer to allow scrolling back through screen buffer history

gerryg400 wrote:An off-screen ring buffer with a pointer to the current top of screen should do the trick.

But unless I can redirect video memory to this location I don't see how this is any better, other than the fact the system can read from RAM faster than video memory, because it still has to copy just as much memory...

ATXcs1372 wrote:

gerryg400 wrote:An off-screen ring buffer with a pointer to the current top of screen should do the trick.

But unless I can redirect video memory to this location I don't see how this is any better, other than the fact the system can read from RAM faster than video memory, because it still has to copy just as much memory...

True but to be honest copying 4k isn't majorly expensive, especially if you use a 64 bit copy method with rep stosq...

The frame rate control I was referring is about general programming technique, which you usually found on game programming.
It can be as easy as: Then, reset the frame_count to zero every second, and flush any un-committed screen (hint: use the timer)...

The idea is that, even you can redraw the screen 1000 times a seconds upon 1000 changes, your human eye simply cannot catch it.

PS. Before proceed to frame rate control, you should try the simple off-screen buffer and benchmark again, video write is quick compare to read, so it may just solve your problem.

brain wrote:

ATXcs1372 wrote:

gerryg400 wrote:An off-screen ring buffer with a pointer to the current top of screen should do the trick.

But unless I can redirect video memory to this location I don't see how this is any better, other than the fact the system can read from RAM faster than video memory, because it still has to copy just as much memory...

True but to be honest copying 4k isn't majorly expensive, especially if you use a 64 bit copy method with rep stosq...

No, not true. His original system, for every line printed required a 4k memmove and a 1 line memcpy. The 4k memmove may be especially slow on some hardware because it is video mem. (4k + 1 line copied)

An offscreen linear buffer for every line printed requires a 4k memmove and a 1 line memcpy. Finally a 4k memcpy to video mem will be required. (8k + 1 line copied)

An offscreen ring buffer for every line printed requires a 1 line memcpy and pointer adjustment. Finally a 4k memcpy (in 2 parts) to video mem will be required. (4k + 1 line copied).

The ring buffer scheme requires the same amount of copying as the original scheme but since video memory will not be read it will be fastest.

@bluemoon: Your code looks a bit screwed... If write_to_screen is called, say, every 1 ms, it will in turn call flush_screen every 1 ms. Let's assume that frame_count = 0 at the beginning. Then, for the first 30 ms, the screen will be updated at each call of flush_screen, and frame_count will be increased. After 30 ms, the screen will not be updated anymore until the next 1000 ms timer tick, when frame_count is reset to 0. Then again the screen will be updated 30 times each 1 ms, and again be frozen for the remaining 970 ms. That's probably not intended...

In that case, just tune the parameters, like limiting 3 updates every 0.1 seconds, or 1 update every 1/30 seconds
I admit the code looks bad but it's for demonstrating the idea.

brain wrote:

ATXcs1372 wrote:

gerryg400 wrote:An off-screen ring buffer with a pointer to the current top of screen should do the trick.

But unless I can redirect video memory to this location I don't see how this is any better, other than the fact the system can read from RAM faster than video memory, because it still has to copy just as much memory...

True but to be honest copying 4k isn't majorly expensive, especially if you use a 64 bit copy method with rep stosq...

Copying from main memory to main memory is quite quick because all the CPU will do is fetch the source by reading an entire cache line, then write a new cache line corresponding to the destination. But when you copy from main memory to video memory, caching obviously isn't be used for the writes, which slows things way down, especially for video memory.


Every 1/60th of a second or so (the refresh rate of the vast majority of modern LCD's) simply write the last 4000 bytes (or less) of an offscreen buffer into video memory. When the buffer is close to getting full, copy the last 4000 bytes to the beginning, and set the buffers pointer to BASE_OF_BUFFER + 4000. Two paging level optimization you could make would be to:

1. Put the pointer to the buffer in its own 4kb page with nothing else in it. Every time you update the screen, clear that pages dirty flag, checking the dirty flag each 'screen update tick', and only copying the buffer if its dirty (since the pointer to the buffer will change anytime the buffer is written).
2. Set a guard page at the end of the buffer. Set your page fault handler to reset your buffer (copy the end 4000 bytes to top, etc) any time a page fault happens in that page. Then you will have a "never ending buffer" for your off screen buffer (which simplifies a lot of things), and you will only reset the buffer when absolutely necessary.

bluemoon wrote:The frame rate control I was referring is about general programming technique, which you usually found on game programming.
It can be as easy as:

Code: Select all

CODE

Then, reset the frame_count to zero every second, and flush any un-committed screen (hint: use the timer)...

I understood the method, I was just unaware there was capabilities for that outside of a VGA mode. I'll keep looking.

bluemoon wrote:In that case, just tune the parameters, like limiting 3 updates every 0.1 seconds, or 1 update every 1/30 seconds

Indeed, that sounds reasonable. It still has some problems, for example, if there are two screen writes within 1/30 seconds, only the first will be flushed to the screen, while the second one will be delayed until the next screen write (which may be seconds later). However, ...

I admit the code looks bad but it's for demonstrating the idea.

...that's a fair point.

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