Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Hi, On Mon, Jun 30, 2014 at 12:30 PM, Zbigniew wrote: > 2014-06-30 19:19 GMT+02:00, Rugxulo : > >> IIRC, 4DOS can swap out (since it's quite large) to conserve >> conventional memory. You may have to change that setting (SWAPPING ?? >> I forget ...). I don't think it's something inherently wrong with >> 4DOS, but who knows. > > But I already wrote, that when using JEMMEX and 4DOS I had more memory > available (both conventional & upper), than using XMGR + FREECOM? But not by much. Sorry, but 599 vs 609 kb isn't really worth worrying about, IMHO. Of course, the extra 14 kb UMB is more significant (barely), but have you tried UMBPCI? Then you don't need EMM386 at all. http://www.uwe-sieber.de/umbpci_e.html For me, I just use XMS only, and it's good enough. (I encountered a few rare incompatibilities with EMM386, esp. NOVCPI, so I don't load any of that by default anymore.) I put all the unloadable stuff at the end of my AUTOEXEC, so if I need the RAM, I can reclaim it manually instead of rebooting. I can't remember all of them, but at least NNANSI, CTMOUSE, SHCDX33F can unload. (Okay, BIOS emulation bugs make CTMOUSE almost unusable for me when physically connected via USB instead of PS/2. Not that I prefer the mouse for anything anyways. So these days it's disabled by default.) > And - despite of this - that only in latter case I could switch to shell from > TC's IDE? No idea, I'm not a heavy user of TC201's IDE. But I'm still not sure I'd blame 4DOS entirely (if at all). Keep fiddling with it, try to see if you can isolate (or avoid) the problem without switching shells entirely. Actually, maybe the IDE is checking COMSPEC and you're not loading that properly? Or maybe it expects hardcoded COMMAND.COM or even C:\COMMAND.COM? Maybe if you renamed 4DOS.COM (locally) to C:\4DOS\COMMAND.COM and tried that?? BTW, does this mean you tried JEMMEX + FreeCOM as well? Results? -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
On Mon, Jun 30, 2014 at 1:30 PM, Zbigniew wrote: > 2014-06-30 19:19 GMT+02:00, Rugxulo : > >> IIRC, 4DOS can swap out (since it's quite large) to conserve >> conventional memory. You may have to change that setting (SWAPPING ?? >> I forget ...). I don't think it's something inherently wrong with >> 4DOS, but who knows. > > But I already wrote, that when using JEMMEX and 4DOS I had more memory > available (both conventional & upper), than using XMGR + FREECOM? And > - despite of this - that only in latter case I could switch to shell > from TC's IDE? I've encountered that in other contexts. 4DOS works essentially the same way a COMMAND.COM. There is a resident portion and a transient portion. When you load the shell, the resident portion is relocated to the top of available memory. When you run a program from the shell, the transient portion is overwritten by your program to give it more conventional memory. When you exit the program, the transient portion is reloaded, using the SHELL= line to specify what to reload from and where to find it. (If you use a stock system with COMMAND.COM, you don't need the SHELL= line, because DOS will reload from \COMMAND.COM on your boot drive.) The transient portion of 4DOS is much larger than than that of COMMAND.COM. 4DOS will let you swap most of itself EMS, XMS, or disk, depending on what you specified in the SWAPPING config, to leave more room in conventional RAM. The problem is what happens when you shell to DOS from within an application. You are attempting to load COMMAND.COM or 4DOS in the conventional memory left over by the application you shelled from. If your application takes enough conventional memory, 4DOS will fail to load because there isn't enough room left for its transient portion, but COMMAND.COM will work because it will fit. I tend to invoke such applications from a batch file that sets SHELL to point to COMMAND.COM instead of 4DOS, and invoke the app by "command /c app" to start it from COMMAND.COM. > Z. __ Dennis -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
2014-06-30 19:19 GMT+02:00, Rugxulo : > Hi, > > On Sun, Jun 29, 2014 at 7:05 PM, Zbigniew wrote: >> >> No, no such exotic options, > > Well, I would maybe recommend "I=TEST X=TEST". I used - and still use - exactly the two above. > IIRC, 4DOS can swap out (since it's quite large) to conserve > conventional memory. You may have to change that setting (SWAPPING ?? > I forget ...). I don't think it's something inherently wrong with > 4DOS, but who knows. But I already wrote, that when using JEMMEX and 4DOS I had more memory available (both conventional & upper), than using XMGR + FREECOM? And - despite of this - that only in latter case I could switch to shell from TC's IDE? -- Z. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Hi, On Sun, Jun 29, 2014 at 7:05 PM, Zbigniew wrote: > > No, no such exotic options, Well, I would maybe recommend "I=TEST X=TEST". > and using JEMM386 didn't help Again, I think it's better to LOAD and UNLOAD from cmdline (JEMM386) when needed to avoid such problems. > - but I located the problem: JEMMEX isn't to blame. Somehow TC's > IDE doesn't like 4DOS - when switched to FREECOM, the problem is gone. IIRC, 4DOS can swap out (since it's quite large) to conserve conventional memory. You may have to change that setting (SWAPPING ?? I forget ...). I don't think it's something inherently wrong with 4DOS, but who knows. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
2014-06-29 21:16 GMT+02:00, Rugxulo : > I don't know which versions exactly, but AFAIK, Turbo C tries to use > EMS by default (if found) but not XMS (without some cmdline switches). > So who knows if it's getting confused here. Remember that 32 MB of EMS > is a lot (to it)! > > Are you using any switches like NOVCPI or FRAME=NONE? Try eliminating > any unusual switches at load time. > > Try using something else like EMSMAGIC (or EMM286 or whatever) and see > if the problem goes away. Heck, it might be JEMMEX specific, so try > using (XMS +) JEMM386 separately. (At least that can LOAD and UNLOAD > manually, so less clashes.) No, no such exotic options, and using JEMM386 didn't help - but I located the problem: JEMMEX isn't to blame. Somehow TC's IDE doesn't like 4DOS - when switched to FREECOM, the problem is gone. -- Z. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Hi, On Sun, Jun 29, 2014 at 8:45 AM, Zbigniew wrote: > 2014-06-29 15:25 GMT+02:00, Mateusz Viste : > >> I am not sure it's related to the XMS manager you use. > > Unfortunately, it seems to be related. > >> It's rather a matter of the amount of conventional memory you have. > > No, it was what I checked first before posting. > >> Maybe when using >> XMGR you end up with more free memory < 640K than when using Jemmex? > > JEMMEX left more memory: 609k conventional and 14k upper - while XMGR > left 599k of conventional, and no upper at all. I don't know which versions exactly, but AFAIK, Turbo C tries to use EMS by default (if found) but not XMS (without some cmdline switches). So who knows if it's getting confused here. Remember that 32 MB of EMS is a lot (to it)! Are you using any switches like NOVCPI or FRAME=NONE? Try eliminating any unusual switches at load time. Try using something else like EMSMAGIC (or EMM286 or whatever) and see if the problem goes away. Heck, it might be JEMMEX specific, so try using (XMS +) JEMM386 separately. (At least that can LOAD and UNLOAD manually, so less clashes.) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Strange then. Maybe Jemmex provides more memory overall, but it's
fragmented for some reasons? MEM should tell you the size of the longest
contiguous block in memory ("largest executable block size" IIRC).
Mateusz
On 06/29/2014 03:45 PM, Zbigniew wrote:
> 2014-06-29 15:25 GMT+02:00, Mateusz Viste :
>
>> I am not sure it's related to the XMS manager you use.
>
> Unfortunately, it seems to be related.
>
>> It's rather a matter of the amount of conventional memory you have.
>
> No, it was what I checked first before posting.
>
>> Maybe when using
>> XMGR you end up with more free memory < 640K than when using Jemmex?
>
> JEMMEX left more memory: 609k conventional and 14k upper - while XMGR
> left 599k of conventional, and no upper at all.
>
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
2014-06-29 15:25 GMT+02:00, Mateusz Viste : > I am not sure it's related to the XMS manager you use. Unfortunately, it seems to be related. > It's rather a matter of the amount of conventional memory you have. No, it was what I checked first before posting. > Maybe when using > XMGR you end up with more free memory < 640K than when using Jemmex? JEMMEX left more memory: 609k conventional and 14k upper - while XMGR left 599k of conventional, and no upper at all. -- Z. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
I am not sure it's related to the XMS manager you use. It's rather a matter of the amount of conventional memory you have. Maybe when using XMGR you end up with more free memory < 640K than when using Jemmex? Mateusz On 06/29/2014 03:20 PM, Zbigniew wrote: > What I also noticed, Turbo C 2.01 doesn't like JEMMEX - while having > around 32 MB of EMS and 1 GB of XMS, I cannot switch to shell from its > IDE; it complained: "not enough memory, press Esc". > > No such problem when using XMGR instead of JEMMEX. > -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
What I also noticed, Turbo C 2.01 doesn't like JEMMEX - while having around 32 MB of EMS and 1 GB of XMS, I cannot switch to shell from its IDE; it complained: "not enough memory, press Esc". No such problem when using XMGR instead of JEMMEX. -- Z. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
2014-06-19 1:05 GMT+02:00, Louis Santillan : > The uide drivers gets updated rather frequently. Find the latest here < > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis> Well I used the latest one - and it turned out, that older uide2.sys is more "Turbo C compatible" than newest uide.sys. But only when used for CD-ROM, not main HDD. -- regards, Zbigniew -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
The uide drivers gets updated rather frequently. Find the latest here < http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis> On Wed, Jun 18, 2014 at 3:39 PM, Zbigniew wrote: > I noticed another issue while using Turbo C 2.01: > > If in the fdconfig.sys there is uide.sys used (or uide2.sys used for > HDD) - the compilation is incredibly slow (100x or 200x times slower). > But it is enough to _not_ use this driver, or to use uide2.sys with > parameter like "/D:CDROM", to have Turbo C compiling at its normal > pace. > -- > regards, > Zbigniew > > > -- > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
I noticed another issue while using Turbo C 2.01: If in the fdconfig.sys there is uide.sys used (or uide2.sys used for HDD) - the compilation is incredibly slow (100x or 200x times slower). But it is enough to _not_ use this driver, or to use uide2.sys with parameter like "/D:CDROM", to have Turbo C compiling at its normal pace. -- regards, Zbigniew -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
On Fri, May 23, 2014 at 4:49 PM, Eric Auer wrote: > > Hi! > >> After a fresh install of FreeDos, I found turbo c 2.01 is terribly slow to >> run. > > That depends on what you mean by Turbo C. The IDE (editor) of it? > Compiler? Some program written in Turbo C? What kind of program? I meant the Turbo C IDE was slow with FDAPM. > >> even the speed of scrolling the screen is unacceptable. However, >> when I unloaded FDAPM, turbo c became normal. >> >> Is there any work around? Is it a bug in Turbo C or in FDAPM? > > Which other drivers do you have loaded and what type of hardware > is this? Do you also use Do you also use the FreeDOS kernel power > saving function IDLEHALT at the same time? With which settings? I tested it with VirtualBox, qemu and a desktop PC, all have the same symptom. And I didn't know about IDLEHALT, after a quick web search, I think I didn't active it. > > If "FDAPM APMDOS" puts the CPU on idle too often, slowing down > your programs, try "FDAPM ADV:REG" or "FDAPM ADV:MIN" instead. > The default setting is equivalent to "FDAPM ADV:MAX" there. You > can see the current setting with "FDAPM STATS" :-) Of course in > the MIN setting, less energy is saved. REG is a good compromise. Thanks for all the information. "FDAPM ADV:REG" did the trick for me. maybe it's a better default setting than "FDAPM APMDOS". > > Regards, Eric > > > > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user Pluto -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM slow turbo c 2.01 down
Hi! > After a fresh install of FreeDos, I found turbo c 2.01 is terribly slow to > run. That depends on what you mean by Turbo C. The IDE (editor) of it? Compiler? Some program written in Turbo C? What kind of program? > even the speed of scrolling the screen is unacceptable. However, > when I unloaded FDAPM, turbo c became normal. > > Is there any work around? Is it a bug in Turbo C or in FDAPM? Which other drivers do you have loaded and what type of hardware is this? Do you also use Do you also use the FreeDOS kernel power saving function IDLEHALT at the same time? With which settings? If "FDAPM APMDOS" puts the CPU on idle too often, slowing down your programs, try "FDAPM ADV:REG" or "FDAPM ADV:MIN" instead. The default setting is equivalent to "FDAPM ADV:MAX" there. You can see the current setting with "FDAPM STATS" :-) Of course in the MIN setting, less energy is saved. REG is a good compromise. Regards, Eric -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] fdapm and dpakbd aware programs (no subject)
Hi Marcos, >> another chance would obviously be making fdapm aware :-) > > Do you mean, authors making their programs FDAPM aware? No I mean making FDAPM aware of the programs... Exactly the same way as your "DPAKBD" is aware of your programs, without having to change your programs, as I understood. > The only programs I write are in high-level languages such as > Euphoria. Interestingly, I checked the Euphoria manual, and > found that there are two distinct input commands, get_key() and > wait_key(). The difference is that... I remember you talking about that - this would be an example for making programs in a style that makes it easier for FDAPM, POWER and similar to see idleness. > wait_key() lets the operating system do other useful work > while your program is waiting for the user to press a key." I do not think that I understand what DOS Euphoria does there... > So I changed all the get_key's in my programs into wait_key's, > and it really worked ... it even passed the finger-on-CPU test So even if we do not understand, it still does the right thing :-) > Examples of non-aware programs which I use often and typically > for long periods are: SuperCalc spreadsheet, DataPerfect > database, Desi-III CAD, and the image viewers ShowJPG, PictView > and LXPic. I don't think their authors would change them... Is any of them free for download? In what way are they CPU-hot? And in what way does DPAKBD treat them differently? Are there also side effects of using DPAKBD? Does it maybe slow down the programs that it makes CPU-cool? Or does it slow down others? > juncture. Fortunately, DPAKBD has been working well with them, > but subject to the inconveniences I reported in the previous > email, like freezing and rebooting. Can you give some more explanations about what DPAKBD is and does, which license it has, which configuration options...? > Text editors are no problem, since the best of them -- Aurora, > FTE, Thomson-Davis, SetEdit -- are all natively FDAPM-aware. Nice :-) > Same for the Links browser. Also nice :-) How about elinks, lynx, w3m, Arachne, Dillo? Eric -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM
Am 09.10.11 02:21, schrieb Jack: > Absolutely NO "self respecting" computer, or computer program, > should at-all REQUIRE using "FDAPM" or any equivalents! What > has happened to Industrial RESPONSIBILITY, i.e. making systems > that RUN, WITHOUT requiring such "Band Aid" power software??!! > > In my opinion, and "laptop" OR NOT, any computer that DOES get > too hot just "sitting there" is a HOPELESS piece of TRASH that > should be sent back for a REFUND (if possible!), or should get > the solution that "DOS386" voiced on this forum (in one word!) > about my ATROCIOUS medical bills, 4 months ago: KALASHNIKOV!! Wasnt't this in "Tron"? FDAPM-aware software: "Nooo! I just wanted to respect the FDAPM!" Master Control Program: "Die, you hopeless piece of crap!" bangbangbangbangbang -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM
I run a 15-year-old Windows/NT V4.0, "backed up" (and restored occasionally!) by a 17-year-old V6.22 MS-DOS. My system is a "flat" desktop (not a "tower") with its power-supply fan and a 13-CFM extra fan, thanks to my old 85-watt AMD 2100 CPU. TOO MUCH, so now I have a 45 watt AMD 3000+, which never goes over 40 degrees centigrade with its "stock AMD" CPU fan, the power- supply fan, and my "extra boy" on the back of the case. With the above hardware and software, I HAVE NEVER had any DOS or Windows/NT program cause overheating, merely from my system "sitting there" and no-matter WHAT "idle loop" was being used! I have absolutely NO "power management" software, and all BIOS options to "control" power are disabled or turned-off!Even with my "hot running" 2100+, it never got over 60-C, far below AMD's 85-C design limit for those 10-year-old chips! Absolutely NO "self respecting" computer, or computer program, should at-all REQUIRE using "FDAPM" or any equivalents! What has happened to Industrial RESPONSIBILITY, i.e. making systems that RUN, WITHOUT requiring such "Band Aid" power software??!! In my opinion, and "laptop" OR NOT, any computer that DOES get too hot just "sitting there" is a HOPELESS piece of TRASH that should be sent back for a REFUND (if possible!), or should get the solution that "DOS386" voiced on this forum (in one word!) about my ATROCIOUS medical bills, 4 months ago: KALASHNIKOV!! -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM
Am 08.10.11 19:54, schrieb Rugxulo: >> It would be really good if a helpful FreeDOS developer could add FDAPM >> awareness to more important programs in FreeDOS. > I assume the shell would benefit from this the most, if not already. The shell has no problem. CPU usage is normal (4%) if FDAPM is running, which is the default in FreeDOS. I often work with a nc clone, so finding out about the option in doszip was very helpful. I also replaced FreeDOS Edit with Pedit [1] which is freeware (but unfortunately not open source). > Perhaps you can manually configure your Mac OS X to "power saver" > (decrease or disable one of the cores) at those times? If I leave FreeDOS running in VirtualBox with a not FDAPM aware program like FreeDOS Edit, after 30 minutes OS X will pop up a nice half transparent window. It tells me that my computer needs now to be shut down and that I should push the power button long enough to do so. There is no other option. It's the Mac version of the BSOD. > There really is no perfect answer as modern hardware is just too > powerful to run without a fan. If the problem meant that just a fan is running, it would be cool with me. But I doubt that a CPU running _constantly_ at 100, even at 40% is such a good idea. I mean even when I open a large picture with Photoshop, CPU usage goes up to 40 only for a second and then stays at 6 or 7 percent. I will do some more tests if the problem occurs on my old laptop with Windows XP and with Ubuntu as well. regards Ulrich [1] http://www.goldshell.com/pedit/ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM
Hi, On Sat, Oct 8, 2011 at 2:25 AM, Ulrich Hansen wrote: > > It would be really good if a helpful FreeDOS developer could add FDAPM > awareness to more important programs in FreeDOS. I assume the shell would benefit from this the most, if not already. Other stuff? Dunno, probably less benefit as not used as frequently. > The unlimited CPU usage of FreeDOS programs running in VirtualBox is > not a virtual or theoretical problem. It is real and it can cause real > physical damage. My laptop was in fact overheating and shut down > automatically. Were you blocking the fan vent? Perhaps it's just one of those models which is too power-hungry for its own good? Sadly, a lot of computers are like that, esp. laptops, designed for ultra-modern OSes which take a lot of juice. There are pads / rests with electric USB fans in them you can buy, but I'm not convinced they help much. Just make sure you don't suffocate the airway, keep it slightly propped up, not flat on the table, and don't block the back. > Until this is solved, people should be recommended to limit at least > the CPU usage in VirtualBox. But even with 40 percent the laptop gets > too warm. Perhaps you can manually configure your Mac OS X to "power saver" (decrease or disable one of the cores) at those times? There really is no perfect answer as modern hardware is just too powerful to run without a fan. Only very rarely can you find an x86 chip that doesn't need one (e.g. some VIA models), but those aren't usually targeted at consumers and are much slower overall. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM
Am 08.10.11 06:59, schrieb Marcos Favero Florence de Barros: > FDAPM is *very* effective, but softwares must be FDAPM-aware. > > DosZip is FDAPM-aware and will typically use only 2% of CPU time, > provided it is configured for that. Go to the Setup, System Options > menu and chech the "Use DOS Idle Int 2Fh" checkbox. Thanks a lot! CPU usage dropped from 100% to 4% with that setting. I also will look into DPAKBD. It would be really good if a helpful FreeDOS developer could add FDAPM awareness to more important programs in FreeDOS. The unlimited CPU usage of FreeDOS programs running in VirtualBox is not a virtual or theoretical problem. It is real and it can cause real physical damage. My laptop was in fact overheating and shut down automatically. Until this is solved, people should be recommended to limit at least the CPU usage in VirtualBox. But even with 40 percent the laptop gets too warm. Have a nice weekend! Ulrich -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM in notebooks
Hi, On 2/1/11, Eric Auer wrote: > >> Texts (mainly Aurora editor), databases (DataPerfect), >> spreadsheets (SuperCalc). > > Interesting, I know none of those :-) I'm sure you've heard of Aurora. >> BUFFERS=4 > > A bit more might be good. Not needed if using UIDE as cache (see below). >> DEVICE=C:\FDOS\JEMM\JEMFBHLP.EXE > > FB as in framebuffer? Does this really help you? I forget exactly, (don't use this often, probably should), but I think this is the "fastboot" helper (speeds up rebooting) since FreeDOS needed a little extra help (unlike MS). >> SHELLHIGH=C:\RECURSOS\4DOS\4dos.com C:\RECURSOS\4DOS /P=C:\fdauto47.bat > > Does it make a difference to use SHELL without HIGH > or to use FreeCOM, for memory and idleness purposes? The shell probably does make a difference for idleness, but I'm assuming he's using 4DOS on all machines. >> loadhigh DISPLAY con=(EGA,,1) >> MODE con codepage prepare=((850) C:\RECURSOS\FONTTELA\sanse_38.cpi) >> loadhigh MODE con codepage select=850 > > A user of codepages :-) With a custom font? Doesn't DISPLAY already loadhigh if possible (but rarely due to always needing like 64 kb)? But I don't think doing LOADHIGH for MODE saves anything as MODE doesn't stay resident. >> DEVLOAD /H C:\FDOS\UIDE\UIDE.SYS /S25 /H /PM > > If you use UIDE, did you try loading it earlier? > Not sure what the docs recommend about relative > loading time compared to EMM386, though... I'd have to re-read comments from Jack again, but it never seemed worth it (for me) to try to use the HMA for UIDE. Only if you care about the HMA should you try this (why bother, I say). Just load it instead in CONFIG.SYS unless you really really need the alleged savings (doubt it). EDIT: To load in HMA under FreeDOS, Jack says "CONFIG.SYS must have a "BUFFERS=4" line, and UIDE must be loaded thru AUTOEXEC.BAT using DEVLOAD." (I posted this under the News of Aug-15 drivers update. iBiblio mirror is still six months behind, only has drivers-2010-06-16.zip and older, latest is from Dec. 5.) >> loadhigh C:\RECURSOS\4DOS\kstack.com > > A command history? Or just more keyboard buffer? I don't use this either (it comes with 4DOS, right?), but I think it's to allow programs to pre-load the buffer with specific keys at runtime. >>> Does this also happen with a clean boot (no drivers loaded)? >> >> Yes. The Aurora editor, for instance, usually reaches 98-99% idle >> time on desktops, but only 50% on the ThinkPad with nothing >> loaded except COMMAND.COM and FDAPM. > > Quite interesting! Dunno, but it sounds like the BIOS is doing something behind the scenes. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM in notebooks
Hi Marcos, > Texts (mainly Aurora editor), databases (DataPerfect), > spreadsheets (SuperCalc). Interesting, I know none of those :-) > Pentiums, year 1995-2000, CPU speeds > 133-333 MHz, memories 96-128 MB. > BUFFERS=4 A bit more might be good. > DEVICE=C:\FDOS\JEMM\JEMFBHLP.EXE FB as in framebuffer? Does this really help you? > SHELLHIGH=C:\RECURSOS\4DOS\4dos.com C:\RECURSOS\4DOS /P=C:\fdauto47.bat Does it make a difference to use SHELL without HIGH or to use FreeCOM, for memory and idleness purposes? > loadhigh DISPLAY con=(EGA,,1) > MODE con codepage prepare=((850) C:\RECURSOS\FONTTELA\sanse_38.cpi) > loadhigh MODE con codepage select=850 A user of codepages :-) With a custom font? > Shsurdrv /D32M$Disco_Virtu Nice ramdisk :-) > DEVLOAD /H C:\FDOS\UIDE\UIDE.SYS /S25 /H /PM If you use UIDE, did you try loading it earlier? Not sure what the docs recommend about relative loading time compared to EMM386, though... > loadhigh C:\RECURSOS\4DOS\kstack.com A command history? Or just more keyboard buffer? The former is built-in with FreeCOM and for the latter you could try a FDCONFIG option, see the docs of the kernel (fdconfig.txt?)... > loadhigh c:\FDOS\BIN\keyb.exe br,850 MKEYB could also be interesting - it is tiny but only has a selection of built-in layouts. > loadhigh c:\fdos\bin\FDAPM.COM APMDOS FDAPM is small in RAM, so you can try if it works more efficiently outside UMBs. >> Does this also happen with a clean boot (no drivers loaded)? > > Yes. The Aurora editor, for instance, usually reaches 98-99% idle > time on desktops, but only 50% on the ThinkPad with nothing > loaded except COMMAND.COM and FDAPM. Quite interesting! Does the ThinkPad use any fancy BIOS stuff such as extra energy saving or USB-to-PS2 or similar BIOS based drivers? > Another intriguing fact is that I've already seen -- albeit very > rarely -- high numbers on the notebooks such as 90%, and low ones > on the desktops such as 3%. That is indeed unusual. It sometimes happens when software has idle loops which are not supported that well by FDAPM, e.g. SSH2DOS or other networked software, but if you mean very different idle ratio even with the same software then it is of course unexpected :-) How idle you get in part depends on which IRQ sources are active on your system and in part on what your BIOS does and whether you have hardware energy saving such as CPU throttle. > Could this be related to BIOS power management, > such as HDD power down, system doze, standby, > suspend, etc? Is the "FDAPM stats" > calculation influenced by these? It could be that standby / suspend confuses the statistics, but HDD power down is mostly done by your harddisk itself, the BIOS only sets a timer inside the harddisk one time for that. As said above, doze can have an effect if the system already "takes away CPU time" in other ways if the system is not busy. Then there is less work to be done for FDAPM but that is ok. Eric :-) -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM in notebooks
Marcos Favero Florence de Barros wrote: > Is there something that must be configured differently in notebooks > to achieve higher CPU idle times? Please tell us a little more about the specs of the notebooks / desktop. Does this also happen with a clean boot (no drivers loaded)? Robert Riebisch -- BTTR Software http://www.bttr-software.de/ -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] (fdapm vs idlehalt performance and energy saving in dos)
Hi Marcos, thanks for the in-depth measurements :-) >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. I agree that this is the best option. To answer your questions: IDLEHALT is in the kernel, you do not have to load it. You only activate it or not. FDAPM is more advanced, but takes a bit of DOS memory. The ADV:REG option usually saves almost as much of your battery power as the normal APMDOS option. You do not get extra savings by combining FDAPM and IDLEHALT, only slowness ;-) You do not need to standby or suspend DOS - just shutdown the PC when you do not need it and reboot it when you need it again, a DOS system usually boots very quickly. However, FDAPM does have support for APM BIOS standby and suspend. Whether it actually will work and wake up properly depends on the BIOS. If you get stuck, you can always keep the power button of your PC pressed for several seconds to force a power-off or power-on. Newer BIOSes do not support any APM. They only support ACPI. For ACPI, FDAPM gives you throttling (SPEED1 to SPEED8) and poweroff but no actually useful standby or suspend options... Throttling means that your CPU will be halted up to 7/8 of the time, which is also a nice thing for playing too fast old DOS games :-). It is also possible to suspend other components with DOS PCISLEEP. Note that all the throttling and suspending stuff does not save much more energy than FDAPM APMDOS on a typical desktop PC if DOS is just waiting for input at the prompt. I also made a tool for AMD "Cool n Quiet" to switch my CPU to 1 GHz and lower voltage, but this only works for the CPU and mainboard for which you compile it. For automatic setup for generic PC, the tool would be complex and I was lazy... -- 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] fdapm...
Hi Blakeslee, standby is mostly APM based, but if your PC likes ACPI better than APM, then you should try the following: Make sure wake-on-lan is enabled in your BIOS / CMOS setup and use FDAPM POWEROFF to switch off your PC. It should be possible to wake up from there via WoL. > ... to standby or s3 I think is what I need. So that they > will be ready to receive and respond to WOL packets ... About this issue: > go into standby and stay there instead of > coming back up as it does. Depends on what it says. Maybe your network / sound / mouse or USB or whatever hardware generate wake up events? You might be able to configure that in BIOS setup as well. It can also be the case that standby is not properly supported by fdapm for your BIOS or hardware ... Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] fdapm speed# not working for me
> So far, only two things worked for me: > - using the "throttle" tool (http://www.oldskool.org/pc/throttle/DOS), > - disabling my processor's cache (there's a CPUCACHE program somewhere... just > google after it... or disable your cache right in the BIOS). I already tried throttle and it didn't worked for me. Besides, I think that throttle does exactly the same job as fdapm speed# : """ Throttle uses your system hardware to modify the clock speed going to your CPU, rather than using software "delay loops" or HLT instructions to slow your machine down. This method provides very smooth slowdowns without any incompatibilies with software.""" -- Fabien Meghazi Website: http://www.amigrave.com Email: [EMAIL PROTECTED] IM: [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] fdapm speed# not working for me
On Saturday 26 January 2008, Fabien Meghazi wrote: > So I played a little with fdapm speed<1-8> and it just have no effect > ! Or if there's an effect, it's unnoticeable. So far, only two things worked for me: - using the "throttle" tool (http://www.oldskool.org/pc/throttle/DOS), - disabling my processor's cache (there's a CPUCACHE program somewhere... just google after it... or disable your cache right in the BIOS). bye, Mateusz Viste - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM
FDPKG basically replaces FDPM On 7/7/07, Florian Xaver <[EMAIL PROTECTED]> wrote: > Hi, > > how is the status of this package manager tool > (http://fdpm.sourceforge.net/): It seems to work now? > > Btw: There should be a big link at FreeDOS homepage I think. I have > seen the great package manager of Debian and DJGPP > (http://homepages.nildram.co.uk/~phekda/richdawe/pakke/) and I think > it is a important tool for every operating system. > > Bye > Flo > -- > Club Dr-DOS Wiki http//www.drdos.org > private page http://www.flox.at.tf > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- Fall is my favorite season in Los Angeles, watching the birds change color and fall from the trees. David Letterman (1947 - ) See ya - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] fdapm update and a new screen saver
Hi again, I updated FDAPM again. Changed since 15jul: IDLEDPMS is now smaller in RAM (< 1/2 kb) and avoids double-loading. If you try to load it twice, you get a message. There is also a tiny change in VBE/PM handling. Of course there are also the old news from 15jul: Fixed the stats used for "CPU was idle for ... of the time" display and added a new tool IDLEDPMS, which is a small (1 kb file) but effective DPMS screen saver. The screen saver detects Windows3 and "games with own keyboard IRQ handler" to avoid "saving" at the wrong time. Enjoy :-). Eric > www.coli.uni-saarland.de/~eric/stuff/soft/fdapm-2007jul17.zip > PS: You cannot change the timeout or unload idledpms > after you load it, it is too simple for that :-). PPS: If VBE/PM is supported, only VBE/PM is accessed. Otherwise, VGA BIOS function int 10.12/bl=36 is used if VGA, and registers 3c4/5.1 "and d0 or 0/20" and 3d4/5.17 (or 3b4/5.17) MSB are used. EGA install check is int 10.12/bl=10, VGA check is int 10.1a00. VBE/PM interface is int 10.4f10/bl=0 (check) or 1 (set mode bh). - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDAPM / REXX / QBASIC / POWER questions TO users
Hi! 1-Мар-2005 22:42 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-user@lists.sourceforge.net: EA> - POWER can detect "check for key"-flooding and react with freezing the EA> system for some part of every second (usually 3/8-7/8 of it, with flood EA> being defined as usually 285-750 requests per timer tick), does that EA> feel useful? If so, should it be on by default? This seems to be what EA> distinguishes the three ADV depths (min, reg, max) from each other!? When FDAPM used with Volcov Commander udner Windows, seems, it detects idleness. But when there are more VC windows, CPU usage arise to 100% and never fall back (ie. current FDAPM idleness detection is not perfect). --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
