Date: Tue, 29 Feb 2000 21:09:10 +0600 (LKT) From: Kalum Somaratna aka Grendel X-Sender: root AT darkstar DOT grendel DOT net To: djgpp AT delorie DOT com Subject: Re: Fastest bitblt? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 28 Feb 2000, Damian Yerrick wrote: > On Mon, 28 Feb 2000 18:20:28 +0600 (LKT), Kalum Somaratna aka Grendel > wrote: > > >On Mon, 28 Feb 2000, Damian Yerrick wrote: > > > >> On Sat, 26 Feb 2000 20:28:15 +0600 (LKT), Kalum Somaratna aka Grendel > >> wrote: > > > > > >> >Yes you can acess memory using the farpokeb etc... functions. > >> >Allegro is a library which uses this method. > >> > >> I guess you misunderstood me. > > > >I'm sorry but I don't get it. > > OP wrote "how do I disable protection to access low memory?" > I said "You don't [disable the protection]." > You interpreted it as "You don't [access low memory]." Not quite, I interpreted it as you dont *need* to disable protection to acesss <1mb memory. Ie-: you can use farptrs > > >> >providing that you are careful when acessing memory using the > >> >pointer as it is very easy to overwrite code or data using > >> >a stray pointer. > >> > >> All too easy in a buggy program on a single-HD laptop. > > > >Comeon, nearptr's would be used in the code that needs to acess <1mb > >memory. So if you take a game the code that depends on nearptrs being > >enabled is likely to be very small in relation to the main code > >(calculating player moves, stuff etc). IMHO so it should be reasonably > >possible to root out most of the bugs in the code that would need to acess > >< 1mb of meory (typically blitting routines, sound card, DMA acess etc).. > > Disk access, loading stuff into RAM, saving games. A write gone awry > in the DMA or blit code could trash the kernel. Well if you are so paranoid then enable nearptrs only before you execute code that depends on it like blitting routines, and disable them immediately afterwards. Although this would cause a certain amount of performance problems due to the complex DPMI calls (less so with modern day machines) you can develop and beta test and root out the bugs with the above method then enable nearptrs for the whole program in the final release version thus getting the maximum performance possible. Well consider the amount of WATCOm/DOS4GW games you have run over the years (doom, doom2, command and conquer, the list is endless...) all of them have nearptrs enabled by default (as you yourself have said), How many times have they screwed up your system or HDD? IMHO there are so many dos extended programs with nearptrs enabled out there and I still have to see any one of them doing anything bad as such. So the nearptr usage is nothing to be frowned upon or for other programmers to get a heart attack about :-) > >> > >> So use the CPU's. farptr is your friend. > > > >Again, How many people write code of the complexity that ID software > >wrote that dependens on nearptrs. So that means most people wont have need > >to vast resources to root out bugs :-) Well you didn't answer this part of my message. hmm..... > >> >> >for(i=0;i<64000;i++) > >> >> > _farpokeb(_dos_ds,0xA0000,+i,buffer[i]); > >> > > >> >char *p= (char *)(__djgpp_conventional_base+ 0xa0000); > >> >for (i=0; i<64000;i++) > >> >p=buffer[i]; > >> > >> After getting and storing the selector for video RAM > >> (pointing to 0xa0000 or whatever VBE 2 tells you): > >> #include > >> movedata(_my_ds, (unsigned)video_buffer, video_ds, 0, 64000); > > > >I think you've missed the bus here Damien :-) Your code doesn't do the > >same as the code I produced above. > > That's because code above has a bug. ???? which has the bug your code or mine? >Mine might too. > We're human (I hope). No, I happen to be a neural network designed especially for newsgroup posting and answering, running on a Athlon 1Ghz machine with 2GB of memory and 10 20Gb SCSI drives ;-) > > >The point i'm trying to make is that when you use nearptrs gcc can > >optimize your code as it sees fit. Therefore you should get better > >performance than movedata or even the farptrs. > > OK. So you better be *really* careful. Sure, You have to be really careful not only when you use nearptrs but when you write just about any code. > > >Well IMHO the idea of a protected mode DOS is that you *should* be able to > >acesss < 1mb memory as easily as possible. IMHO If you can't or it is too > >difficult to access <1mb this might prove to be a hindarance to > >programmers who use that environment. > > How is movedata() difficult? Not difficult but slow... Consider that you want to copy data in a interrupt handler (say a sound card driver) where naturally performance is critical. And say that the interrupt handler is called about 100 times a sec. Surely a inline assembly routine called 100 times using nearptrs enabled and the rep movsd insns would be faster than calling the equivalent movedata function 100 times? Just imagine the overhead of setting up the stack 100 times etc during the 100 calls to movedata in a interrupt handler :-) if you really want to use farptrs then farpoke* is a much faster option than movedata IMHO. > > >You can also ovewrite dos in real mode programs too but tell me how many > >of the thousnds of real mode programs/games (which have almost no memory > >protection) corrupted your HDD as you accuse nearptr enabled programs of. > > Because I (and several thousand other players) paid $40 each to pay > testers and debuggers. This is distortion of the facts IMHO. Anyway I doubt that most of the 40$ went to the testers and debuggers, AFAIK it's the pay for programmers, managers, developement costs, and artists/music etc that accounts mostly for the final pricing. FWIW there are companies that depend on users to do the beta testing. 7 Kingdoms was one such game in which the developers encouraged users to download beta releases and test it out and submit the bugs. > > >BTW Damien, Maybe the reason why your "virus scanner" ;-) is so > >innefective is that it doesn't take into account the line ending > >problem ;-) > > It's on Usenet; DOS line endings are the standard on Usenet. But maybe not on the mailing list ;-) > > >>And Linux doesn't need virus scanners, as system EXEs cannot > >> be overwritten by a user program. > > > >I havent come across viruses that have been written for linux but I > >suppose there might be a few. > > Any Solaris viruses? HP-UX viruses? Since every OS has it's bugs. It is _not_ impossible for someone to write a virus for UNIX/LINUX, Just much harder than dos/windoze. There maybe quite a lot of viruses out there lurking on UNIX boxes even. Who knows? > >BTW Are there any friends on the list who know of any viruses for > >UNIX/LINUX? > > Good luck. Thanks but I don't need it. Quite a number of people already have followed up with comments about the viruses that are available for UNIX/Linux. Grendel Hi, I'm a signature virus. plz set me as your signature and help me spread :)