Page 1 of 1
Scroll mess up the "console"
Posted: Sat Jun 25, 2011 6:34 am
by 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.
Re: Scroll mess up the "console"
Posted: Sat Jun 25, 2011 7:56 am
by Brendan
Hi,
WildN00b wrote: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
Re: Scroll mess up the "console"
Posted: Sat Jun 25, 2011 8:04 am
by WildN00b
berkus wrote:I hope your videoram is defined as "volatile unsigned char*"?
still don't work
Re: Scroll mess up the "console"
Posted: Sat Jun 25, 2011 8:05 am
by WildN00b
Brendan wrote:Hi,
WildN00b wrote: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?
Re: Scroll mess up the "console"
Posted: Sat Jun 25, 2011 8:25 am
by Neolander
Interested in the answer too. I can't figure out what's wrong about reading the display memory right now.
Re: Scroll mess up the "console"
Posted: Sat Jun 25, 2011 8:33 am
by thepowersgang
Neolander wrote:Interested in the answer too. I can't figure out what's wrong about reading the display memory right now.
Brendan wrote:
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)
Re: Scroll mess up the "console"
Posted: Sat Jun 25, 2011 8:38 am
by Brendan
Hi,
Neolander wrote: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.
WildN00b wrote: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
Re: Scroll mess up the "console"
Posted: Sun Jun 26, 2011 1:04 pm
by 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;
Re: Scroll mess up the "console"
Posted: Sun Jun 26, 2011 1:21 pm
by 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.
Re: Scroll mess up the "console"
Posted: Mon Jun 27, 2011 3:59 am
by 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
Re: Scroll mess up the "console"
Posted: Mon Jun 27, 2011 6:01 am
by 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.
Re: Scroll mess up the "console"
Posted: Tue Jul 05, 2011 9:53 pm
by 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)
