Mail Archives: djgpp/1999/09/29/23:20:19
I'm just learning all of this stuff now...so if I'm wrong just ignore
everything I have to say.
You can use the selector that djgpp provides (go32.h) i think it's called
_dos_ds.
To plot a pixel you can use the _farpokeb function.
I think a pixel function for this is
pixel(int x, int y, char color) {
_farpokeb(_dos_ds, 0xA0000 +y*320+x, color);
}
make sure you include sys/farptr.h
Alternatively
The way I've been accessing video memory in DJGPP -
is to write to a buffer that's same size as the screen [64000] (mode13h).
and then copy this buffer to the screen.
eg
char buffer[64000];
/*clear the buffer*/
memset(buffer,0,sizeof(buffer));
/*write some stuff to the buffer*/
buffer[ /*some x,y coords*] = /*some color*/;
/*copy buffer info to the screen (physical address = 0xA0000)*/
/*sys/movedata.h*/
dosmemput(buffer,64000,0xA0000);
As I said I'm still learning but I hope this helps.
I think
A good source of info on these things is the DJGPP Web site
http://www.delorie.com/djgpp/ (do I really need to write down the address)
G.A
Damian Yerrick wrote:
> FokkemaDBRA has a selector that points to video RAM.
> S/he wants to access video RAM as if it were an array. In
> Borland C++, this worked:
>
> > > int far *pointer;
>
> Hans-Bernhard Broeker <broeker AT acp3bf DOT knirsch DOT de> responded:
>
> > There is no such thing as a 'far pointer' in DJGPP. But there are
> specialised
> > functions (inline assembly, so they should be fast enough for just about
> > every application you can come up with), conveniently called the 'far
> pointer
> > functions'. Look up
> >
> > farpokeb()
> > farpeekb()
> > movedata()
>
> Shouldn't movedata() be called farmemmove() or farmemcpy()?
>
> > The one thing you won't get using these functions is use of
> > the 'standard' syntax, like 'video_mem[position] = content;'.
>
> Maybe someone could put true far pointer support
> (a la Borland) into DJGPP.
>
> > If you insist on that, you must effectively disable
> > memory protection using the 'near pointer method'.
>
> And risk overwriting other programs in memory (such as
> Windows, DOS, etc.). Overwriting DOS is a Bad Thing.
>
> > See the FAQ for more details about all of this.
> > --
> > Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
> > Even if all the snow were burnt, ashes would remain.
- Raw text -