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
