vid memory linked list

[slacker]

im trying to write a atext mode driver using linked lists and i was wondering why the following doest work:

STRUCT1 *S;

assuming i have a pointer to video in that struct, why cant i do this?

Code: Select all

S->vidmem[0]='J';

it compiles fine but it doesnt write the byte to memory

[Tux]

Could it be, black on black? (e.g. attribute?)

[slacker]

nope

[Tim]

It depends what value S has.

[BI Lazy]

or where that pointer points to? have you allocated memory for it? Do you have a place in memory at hands to point at with it?

[slacker]

i have to allocate memory for S? im assuming this is from not using the "new" keyword? i dont think i need to use the keyword "new"....

[Tim]

It's got to point somewhere before you can use it. After you declare a pointer, it is pointing into random memory.

You can assign it a value using either:

Code: Select all

STRUCT1 s;
STRUCT1 *p;
// p points to variable s, on the stack
p = &s;

or:

Code: Select all

STRUCT1 *p;
// p points to an instance of STRUCT1 on the heap
p = new STRUCT1;

[Schol-R-LEA]

Perhaps we should begin with some more basic queries:

What is the STRUCT1 data structure? What is it used for? You describe it as a linked list for a text driver; what is it meant to hold the state for - lines of text? Virtual consoles? The text video pages themselves (which makes little sense to me, but I suppose you might have some reason for it)? Why is a linked list an appropriate structure to use, rather than an array, a stack, a bitmap, etc.?

How does the STRUCT1 structure map to the text video pages? What text mode is this supposed to be used with?

Is this being coded in C or in C++? (If you need to use dynamic memory allocation, then this could be a relevant factor.)

Why did you name it STRUCT1 instead of something more descriptive?

What is the videomem[] array represent - is it supposed to be the text video page itself, and if so, why not use a pointer instead? Are you correctly accounting for the attribute bytes (a character in text mode is represented by a word: the low-order byte holds character's ASCII value while the high-order byte contains the text attribute flags)? If you are going to treat it like an array, wouldn't it make more sense to use a two-dimensional index, so that it can be handled on a per-line basis rather than as the whole screen?

[slacker]

i was thinking about using a linked list to keep track of the data at each location like the character and the attribute byte. also the struct would hold the index(position on the screen), and a pointer to video memory.

im coding in c++

i now am deciding to drop this idea of using a linked list though because its proboly easier to use an array to hold this type of data

videomem is the pointer to video memory

...the entire thing was a stupid idea that i had

[Solar]

i was thinking about using a linked list to keep track of the data at each location like the character and the attribute byte. also the struct would hold the index(position on the screen), and a pointer to video memory.

Erm... excuse me, but why do you want to store information in data structures that's already available in the video RAM?

i now am deciding to drop this idea of using a linked list though because its proboly easier to use an array to hold this type of data

Again, why would you want to "hold" that data in any other place but the video RAM itself? I can hardly think of any use for that.

[Therx]

why would you want to "hold" that data in any other place but the video RAM itself?

When I wanted a UI with lots of VCs (in my first OS) there wasn't enough space to hold them all in the Video Memory so I kept all the inactive consoles in standard mem.

[slacker]

...the entire thing was a stupid idea that i had

it sure was

[Curufir]

Erm... excuse me, but why do you want to store information in data structures that's already available in the video RAM?

Hmm. Ok, let's say, as a for instance, I want to antialias the entire screen contents at a half decent rate. Now if we assume a VGA/VESA mode that doesn't allow for pages then manipulating screen memory directly is out because of tearing. It woudn't be optimal even with pages because accessing video memory is kinda slow at the best of times.

Now if I hold a local copy of video memory in normal ram I get to do doublebuffering even in VGA modes, and I can dump the screen in one almighty lump into video ram once rendering is complete (A large sequential write will be a lot faster than lots of non-sequential writes) in sync with the monitor refresh rate. Result is a loss of some memory and maybe some speed but should be a smoother look.

I can see reasons for it, but I'm guessing once you start driving the graphics board directly (Ie not VGA/VESA) it becomes fairly irrelevant.

[Tim]

Double buffering is also useful if:

-- You often want to read from video memory. Video memory is really slow to read, so for scrolling etc. it's preferable to keep a copy of video memory in system memory, do the copy in system memory, then copy the whole lot to the screen. (Even better than that is an accelerated video card which does video-video copies itself.)

-- You're writing a DOS box program. DOS programs often want to write directly to video memory. If you've got several DOS boxes open in a GUI they can't all do this. One solution is to give each program a virtual video buffer which they can write to, then copy each buffer to the screen periodically. You don't need to copy a buffer to the screen more often than the refresh period of the monitor; any faster and the user won't notice the difference.