Re: [Freedos-user] Odd behaviour involving mouse

2009-12-28 Thread Marcos Favero Florence de Barros
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

2009-12-28 Thread Alain Mouette
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

2009-12-28 Thread Marcos Favero Florence de Barros
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

2009-12-28 Thread Christian Masloch
> 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

2009-12-28 Thread Alain Mouette
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

2009-12-28 Thread Marcos Favero Florence de Barros
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

2009-12-27 Thread dos386
> 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

2009-12-27 Thread Marcos Favero Florence de Barros
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

2009-12-27 Thread Eric Auer

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

2009-12-22 Thread dos386
> 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


Re: [Freedos-user] Odd behaviour involving mouse

2009-12-22 Thread Alain Mouette
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

2009-12-22 Thread Larry
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  
wrote:

> From: Marcos Favero Florence de Barros 
> Subject: [Freedos-user] Odd behaviour involving mouse
> To: "FreeDOS List" 
> 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