Mail Archives: djgpp-workers/1996/10/07/21:47:13
Eli Zaretskii wrote:
>
> The following small program reports the amount of installed physical RAM
> as known to the CMOS setup.
Thank you very much. I'll try this code forthwith and see how it works
under different environments. :)
> 1) The code reads and writes ports, so NT might not allow it.
> But I'm not sure that NT will at all let you use all of the available
> memory in the DOS box anyway. Charles?
I'll include a warning for NT users. Somebody posted some code on the
newsgroup a little while ago which detects the type of Windows installed
- I may make use of that to warn them that the memory detection may be
invalid under NT. _However_, anybody who runs NT should almost
certainly have enough memory that it shouldn't be a problem in any case.
> 2) The function which reads the CMOS disables NMI and re-enables
> it before exit. I would rather not change the NMI flag, but there is no
> way known to me that you can read that flag. Since reading CMOS involves
> writing to the same register which sets ot resets the NMI flag, I chose
> the least dangerous way of disabling and re-enabling it. Stll, if there
> are machines which run with NMI disabled (laptops?), this code will have
> a side-effect on them. If this is of any concern, you can always tell
> people to reboot after they run djverify.
I'll put a reminder in the documentation for people who use laptops. If
it does cause any problems, it will (hopefully) be seldom enough to
avoid concern.
> 4) The function that forces a delay between `inportb' and
> `outportb' is just a kludge. I wanted to prevent the optimizer from
> messing up with the integer division (which might yield zero) and so
> forced the compiler to go to floating point. But that is a bad idea for
> djverify, since it should run on machines without an FPU and without an
> emulator (if the installation is screwed up). So that code has to be
> changed.
Well, I'm not entirely sure why it's necessary to wait between port
calls in the first place, but is the timing that critical? As I recall,
sleep() works in millisecond increments, right? Actually, another
program I have uses a routine for microsecond timing, using the
functions in <sys/time.h>; I can probably just copy that. Or would
calling gettimeofday() mess up the CMOS access?
--
---------------------------------------------------------------------
| John M. Aldrich, aka Fighteer I | fighteer AT cs DOT com |
| Plan: To find ANYONE willing to | http://www.cs.com/fighteer |
| play Descent 2 on DWANGO! | Tagline: <this space for rent> |
---------------------------------------------------------------------
- Raw text -