Hi Rugxulo,
I am not sure if the issue can be closed. The problem from my side is:
Is "lh fdapm apmdos" too hard for the fd live CD?
Would a more soft version of power saving be enough?
Willi
Am 2023-03-16 12:25, schrieb Rugxulo:
> Hi,
>
> On Mon, Mar 13, 2023 at 4:26 AM Wilhelm Spiegl <wilhelm.spi...@mail.com>
> wrote:
>
>> after several tests I found the reason for this strange behaviour.
>> It disappeared when I booted from a virtual diskette without fdconfig /
>> fdauto.bat and executed watcom.exe. Same from HD.
>> Then I added fdconfig again - it was still fast.
>> Finally I found out that line (in about 62) caused be brake.
>> "lh fdapm apmdos"
>> This command appears three times in the autoexec.bat (lines 40, 62, 76,
>> maybe it varies a little) and is used there depending on the machine types.
>> Putting the command "lh fdapm apmdos" to "rem" made the watcom.exe
>> installation file work as it should.
>>
>> I asked Eric Auer, he recommended tests without "lh" - or replacing apmdos
>> by the softer "fdapm ADV:REG" but this gave the same slow
>> speed I had before.
>>
>> So I wonder if it is really necessary to install energy saving in FreeDOS
>> live CD, or, at least to check where
>> the machine runs (bare metal or vm which needs more engergy at all).
>
> IIRC, there's also a FDCONFIG setting of IDLEHALT which can already
> help somewhat. Outside of applications which constantly poll, it
> should reduce (virtual) cpu usage to less than maximum.
>
> Anyways, I just now booted up old QEMU 6.1.0 (64-bit) atop dead Win7
> and used MetaDOS 0.7 (kernel 2041, 128 MB RAM, half of that is RAM
> drive) with old curl 7.64.1 to grab the relevant OW 2.0-c installer
> .EXE (which uses Causeway). Grabbing 140 MB with Curl took me five
> minutes. Installing a not-quite-full DOS toolset (roughly 33 MB) took
> two minutes. This was atop a virtual hard disk (FAT16) of 510 MB, no
> VT-X needed!
>
> NASM 0.98.39 (16-bit) built and worked okay, so did MiniSed, so did
> p2c. What didn't work was compiling TinyAsm (for some unknown reason,
> probably a bug).
>
> So I guess this issue can be closed. (Further testing results are
> still welcome.)
>
> _______________________________________________
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
