Re: [Freedos-user] Odd behaviour involving mouse
Hi, Problem solved. The culprit was IDLEHALT=1 in fdconfig.sys. After removing it, Desi-III refreshes the screen under FreeDOS very fast, apparently just as fast as under MS-DOS. Here's a summary of the refresh times under FreeDOS (for a given drawing I used for testing): With IDLEHALT=1 and FDAPM APMDOS11 sec With IDLEHALT=1 5.5 sec Removing both0.4 sec (estimate) Nothing else had to be changed in FDCONFIG.SYS and FDAUTO.BAT. Thanks, and a happy new year! Marcos -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Hi all, Can anyone explain what IDLEHALT=1 does? It could be interesting to know this in more details for fure problems or even for general kowledge... @MARCOS Dir you test without IDLEHALT=1, but with the fastest possible option of FDAPM? Thanks, Alain Marcos Favero Florence de Barros escreveu: Hi, Problem solved. The culprit was IDLEHALT=1 in fdconfig.sys. After removing it, Desi-III refreshes the screen under FreeDOS very fast, apparently just as fast as under MS-DOS. Here's a summary of the refresh times under FreeDOS (for a given drawing I used for testing): With IDLEHALT=1 and FDAPM APMDOS11 sec With IDLEHALT=1 5.5 sec Removing both0.4 sec (estimate) Nothing else had to be changed in FDCONFIG.SYS and FDAUTO.BAT. Thanks, and a happy new year! Marcos -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Can anyone explain what IDLEHALT=1 does? It could be interesting to know this in more details for fure problems or even for general kowledge... IDLEHALT=1 halts the CPU (with a HLT instruction) before calling Int28, when the kernel is waiting for a key to be pressed. FreeDOS's default Int28 handler itself does nothing. FDAPM however might execute another HLT in its Int28 handler resulting in bad performance. You'll get the best performance with no HLTs at all, but one HLT before/in Int28 (IDLEHALT=1 but no FDAPM?) shouldn't affect performance badly either. That might be related to how exactly the application writes to the screen. Regards, Christian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Hi, Alain, Dir you test without IDLEHALT=1, but with the fastest possible option of FDAPM? I tested without IDLEHALT and without FDAPM, and that made Desi-III work full-speed again. Later, I reintroduced FDAPM, but with option ADV:REG as recommended by Eric, which did not cause any noticeable speed loss. Instructions say IDLEHALT=1 is the safest option, so I didn't even bother to try the others. With Desi-III, I don't use IDLEHALT anymore. Marcos -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
So, let me rephrase a bit... Without IDLEHALT=1, it enters a loop calling int28 and with it, int28 is called once for every Hardware interrupt (which brings out of HLT). Please correct me if I am wrong.. But if I am right... then it probably is that that program uses int28 to update the screen a bit at a time. This is a good way of doing a refresh, specially in those days were CPUs were so slw ;) @ERIC Could FDAPM detect IDLEHALT=1 and act accordingly? This could avoid some future problems. Also, INHO, FDAPM could have a default that is the fastest, leaving the better in terms of power-saving for users to tune... Alain Christian Masloch escreveu: Can anyone explain what IDLEHALT=1 does? It could be interesting to know this in more details for fure problems or even for general kowledge... IDLEHALT=1 halts the CPU (with a HLT instruction) before calling Int28, when the kernel is waiting for a key to be pressed. FreeDOS's default Int28 handler itself does nothing. FDAPM however might execute another HLT in its Int28 handler resulting in bad performance. You'll get the best performance with no HLTs at all, but one HLT before/in Int28 (IDLEHALT=1 but no FDAPM?) shouldn't affect performance badly either. That might be related to how exactly the application writes to the screen. Regards, Christian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Hi, The screen refresh discussion ended up involving FDAPM and IDLEHALT. Let me ask a few questions concerning their general use (not for Desi-III), since for environmental reasons everyone should save energy. 1. In order to save energy, is it sufficient to load FDAPM (with option ADV:REG for example), or do we also have to issue a command such as FDAPM STANDBY? 2. How about IDLEHALT? Do we just load it? 3. Are FDAPM and IDLEHALT meant to complement each other? Marcos -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Hi Marcos, in case you used an USB mouse with BIOS PS/2 over USB support: Try a PS/2 mouse or a DOS USB driver instead of BIOS legacy. 4. Holding down keyboard keys while screen refreshes, as suggested by Larry (doc...@yahoo.com): shift, ctrl and alt keys cut screen refreshing time by half. Right-hand alt key is even slightly better. Why does that make a difference? 5. FDAPM (FreeDOS tool for APM power management and energy saving). I was loading FDAPM with option APMdos (keep FDAPM in RAM, save most energy). By not loading it, refreshing time is cut by half. Same improvement can be obtained by loading it with option APMbios instead of APMdos. Did you try FDAPM ADV:REG instead of FDAPM APMDOS? The ADV:REG method is documented to sometimes give better performance, for example with Novell, but save a bit less energy (no int 28 idle). Methods 4 and 5 are cumulative, i.e., refresh time is reduced to one-quarter of the original time if both are used. This is a substantial improvement, but still a long way away from the speed of MS-DOS. How big is the difference? Does the MS kernel matter, the MS mouse driver or both? Eric PS: Happy holidays to everybody :-) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Hi Eric, in case you used an USB mouse with BIOS PS/2 over USB support: Try a PS/2 mouse or a DOS USB driver instead of BIOS legacy. My mouse is not USB. It is a real old one, with a flat plug with two rows of holes. 4. Holding down keyboard keys while screen refreshes, as suggested by Larry (doc...@yahoo.com): shift, ctrl and alt keys cut screen refreshing time by half. Right-hand alt key is even slightly better. Why does that make a difference? I have no idea why it makes a difference. I can only say that, for the drawing used for tests, the screen normally refreshes in about 10 sec, but will refresh in 5 sec if either shift, ctrl or alt is held down. Did you try FDAPM ADV:REG instead of FDAPM APMDOS? I can try it, but as far as screen refreshing speed is concerned, option APMbios seems good enough: it is as fast as if FDAPM was not loaded. Methods 4 and 5 are cumulative, i.e., refresh time is reduced to one-quarter of the original time if both are used. This is a substantial improvement, but still a long way away from the speed of MS-DOS. How big is the difference? Does the MS kernel matter, the MS mouse driver or both? These are the differences observed under FreeDOS: -- Method 5 (avoiding option APMDOS for FDAPM) by itself reduces screen refreshing time from 10 to 5 sec. -- Method 4 (holding down keys) by itself also reduces it from 10 to 5 sec. -- Methods 4 and 5 in combination reduce it from 10 to 2.5 sec, i.e., both have their effect. The mouse driver does not seem to matter: speed is the same with either CuteMouse or Logitech driver. Please explain what MS kernel is. Is it a file in Microsoft DOS, like the one in FreeDOS? Anyway, tests with MS-DOS were done with version 6.22, installed from original floppies. Here is a summary of the whole thing: - Under FreeDOS, refresh speed is increased by avoiding FDAPM with option APMDOS. It can be further increased in two ways: by holding down keys or, much better, by moving the mouse. - Under MS-DOS, refresh speed is much faster than any of the above. Regards, Marcos -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
My mouse is not USB. It is a real old one, with a flat plug with two rows of holes. Serial mouse ;-) Again, try to save more low memory under FreeDOS. -- ~~~ wow ~~~ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
I don't know if this relates or not. I use Freedos in a dosemu emulator in Linux. In that environment, arachne won't update a screen unless I hold down a moust button, or a shift key (or some key). Have you tried holding down a shift key to see if your CAD then updates the screen faster? --- On Tue, 12/22/09, Marcos Favero Florence de Barros fav...@mpcnet.com.br wrote: From: Marcos Favero Florence de Barros fav...@mpcnet.com.br Subject: [Freedos-user] Odd behaviour involving mouse To: FreeDOS List freedos-user@lists.sourceforge.net Date: Tuesday, December 22, 2009, 6:13 AM Hi, I'm an engineer and a user of DESI-III, a professional-quality freeware CAD from Belgium, with which I draw mechanical parts for a product I'm developing. Since I started using FreeDOS in 2007 I noticed that it was taking longer for DESI-III to refresh the screen -- an important point for CAD software, because we must zoom in and out all the time. Then a few days ago I noticed that, if the mouse is moved, the screen refreshes much faster. For instance, the drawing I'm currently working on would take 11 seconds to refresh, whereas if the mouse is slightly pushed in any direction while the image is appearing on the screen, the process takes only 2 seconds, i.e., it gets *five* times faster. Then last night I decided to run Desi-III under MS-DOS. I reinstalled it in a spare hard drive, and it turned out that the speed difference is huge. Under MS-DOS the screen redraws so fast that couldn't measure the time. It must be something below 0.2 seconds for that same drawing, so we are talking about a factor of *fifty* here. I had already written to Desi-III's author Hugo Mari‰n about this. He answered: It is a surprisingly story you are telling, because IMHO it has nothing to do with DESI-III but with your configuration. [..] DESI-III only calls the mouse on demand, it doesn't need to call the mouse driver when the screen is refreshed someway or an other, it only calls the mouse when it needs displacements or a button detection else the mouse is left alone. Back to FreeDOS, I did some simple testing, such as changing the mouse driver from CTMouse to Logitech, and changing the mouse itself, with no results. If there is any additional test that I could do, please let me know, and I'll report back ... after Christmas :-) Desi-III can be downloaded from: http://users.telenet.be/desi-iii Regards, Marcos Marcos Favero Florence de Barros Sao Paulo, Brazil 55-19-3231-8194 fav...@mpcnet.com.br -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
I guess there is one test that could be done... Is it possible do run a test without any mouse driver installed? Of course, only if th SW is capable of keyboard-only operation. Alain Marcos Favero Florence de Barros escreveu: Hi, I'm an engineer and a user of DESI-III, a professional-quality freeware CAD from Belgium, with which I draw mechanical parts for a product I'm developing. Since I started using FreeDOS in 2007 I noticed that it was taking longer for DESI-III to refresh the screen -- an important point for CAD software, because we must zoom in and out all the time. Then a few days ago I noticed that, if the mouse is moved, the screen refreshes much faster. For instance, the drawing I'm currently working on would take 11 seconds to refresh, whereas if the mouse is slightly pushed in any direction while the image is appearing on the screen, the process takes only 2 seconds, i.e., it gets *five* times faster. Then last night I decided to run Desi-III under MS-DOS. I reinstalled it in a spare hard drive, and it turned out that the speed difference is huge. Under MS-DOS the screen redraws so fast that couldn't measure the time. It must be something below 0.2 seconds for that same drawing, so we are talking about a factor of *fifty* here. I had already written to Desi-III's author Hugo Mari‰n about this. He answered: It is a surprisingly story you are telling, because IMHO it has nothing to do with DESI-III but with your configuration. [..] DESI-III only calls the mouse on demand, it doesn't need to call the mouse driver when the screen is refreshed someway or an other, it only calls the mouse when it needs displacements or a button detection else the mouse is left alone. Back to FreeDOS, I did some simple testing, such as changing the mouse driver from CTMouse to Logitech, and changing the mouse itself, with no results. If there is any additional test that I could do, please let me know, and I'll report back ... after Christmas :-) Desi-III can be downloaded from: http://users.telenet.be/desi-iii Regards, Marcos Marcos Favero Florence de Barros Sao Paulo, Brazil 55-19-3231-8194 fav...@mpcnet.com.br -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Odd behaviour involving mouse
Since I started using FreeDOS in 2007 I noticed that it was taking longer for DESI-III to refresh the screen -- an important point for CAD software, because we must zoom in and out all the time. Nice that someone uses DESI-III with FreeDOS :-) Then last night I decided to run Desi-III under MS-DOS. I reinstalled it in a spare hard drive, and it turned out that the speed difference is huge. Under MS-DOS the screen redraws so fast that couldn't measure the time. It must be something below 0.2 seconds for that same drawing, so we are talking about a factor 50 Back to FreeDOS, I did some simple testing, such as changing the mouse driver from CTMouse to Logitech, and changing the mouse itself, with no results. Very strange ... It is a surprisingly story you are telling, because IMHO it has nothing to do with DESI-III but with your configuration. 1. Try EDR-DOS 2. Reveal what EMM386 you are using (regrettably DESI-III requires EMS IIRC) 3. Other stuff (driver, TSR) present ??? 4. Free more low memory (frustrating low memory wars ... I hate them) or EMS page frame size This is most like related to the low memory hogginess of DESI-III and the EMS usage :-( Of source, porting DESI-III to 32-bit DOS (WATCOM FORTRAN) would be a great thing :-) Is it possible do run a test without any mouse driver installed? Of course, only if th SW is capable of keyboard-only operation. IIRC you can't even exit DESI-III with the keyboard (this is a BUG ...) -- ~~~ wow ~~~ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
