From: Geza Herman Newsgroups: comp.os.msdos.djgpp Subject: Re: Getting the fastest running Date: Mon, 5 Jan 1998 13:48:57 +0100 Organization: Technical University of Budapest Lines: 63 Message-ID: References: <1998918057C AT fs2 DOT mt DOT umist DOT ac DOT uk> NNTP-Posting-Host: kempelen.inf.bme.hu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <1998918057C@fs2.mt.umist.ac.uk> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Mon, 5 Jan 1998, Anthony.Appleyard wrote: > (0) Due to the nature of the work I must set up a screen display in an array > and then bulk copy it to screen (in a 256-color mode: VESA 0x101, 0x103, > 0x105, 0x107), by dosmemput()'ing it 0x10000 bytes at a time to the graphics > screen address 0xa0000 etseq. Is this the fastest way to copy bulk matter to > the graphics screen in djgpp? If not, what is? Why must you copying? You can write directly to vid.mem. Dosmemput is very fast, but you can make the copying a LITTLE bit faster( examine the assembly code of dosmemput ) > (1) In djgpp v2 how fast are farpokeb() / farpeekb() compared to directly > writing to / accessing ordinary char variables? A little bit slower because of the selector registers. You can use _farsetsel, and _farnspokeb( if I remember the names right ) > (2) When a PC program runs in protected mode with 32-byte addresses, when it > accesses a variable (if it is not swopped out onto disk at the time), does it > genuinely access extended memory directly?, or does it have hidden time > overheads due to DPMI / EMS / XMS / etc interrupt routines swopping extended > memory areas in and out of conventional memory so the program can access them? DPMI and EMS are two different worlds. DPMI sees the memory as a whole, it doesn't see XMS and EMS( for example: if your machine has 16MB of mem, and you use 5MB EMS, DPMI will see only 10MB ). There is no swapping. > (3) A djgpp v2 program has an array of e.g. 1 to 4 megabytes. If I access or > alter elements in it here and there at random rather than in sequence, am I > thereby wasting much time making DPMI etc repeatedly swop memory segments > about between conventional and extended memory? My PC has 16 megabytes of RAM. Look (2) > (4) If a program runs in real mode and accesses extended memory by directly > calling the interrupt `AX=0x8700, int0x15' to swop memory segments between > conventional memory and extended memory, could that program be safely called > from Windows (3.1 or 3.1.1 or 95 or NT)? Why do you need it now? > (5) If a program runs in real mode and accesses the graphics screen pixel > values at address 0xa0000 etseq, is that access genuinely direct? Or is it via > hidden interrupt routines which access the screen's RAM by reading and writing > ports? Ditto re accessing the text screen? What is the speed of accessing > screen RAM addresses compared to accessing ordinary RAM addresses? No hidden interrupt routines. Generally, video memory is slower than ordinary memory. Your video card handles 0xa0000 memory. > (6) What C or C++ compilers are there which compile into real mode? How to > get them? I have `Small C', which compiles into real mode but as far as I can > find only onto a .COM file, not an .EXE file. I have Borland C++ version 45 > for Windows: it can compile for DOS or for Windows, but apparently always into > protected mode. Real mode isn't the future. You'd better not use it. However, you can you the older versions of Borland/Turbo C( version 3.0 ) To achieve the fastest running, (in DJGPP) use -O3. Regards, Geza