Scroll mess up the "console"

[WildN00b]

When the kernel scrolls the console become messed up.

Here the code:

Code: Select all

void Scroll(void)
{	
	if (ypos >= 25)
	{
		int y,x;
		for (y = 0; y < 24 ; y++)
		{
			for (x = 0; x < 80 ; x++)
			{
				int index = ((y * 80) + x) * 2;
				int oldIndex = (((y + 1) * 80) + x) * 2;
				
				videoram[index] = (unsigned char) videoram[oldIndex];
				videoram[index + 1] = (unsigned char) videoram[oldIndex+ 1];
			}
		}
		
		for (x = 0; x < 80; x++)
		{
			int index = ((24 * 80) + x) * 2;
			videoram[index] = (unsigned char) ' ';
			videoram[index + 1] = (unsigned char) defaultColor;
		}
		
		ypos = 25 - 1;
	}
}

Heres before it's scrolls:


Heres when/after it's scrolls:


Thanks in advance.

[Brendan]

Hi,

When the kernel scrolls the console become messed up.

And if you fixed the bug and it worked properly, it'd still be wrong. The first rule of designing video code is "never read from display memory"...


Cheers,

Brendan

[WildN00b]

I hope your videoram is defined as "volatile unsigned char*"?

still don't work

[WildN00b]

Hi,

When the kernel scrolls the console become messed up.

And if you fixed the bug and it worked properly, it'd still be wrong. The first rule of designing video code is "never read from display memory"...


Cheers,

Brendan

how should i do then?

[Neolander]

Interested in the answer too. I can't figure out what's wrong about reading the display memory right now.

[thepowersgang]

Interested in the answer too. I can't figure out what's wrong about reading the display memory right now.

And if you fixed the bug and it worked properly, it'd still be wrong. The first rule of designing video code is "never read from display memory"

Brendan's point is that, although reading from video memory will usually work, it is SLOW.
It is _far_ faster to keep a cached copy of the contents and scroll that, then write that to the video memory.

That said, I'd suggest you change your nested loops to a memcpy instead, and treat the video ram as 16-bit blocks (and make sure it's volatile)

[Brendan]

Hi,

Interested in the answer too. I can't figure out what's wrong about reading the display memory right now.

Reading from display memory is painfully slow; and in some cases the video card has different read modes and different write modes, where what you read isn't what you write.

how should i do then?

Simplest way is to have a buffer in RAM, do the scrolling on the buffer in RAM, then copy the buffer to display memory.

For the boot log, I keep a big zero terminated string in RAM. Someone can add six lines of text to the end of the boot log and then ask the video handling code to update. The video handling code determines how many lines to scroll (6 in this case), does the scrolling in the buffer once, adds the new text to the buffer, then copies the buffer to display memory once. If someone adds 200 lines to the boot log and then asks the video handling code to update, then video handling code discards the previous buffer, finds the first piece of text that would become visible and generates the new buffer from there - no scrolling at all (and definitely no need to do "scroll()" 200 times).

Of course eventually the "big zero terminated string in RAM" would be saved in the file system or something, so the user can still see what happened long after it scrolled off the top of the screen.


Cheers,

Brendan

[WildN00b]

i use memcpy and memset now and a buffer but it don't work


the code i use now is:

Code: Select all

volatile unsigned char *videoram;
unsigned char *cachedvideoram;

Code: Select all

unsigned blank, temp;
		
		blank = ' ' | (defaultColor << 8);
		temp = ypos - 25 + 1;
		
		//Moving from line 2 to line 24 to line 1 to 23
		memcpy(cachedvideoram, cachedvideoram + temp * 80, (((25 - temp) * 80) * 2));
		//Cleaning line 25
		memsetw((unsigned short *)(cachedvideoram + (25 - temp) * 80), blank, 80);
		
		//Doing the Scroll :D
		memcpy((unsigned char *)videoram, cachedvideoram, ((25 * 80) * 2));
		
		ypos = 25 - 1;

[gerryg400]

You shouldn't memcpy when src and dest overlap. Use memmove.

and in

Code: Select all

cachedvideoram, cachedvideoram + temp * 80

the 80 should be 160.

[rand]

For a general clarification, is the video ram a buffer in ram where the video card reads from, or, as I suppose it is the memory address where video card itself is mapped?

Or, again, the answer is system dependant?

thank you

[Combuster]

Technically it comprises any memory dedicated for video use. For VGA, its physical arrangement can be practically everything: four parallel 8-bit ram units in the original VGA, to any form of modern memory dedicated in modern plug-in cards, or stolen from your system memory for several onboard video solutions. The applicable use for a VGA's memory varies between framebuffers, tile+attribute pairs, and font data, some of which is restricted to a particular subset of its apparent internal memory.

All of that does not matter: The VGA "standard" specifies how to read and how to write its 256k of vram, in a way that does not care about implementation details.

[shadowH3]

Had this issue twice awhile back and it affects current linux kernels still to this day UBUNTU is plagued by this..


True about the scoll thing, but you can copy ALL 4K of VRAM at once into a buffer, then save it when you get the HD/storage up and running. More efficient if you ask me, but thats my 2c.


Attached is how i fixed this.(now Im in FPC, but you get the logic anyways)