Re: [Freedos-devel] Booting and FDAPM

[Bret Johnson]

> ...
> By no means is VINFO perfect. In fact, there is a known issue in
> detecting some 486 based machines that I have not got around to
> fixing. Also, there some other things that could be done better.
> But, they are mostly minor issues that I have not found the time or
> motivation to remedy. Generally speaking, it is good enough for what
> it does and is under 3k when UPX compressed. 

Totally understandable, and I can completely relate to the lack of time and 
motivation.  I've got a LOT of programs I would like to update (some in some 
very major ways) and it's tough to get any of them done.

> ...

> I though I saw ISLOADED somewhere before. But, I just made a quick
> visit to your site and didn't notice it. If I recall correctly,
> the program does a lot of other things as well.

It's not on my web site because I've not yet officially released it.  I sent 
Jim a copy several weeks back which he posted -- that's probably where you saw 
a reference to it.  That was before I added all the VM stuff so it doesn't have 
that anyway, but it has over a hundred different things it can test for.  The 
version I sent to Jim did detect the Windows Virtual Machines (the VMs from 
DOS-based versions of Windows and NTVDM from Windows NT), but not the "modern" 
ones.  I know I've taken a thrashing recently on this forum over calling things 
VMs that some others call "Emulators", and you seem to use the term "Virtual 
Environment".  What Microsoft called Virtual Machines would probably not be 
called VMs by my modern detractors.

>> I also have another program called BATTSAVE which I think is sort
>> of "in-between" what IDELHALT does and what FDAPM does and it may
>> work better than either for the specific problem you're trying to
>> fix.  It's "not ready for prime time" either, but I can send it to
>> anyone who wants it...

> When you say not ready for prime time, why? Compatibility,
> incomplete, documentation, etc?
>
> Just generally speaking, how is it in-between IDLEHALT and FDAPM?

With ISLOADED, there are still a few tests I want to add, and need to do some 
more testing.  E.g., I was having problems with the VMware test where after I 
did the test VMware would start acting funny.  I need to track that down.

With BATTSAVE, there are several different C-states (power-saving states) that 
the CPU can be in.  C0 is the "normal" mode with no power saving.  C1 is 
triggered by the HLT CPU instruction used by IDLEHALT and FDAPM (at least last 
time I looked at it which was a long time ago).  On older CPUs C1 just stops 
the CPU from performing instructions but in 486+ CPUs the HLT instruction also 
disables some of the hardware clocks.  C2 saves even more power than C1 and 
also restarts everything when a hardware interrupt occurs.  C3 and beyond don't 
restart things when an interrupt occurs so probably aren't good for DOS.  There 
are also C-states like C1E and C2E.

Anyway, for BATTSAVE I want to allow C2 as an option to save even more power 
than HLT can do.  But C2 is started through an I/O port instead of a CPU 
instruction and there is no standard I/O port.  I think the only way to 
determine the correct I/O port to use is via ACPI, and if you've ever dealt 
with ACPI you know what a HUGE pain it is.  I've experimented with C2 a little 
bit, but still need to do more.

Also, I suspect that in VMs C2 won't actually do anything useful at all.  This 
is based on the fact that in VMs disabling the cache in the virtual CPU doesn't 
seem to do anything at all (at least on the VMs I've tested).  On real hardware 
disabling the cache has a HUGE effect.  That's actually one of the tests I use 
to detect a "generic" VM in ISLOADED.

For a power saving program to work in DOS it must monitor CPU instructions for 
programs to declare themselves "idle" (either directly or indirectly).  From 
the documentation on IDLEHALT, it only monitors a limited number of CPU 
instructions.  I think BATTSAVE monitors more than IDLEHALT, and FDAPM does a 
lot more than BATTSAVE (like interacting with the APM BIOS if there is one).

In addition, I have BATTSAVE right now toggle a character on the screen to 
indicate when it has entered the power saving mode and also indicates which CPU 
instruction caused the "trap".  This is there for testing purposes.  I 
originally thought I would remove this when I actually released the program, 
but kind of like it and think I will probably add some command-line options to 
control the toggling in case the user actually wants to see the operation, and 
maybe even a hot-key so the user can control the screen toggling in "real-time".

Neither program has currently any documentation other than the comments in the 
source code.

> Regardless, both programs sound interesting. When you feel they are
> ready for more public use/testing, it might be nice for them to get
> wrapped in a package and put on the download repo. Possibly, included
> on one of the release media as well. But, that is a 

Re: [Freedos-devel] watcom, was Re: Booting and FDAPM

[Michael Brutman]

+1 - Open Watcom 1.9 is stable and safe.  I think those factors make it the
default for inclusion in a distribution.

Something actively under development and in between releases sounds like a
bad idea.

On Sat, Mar 18, 2023 at 5:42 AM  wrote:

> Hi Bernd,
>
> > On Mar 17, 2023, at 2:12 PM, Bernd Boeckmann via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
> >
> > IDLEHALT=1 works for my machines and reduces the CPU load under
> VirtualBox to nearly zero at the command prompt.
> >
> >> Am 17.03.2023 um 15:25 schrieb jer...@shidel.net:
> >>
> >> On a side note… Why run the watcom installer at all? Installing the
> FreeDOS WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN
> loaded takes about 1 minute inside VirtualBox. We could most likely just
> provide a WATCOM2C package and avoid the whole issue completely.
> >
> > Yes, was only for testing purposes :-)
> >
> > If v2 is packaged would it be possible to continue shipping the 1.9
> branch in parallel? My impression is that the v2 fork focusses on adding
> new stuff: Linux support, 64-bit and so forth… And from time to time they
> seem to break older stuff. I at least under Win9x encountered some
> regressions.
> >
> > Greetings, Bernd
> >
>
> At present, the RBE is not setup to include 2 branches from the same
> GitLab project.
>
> It would require a separate GitLab project (with a different name, like
> watcomv2). I think having two different watcom C packages could cause user
> confusion on which one to install. It would also take up a lot of space on
> the OS install media. I think it would probably be better to wait for v2 to
> produce a stable release and then upgrade our 1.9 package to v2.
>
> But, I don’t use watcom. So, maybe I’m wrong. Maybe having both would be
> better. Or, possibly include 1.9 with the release and have v2 available on
> the download repo.
>
> :-)
>
> Jerome
>
>
>
>
> ___
> 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

[Freedos-devel] Reminder: FreeDOS virtual get-together tomorrow (Sunday)

[Jim Hall]

Hi everyone! I wanted to remind you that our next FreeDOS virtual
get-together is tomorrow (Sunday) at 11am US/Central for about an
hour. Use your favorite timezone converter to find your local time.
For example:
https://www.worldtimebuddy.com/

We alternate topics every month, and this month the focus is "social
time." We might discuss some technical topics, but mostly this is an
opportunity to chat and get to know each other better.

As always, the get-together will be via BlueJeans - that's what I use
for my consulting practice. I'll share the URL shortly before the
meeting starts. While you can connect using the web version from any
modern browser (BlueJeans recommends Chrome) we've found that you get
the best performance if you download the desktop client from
bluejeans.com

See you tomorrow!


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

[tom ehlert]

Hallo Herr Bret Johnson,

am Donnerstag, 9. März 2023 um 23:27 schrieben Sie:



> The computer I'm currently using is a few years old, old enough
> that I can boot DOS on the actual hardware.  The CPU is an Intel i5-4590 
> running at 3.30 GHz.

> I have a DOS program I wrote a long time ago, called SLOWDOWN (and
> hope to find time to "update" it in the future).  The purpose of
> SLOWDOWN is to slow the computer down so that DOS applications don't
> "blow up" because the computer is too fast.  It's not a perfect
> solution, but is useful in certain situations.

> One of the things SLOWDOWN needs to do is figure out how fast the
> computer is running so that it can slow it down the correct amount
> when you want to do that.  So, SLOWDOWN can sort of be used as a
> "benchmark" to see how fast your computer actually is.

> For my test, I compared how fast my current computer runs (with a
> 3.30 GHz clock speed) against a 33 MHz 386 CPU (which I measured way
> back when -- I don't have access to that computer any more).  At
> least in theory, because my current clock speed is 100 times as fast
> as the 386, my current computer should run _at least_ 100 times as
> fast as the 386 did.  Also, at least in theory, it should be even
> faster than that since the new computer has a cache and the 386
> didn't, modern CPU's take fewer clock cycles per CPU instruction, etc.

> In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the
> 33 MHz 386 did, not more than 100 times like you would expect.

this doesn't make sense AT ALL.
even in your own source,

DB   'º Generic º AMD ³ AM386DX ³   33 ³   334 
º',CR,LF
DB   'º Unknown º Intel   ³ Pentium-3   ³  650 ³  4611 
º',CR,LF
DB   'º Generic º AMD ³ K6-2³  350 ³  4780 
º',CR,LF

you document that an AMD k6-2 350 MHz is 15 times faster then a 33 MHz
386 CPU. And we all KNOW that an Intel i5-4590 running at 3.30 GHz is
faster then AMD K6-2.

for those who want to search themself, search the source for
'WasteLoop'.

it all boils down to some garbage (does nothing sensible) code,
including

  MOV  CX,2   ;Do two bits
  REPE CMPSB  ;Compare the string to itself
  ADD  AL,220 ;Give AL a number
  ADD  AX,3456;Give AX a number
  MOV  BX,DummyVar;BX=address of DummyVar
  MOV  DummyVar,AX;Store it in DummyVar
  SUB  AX,ES:DummyVar ;AX=0
  XLATB   ;AL=[BX+(unsigned)AL]
  SAL  BX,CL  ;Multiply BX by 2, CL times
  MOV  CL,3   ;Divide by 3
  SAR  DummyVar,CL;Signed divide DummyVar by 2, 3 times
  SBB  AX,8   ;Subtract with borrow
  AAM ;ASCII adjust after multiply (AL/10:AH=Quo,AL=Rem)
  DAS ;Decimal adjust after subtraction
  MOV  DX,21h ;Do an
  IN   AL,DX  ;  IN
  POP  CX ;Restore the loop counter
  DEC  CX ;Decrement it
  JZ   WasteExit  ;If it's 0, we're done
  JUMP WasteLoop  ;If it's not, do it all again

looks innocent enough. the problem child is
  IN   AL,DX  ;  IN

and the fact that the 'IN'-bus doesn't run significant faster then it
did in 386's days (there is a reason modern disks are accessed with
(U)DMA, not IN). the speed depends on the chipset and the actual port
address, but is more like 10 MHz then 3 GHz.


> I then ran a second test where I disabled the cache on the CPU (you
> can do this with my CPUCACHE program which is included with
> SLOWDOWN).  This is a more "apples-to-apples" comparison of the
> _actual_ CPU speed than the original test with the cache enabled.

it's not. almost EVERYBODY knows that GHz CPU's just don't make sense
without cache, because it is always waiting for the next instruction
coming from memory. and memory access times are basically unchanged for
the last 30 years at 60-100 ns. so a modern CPU without cache spends
all the time waiting for CPU instructions coming from memory.

> When I did this test, the computer ran almost exactly the same speed
> as the 33 MHz 386 (it was about 3% faster, not 10,000% faster as
> "logic" would dictate).
the is exactly no "logic" in your argument.

> There is something VERY wrong going on
> here.  I suspect you may not believe my results, but they are nonetheless 
> real.







> Let me ask you a few questions.  One of the things I said was that
> the main reason modern CPU's seem so fast is because of "tricks"
> like pipelining and caching,
and read ahead caching, write back buffering, and more

> and you seem to indicate that you don't
> think that is true.
no. that's true.


> Would you even _consider_ running a modern OS
> on a CPU with the cache disabled, when the actual, verifiable data
> shows it would run about the same speed as in the 386 days?
I'm not stupid.

> The next set of questions relate again to what I mentioned
> previously.  What if modern CPU's 

Re: [Freedos-devel] mode.com

[wilhelm . spiegl]

Hi all, 

sometimes trying to write FD help makes me crazy. 

Mode is a typical example. At
https://gitlab.com/FreeDOS/base/mode/-/blob/master/DOC/MODE/MODE.TXT 

there is a big explanation what the original mode.com from 1995 can do
for me. But the last change was in 2015 - and as it looks like a lot of
things were changed without a documentation, among others FD has no park
function. 

If I understand this right, the actual errorlevels should be like this
(found them at modecp.c - hopefully correct?)

MODE has the following ERRORLEVEL / EXITCODES [1]:
  generic:
100:  INTERNAL ERROR: size for prepared table too small
101:  No compatible FreeDOS DISPLAY [2] driver loaded.
  Syntax example: ... DISPLAY [2] CON=(VGA,437,1)
102:  File not found
103:  Error specifying codepage / buffer
104:  Error: selected buffer not present
105:  Syntax error
  check codepage:
26:  Active codepage was never set
27:  Device read codepage error
  prepare codepage:
27:  Codepage was not found in CPI file
29:  Could not get codepage info from file (or XMS troubles)
31:  specified CPI file is damaged (or XMS troubles)
  end prepare codepage:
31:  INTERNAL ERROR: End prepare without Begin prepare
  select codepage:
26:  Specified codepage was not found in file
27:  KEYB failed to change codepage
29:  Device select codepage failed (or XMS troubles)
31:  Device select codepage error

(I think 0 should be added too)

The orignal looks as follows:

Errorlevels returned by MODE are as follows:

0No error
115Serial port does not exist (either for COMn: or LPTn:=COMx)
117No hard disk(s) found to park
118Specified video mode is not supported on this machine
162Insufficient memory (MODE requires about 6K of memory)
241Parameter out of range (e.g. time value, LPT port number etc)
242Cannot have 43-line or 50-line modes with modes other than
CO80
243Unknown baud rate
244Must specify both DELAY= and RATE= for typematic setting
246More than one command or command type was given
255Incorrect usage syntax (all usage syntax errors)

Question: Which are the correct errorlevels?

Your mousepusher

Willi
 

Links:
--
[1]
file:///F:/htmlhelp-110/HTMLhelp-110-english12k/en/hhstndrd/batch/errorlvl.htm
[2]
file:///F:/htmlhelp-110/HTMLhelp-110-english12k/en/hhstndrd/base/display.htm___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] watcom, was Re: Booting and FDAPM

[jerome]

Hi Bernd,

> On Mar 17, 2023, at 2:12 PM, Bernd Boeckmann via Freedos-devel 
>  wrote:
> 
> IDLEHALT=1 works for my machines and reduces the CPU load under VirtualBox to 
> nearly zero at the command prompt.
> 
>> Am 17.03.2023 um 15:25 schrieb jer...@shidel.net:
>> 
>> On a side note… Why run the watcom installer at all? Installing the FreeDOS 
>> WATCOMC 1.9 package through FDIMPLES, even with FDAPM and DOSLFN loaded 
>> takes about 1 minute inside VirtualBox. We could most likely just provide a 
>> WATCOM2C package and avoid the whole issue completely. 
> 
> Yes, was only for testing purposes :-) 
> 
> If v2 is packaged would it be possible to continue shipping the 1.9 branch in 
> parallel? My impression is that the v2 fork focusses on adding new stuff: 
> Linux support, 64-bit and so forth… And from time to time they seem to break 
> older stuff. I at least under Win9x encountered some regressions.
> 
> Greetings, Bernd
> 

At present, the RBE is not setup to include 2 branches from the same GitLab 
project. 

It would require a separate GitLab project (with a different name, like 
watcomv2). I think having two different watcom C packages could cause user 
confusion on which one to install. It would also take up a lot of space on the 
OS install media. I think it would probably be better to wait for v2 to produce 
a stable release and then upgrade our 1.9 package to v2.

But, I don’t use watcom. So, maybe I’m wrong. Maybe having both would be 
better. Or, possibly include 1.9 with the release and have v2 available on the 
download repo.

:-)

Jerome 




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Booting and FDAPM

[jerome]

Hi Bret,

> On Mar 17, 2023, at 9:41 PM, Bret Johnson  wrote:
> 
>> Tom's suggestion of using IDLEHALT is most likely the best solution.
>> 
>> As you suggest, Using IDLEHALT for VM's and FDAPM for real
>> hardware on installed systems will be easy to do.
>> 
>> Since such decisions cannot be made automatically during boot in the
>> CONFIG at present, probably just switch to using IDLEHALT on the
>> LiveCD as well.
> 
> Just a couple of ideas from some things I've been working on.  One is that 
> with my ISLOADED program I can now detect about 25 different specific VMs and 
> also have a set of tests that can detect the presence of a "generic" VM 
> without specifically being able to identify which one it is.  The program is 
> not yet "ready for prime time", but I will send the code and current version 
> of the program to anyone who wants it.  It might come in handy for the 
> FreeDOS install program.

At present, VM detection is performed with VINFO  (part of 
V8Power Tools for DOS). That  testing is very reliable. But, it only tests for 
the (in my opinion) major virtual platforms VMware, VirtualBox, QEMU and 
DOSBox. It also performs a generic VM test in an attempt to catch others. It 
also performs some other tasks related to installation, like CPU, hard drive 
and MBR boot code detection. 

By no means is VINFO perfect. In fact, there is a known issue in detecting some 
486 based machines that I have not got around to fixing. Also, there some other 
things that could be done better. But, they are mostly minor issues that I have 
not found the time or motivation to remedy. Generally speaking, it is “good 
enough” for what it does and is under 3k when UPX compressed. 

Possibly at some point, we may switch to “better” tools to perform the tasks 
required of VINFO. I’m definitely not opposed to switching. After all, I’m lazy 
and that would keep me from needing to eventually improve that utility. But at 
least for time being, I don’t think it would be worth the effort of trying to 
migrate to a different utility for a more nuanced VM detection. 

I though I saw ISLOADED somewhere before. But, I just made a quick visit to 
your site and didn’t notice it. If I recall correctly, the program does a lot 
of other things as well. 

> I also have another program called BATTSAVE which I think is sort of 
> "in-between" what IDELHALT does and what FDAPM does and it may work better 
> than either for the specific problem you're trying to fix.  It's "not ready 
> for prime time" either, but I can send it to anyone who wants it.  I 
> developed it mainly for use when I am traveling and using my laptop and need 
> the battery to last longer when I'm using DOS.

When you say “not ready for prime time”, why? Compatibility, incomplete, 
documentation, etc?
Just generally speaking, how is it “in-between” IDLEHALT and FDAPM? 

Regardless, both programs sound interesting. When you feel they are ready for 
more public use/testing, it might be nice for them to get wrapped in a package 
and put on the download repo. Possibly, included on one of the release media as 
well. But, that is a discussion for another day. :-)

On a completely unrelated and non-FreeDOS related topic…

When I was at your site, I noticed you put your city/state on the page. I’ve 
been out your way twice when the balloon thing was happening. Once in the 
mid-90s, and again a couple years later. Hundreds, if not thousands, of hot air 
balloons in the sky. Flying hamburgers, fork-lifts, animals and stranger 
things. Some not making it and crashing into trees and houses. It was 
definitely a sight to see. They still do that each year?

:-)

Jerome



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