Scrolling terminal in software-emulated text mode

[austanss]

So I wrote a terminal driver that can work in UEFI, by using an LFB and using bitmap text fonts.

Some of the terminal functions I did not update as I was clueless as how to.

In real text mode, you have a simple text buffer. Easily, all you have to do to scroll this buffer is shift this buffer to the left VGA_WIDTH times.

In my software-emulated text mode, you have a pixel LFB.
There is no text buffered anywhere, just pixels.

So how would I scroll this terminal?

[Octocontrabass]

The same way, just individual pixels instead of whole characters.

[bloodline]

So I wrote a terminal driver that can work in UEFI, by using an LFB and using bitmap text fonts.

Some of the terminal functions I did not update as I was clueless as how to.

In real text mode, you have a simple text buffer. Easily, all you have to do to scroll this buffer is shift this buffer to the left VGA_WIDTH times.

In my software-emulated text mode, you have a pixel LFB.
There is no text buffered anywhere, just pixels.

So how would I scroll this terminal?

You should still have a text buffer, and just draw to the screen the same way. I’ve looked at your code and you don’t have a text buffer.

[Octocontrabass]

A text buffer is unnecessary for scrolling (although it can make it easier, and it can be useful in other ways).

[austanss]

I'm reluctant to create a text buffer as the text buffer would need to be dynamically sized, and it would be a bit difficult to find a place to put it. It's not MMIO, like the real text mode, but actual physical RAM. If a person has a very large monitor but has minimal RAM, then an issue can arise.

[bloodline]

A text buffer is unnecessary for scrolling (although it can make it easier, and it can be useful in other ways).

If you look at the console I implemented in my OS, when you resize the window it uses a text buffer to redraw the window contents. It is very pleasing.

Scrolling pixels without a blitter is just painful

[austanss]

Thank god for C, I would hate to write this in assembly:

Code: Select all

        for (uint64_t i = 0; i < 4 * (gop.x_resolution * gop.y_resolution); i+=4)
	{
		*((uint32_t *)i) = (*(uint32_t *)(i + 4 * (gop.x_resolution * 25)));
	}

[bloodline]

I'm reluctant to create a text buffer as the text buffer would need to be dynamically sized, and it would be a bit difficult to find a place to put it. It's not MMIO, like the real text mode, but actual physical RAM. If a person has a very large monitor but has minimal RAM, then an issue can arise.

The largest your buffer just needs to be is one screen of text, no dynamic sizing, just allocate it using your normal memory allocator... it probably won’t be more than 16k at the largest resolution... that’s nothing.

-edit- I just checked my console, and the text buffer is 64kb when running on a 4K monitor! 64k is nothing.

[austanss]

I suppose I was overestimating.

However, one screen of text differs in size. The terminal is dynamically sized by this function:

Code: Select all

dimensions Terminal::get_optimal_size(dimensions screen_res) {
	dimensions term_size;

	term_size.w = (screen_res.w / 16);
	term_size.h = (screen_res.h / 25);

	return term_size;
}

[Octocontrabass]

I'm reluctant to create a text buffer as the text buffer would need to be dynamically sized, and it would be a bit difficult to find a place to put it.

You can always add one later, once you have in-kernel memory allocation working properly.

Thank god for C, I would hate to write this in assembly:

That looks like a pretty good candidate to replace with a single call to memmove(), which you should have already written since it's required by your GCC cross-compiler.

[austanss]

It is? I haven't written it...

[austanss]

I calculated the maximum possible size of a terminal using today's display technology...

7680x4320 (8K)

7680 / 16 (font width) = 480
4320 / 25 (font height + one line of padding) = ~172

One byte for ASCII code
4 bytes for RGBA value

480 * 172 = 82560

82560 * (1 + 4) = 412800

412800 / 1024 = 403.125

403KiB maximum

[bloodline]

I calculated the maximum possible size of a terminal using today's display technology...

7680x4320 (8K)

7680 / 16 (font width) = 480
4320 / 25 (font height + one line of padding) = ~172

One byte for ASCII code
4 bytes for RGBA value

480 * 172 = 82560

82560 * (1 + 4) = 412800

412800 / 1024 = 403.125

403KiB maximum

400kb is a drop in the ocean when the cheapest sbc you can buy comes with at least a gigabyte! Or is it too hard for you to implement?

[austanss]

I grossly overestimated, ok? I realize that's not that much ram.

However, this implementation I made dudn't work, however I can't figure out if the entries are being sent to memory or not because QEMU isn't dumping the memory correctly.

source: https://github.com/microNET-OS/microCOR ... operations

[Octocontrabass]

Do you ever call the code to put pixels into the frame buffer?

How are you dumping memory with QEMU?