Message-ID: <3259DCC3.5BA2@cs.com> Date: Mon, 07 Oct 1996 21:46:59 -0700 From: "John M. Aldrich" Reply-To: fighteer AT cs DOT com Organization: Three pounds of chaos and a pinch of salt MIME-Version: 1.0 To: Eli Zaretskii CC: Charles Sandmann , djgpp-workers AT delorie DOT com Subject: Re: Stub error messages (Was: Re: 'Cannot open') References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 ; 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: | ---------------------------------------------------------------------