RE: Herc in Microwin
: 1. I have finished the optimised HERC_drawhline and . it works, its a : mirical! Great! : : 2. On a 386 16Mhz it takes 60 seconds to load on the original microwin on : the same pc with the optimized hercwin it takes 20 seconds. Both these times : include the reading the disk at the beginning. *much better* : : 3. Do I need a #ifndef statment do control the compliation of the optimized : and non optimized version? No - let's use your code : : 4. Once this is done how do I put the code in the microwin source? Greg? Send it to me and I'll include it in the distribution. Thanks. Greg
RE: Herc in Microwin
hi As discussed last week on this list, vert_line is mislabeled, it should be horz_line (exactly how *did* that happen, Bjorn?? ;-) greg, the list you are talking about is [EMAIL PROTECTED] right? : I have not started the vertline func yet, but as I say the hline is nearly : ready. No need for an optimized vertline, there's nothing that can be done to the existing code to speed it up... Thank god, because I could not think of anything!! No - scr_herc.c was written by me based on Jacob's code. (thanks Jacob) I assume you're starting with scr_herc.c, the working hercules screen driver. Yep thats the file I am adding to. tom __ Get Your Private, Free Email at http://www.hotmail.com
RE: Herc in Microwin
: Bjorn Eriksson's code : void vert_line(US x1, US x2, US y, const BYTE color) : : This confuses me, why does a vert_line func have 2 "x" vals??? Or is a : general typo, wouldnt that be a horizontal line, like you say?? : As discussed last week on this list, vert_line is mislabeled, it should be horz_line (exactly how *did* that happen, Bjorn?? ;-) : I have not started the vertline func yet, but as I say the hline is nearly : ready. No need for an optimized vertline, there's nothing that can be done to the existing code to speed it up... : : This may seem like a silly question, please dont get mad, but, what do you : mean "the code you're running now is based on Jacob's code", baring in mind : I have never done a programming task in a group. Is it that I use the : #defines and stuff he has? : No - scr_herc.c was written by me based on Jacob's code. (thanks Jacob) I assume you're starting with scr_herc.c, the working hercules screen driver. Greg
RE: Herc in Microwin
hi Greg:- Good luck. Remember, the code you're running now is based on Jacob's code, and we want to add the horizontal byte-filling code that Bjorn sent us. Bjorn Eriksson's code void vert_line(US x1, US x2, US y, const BYTE color) This confuses me, why does a vert_line func have 2 "x" vals??? Or is a general typo, wouldnt that be a horizontal line, like you say?? I have not started the vertline func yet, but as I say the hline is nearly ready. This may seem like a silly question, please dont get mad, but, what do you mean "the code you're running now is based on Jacob's code", baring in mind I have never done a programming task in a group. Is it that I use the #defines and stuff he has? Greg tom __ Get Your Private, Free Email at http://www.hotmail.com
Re: Herc in Microwin
Hi I have some examples in asm in a book. Whats the book, sounds great, ISBN??? I will try to remember mailing you what info I have when I get home later tonight. (GMT + 1) GREAT!!! Get Your Private, Free Email at http://www.hotmail.com (Not so private... :-) yes...hehe... I am still...(deap breath)...configuring sendmail/fetchmail/procmail/mailreader for my pop account! I have only been using linux for a year, and 6 months of that I did not use it!! Kind regards, Jakob Eriksson Thanks Thomas __ Get Your Private, Free Email at http://www.hotmail.com
RE: Herc in Microwin
: 2. How do I write to bytes to memory correctly. The origanal drawpixel uses : a pixel value c as well as the x and y cords. And therefor the hline uses : this c as well. : : It does:- : if(c) : ORBYTE_FP(dst, mask); : else ANDBYTE_FP(dst, ~mask); : : What is the pixelvaue "c" for? Who gave greg that code? Greg? In the MicroWindows/Nano engine, there are color values (COLORVAL) and pixel values (PIXELVAL). COLORVALs are now always 32 bits, and hold the RGB color we're looking to see. After translation by the palette manager section of devdraw.c, the color value is converted into a device-dependent PIXELVAL that is essentially an index into the video card's palette, *or* the hardware RGB value, if the card is truecolor. Translated, for you the pixelval is either 0 or 1 (black or white), since you're running a monochrome screen. So, if c == 1, then you OR a bit into screen ram, else you AND out (set to 0) a bit. Good luck. Remember, the code you're running now is based on Jacob's code, and we want to add the horizontal byte-filling code that Bjorn sent us. Greg :
RE: Herc in Microwin
: 2. To verify one important thing, cord 0,0 = top left and 720,348 = bottem : right. Is the CORRECRT??? : yep : 5. This is my understanding of the prob, correct me if I have go compleatly : wrong, or have gotten the wrong idea. So at the moment a draw pixel function : is called many times each time altering memory "bit" by "bit". I have to : write a func that writes a byte at a time to memory, (8 bits) and in case of : the herc card 8 pixels. : Just use Bjorn's submission "vert_line" to this list. rename it properly though ;-) gh
RE: Herc in Microwin
On Tuesday, July 20, 1999 2:39 AM, Thomas Stewart [SMTP:[EMAIL PROTECTED]] wrote: : I fired up my old beast last night, a v20 640k with a herc card, I ran my : compiled copy of microwin with herc support, and it worked! : : WELL done to greg and whoever helped write that driver! : Unbelievable! That's the *second* time I've written a Microwindows/Nano-X screen driver and it's worked without having any hardware to run it on!!! Also big thanks to Jacob for sending me his sample Hercules code, which was very easy to understand. : On the down side it did take a little long for it to load, try 10 min! : So if it is to be used the code has to be somewhat speeded up. I did not try : to move any windows because I did not have a mouse pluged in and it would : have taken too long. Uh-oh. Scratch the above comment. You mean that it took 10 minutes to *draw* the screen! (laughing in background, peers looking at me very strangely...) Well, we definitely need that HERC_drawhline to be implemented, because now it calls HERC_drawpixel for *every* pixel on the screen, all 252,000 of them. I can take a hack at rewriting that, but It'd be nice if someone with a card did it. The file is mwin/src/drivers/scr_herc.c. : : I am not realy an expert, but a v20 is faster that an 8086/8088 so it might : be worse on those. All that I can think of doing is 1.adding 8087 support : 2.speeding up code 3. anyone else have ideas?? The problem is definitely in HERC_drawhline. Rewrite it to draw the horizontal line directly, rather than call HERC_drawpixel. Greg
RE: Herc in Microwin
On Tue, 20 Jul 1999, Greg Haerr wrote: : On the down side it did take a little long for it to load, try 10 min! : So if it is to be used the code has to be somewhat speeded up. I did not try : to move any windows because I did not have a mouse pluged in and it would : have taken too long. Uh-oh. Scratch the above comment. You mean that it took 10 minutes to *draw* the screen! (laughing in background, peers looking at me very strangely...) Well, we definitely need that HERC_drawhline to be implemented, because now it calls HERC_drawpixel for *every* pixel on the screen, all 252,000 of them. I can take a hack at rewriting that, but It'd be nice if someone with a card did it. The file is mwin/src/drivers/scr_herc.c. Ok. I'll do it, since I already have code doing the task "optimally", (how can one be sure anything is done optimally?) if I understand it correctly. (I am not the brain behind the algorithm.) (Guess I'll have to put that Herc. card in a machine then... huhm...) Regards, Jakob Eriksson
