From: Fokkema DOT DBRA AT delorie DOT com, 1043730 Newsgroups: comp.os.msdos.djgpp Subject: Re: problem with far pointers Date: Thu, 30 Sep 1999 06:43:42 GMT Organization: Fac. Wiskunde & Informatica, VU, Amsterdam Lines: 106 Message-ID: <7sv0qu$4pm@cs.vu.nl> References: <7ssgdl$pg AT cs DOT vu DOT nl> <7sssfq$rds AT acp3bf DOT knirsch DOT de> <7su41v$a4q$1 AT solomon DOT cs DOT rose-hulman DOT edu> <37F2B526 DOT C8043DF5 AT hutch DOT com DOT au> NNTP-Posting-Host: galjas.cs.vu.nl X-Newsreader: TIN [version 1.2 PL2] X-Poster-Key: sha1:fNyPun+0NDRmKJFIUGN5OlleZIM= Cancel-Lock: sha1:ImkmuZP03CRFU3A+UCvjL3tSv4g= To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi there! Because I'm writing my own OS (like the rest of the world) I don't want to use functions from the c libraries, if possible. Certainly not functions that check read and write privileges for me, as I believe the djgpp 'far pointer' functions do. But by looking through the documentation, as I was suggested, I managed to find out how inline assembly and multiline macros are written in djgpp. So I wrote some macros, which do the job for me in plain assembly. Currently, I need 6 macros for b,w,l read and b,w,l write. Pointers and constants are both accepted as offset (using the alternative constraints) and constants and variables are both accepted as values. Can someone do it with less than 6 macros? Thank you all so far, David Fokkema GAvin Alexander (gavina AT hutch DOT com DOT au) wrote: : 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 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.