[Freedos-user] (no subject)

2009-12-28 Thread Marcos Favero Florence de Barros
Eric,

> What I would like to know: How fast is the refresh if you
> remove idlehalt but keep fdapm? Does it make a difference
> whether you use APMDOS or ADV:REG option in that case?

Refresh times below are for the same drawing tested in previous
emails.

It would not make sense to test IDLEHALT with values other than
1, as you said yourself.


   -
   1  FDAPM APMDOS  +   IDLEHALT=1 11 sec
   -
   2  FDAPM ADV:REG +   IDLEHALT=1  6 sec
   -
   3  FDAPM APMDOS  6 sec
   -
   4IDLEHALT=1  6 sec
   -
   5  FDAPM ADV:REG about half a sec
   -
   6  (nothing) about half a sec
   -


I adopted option 5 to work with Desi-III, of course.

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-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] (no subject)

2009-12-28 Thread Alain Mouette

dos386 escreveu:
> 
>> Desi-III requires EMS memory.
> 
> It requires EMS __AND__ is low memory hoggy, a pity that such a nice
> programm is compiled that a crappy way :-(
> 
We have to remember that at the time, this was very advanced and prety 
dificult to make. It is probably older then real 32 bit mode, and even 
that was available for only a few tools

;)
Alain


--
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