DOS ain't dead - INT 15.87 in protected mode

Laaca

Czech republic,
29.08.2011, 14:11

INT 15.87 in protected mode (Developers)

Hi!
I learned how to use int 15h/ax=87h in real mode. Now I am able to draw via LFB even in real mode or I can work with ACPI in real mode.

But I tried to use this interrupt in 32.bit DPMI via call INT 31h/AX=300h
I prepared all needed realmode buffers but when I call the service it fails and in AH is returned 86h what means "Function not supported".

Am I doing something wrong?

Yes I know, under DPMI I should map the needed linear address into new selector and access it through this selector. But I wanted to use the code close to realmode version as much as possible.

---
DOS-u-akbar!

Rugxulo

Usono,
29.08.2011, 23:28
(edited by Rugxulo, 31.08.2011, 01:21)

@ Laaca

INT 15.87 in protected mode

Post reply

> But I tried to use this interrupt in 32.bit DPMI via call INT 31h/AX=300h
> I prepared all needed realmode buffers but when I call the service it fails
> and in AH is returned 86h what means "Function not supported".
>
> Am I doing something wrong?

Presumably this was never meant to work when already in pmode itself as it sets up its own 16-bit crud via BIOS.

http://www.delorie.com/djgpp/doc/rbinter/id/35/15.html

Notes: Copy is done in protected mode with interrupts disabled by the default BIOS handler; many 386 memory managers perform the copy with interrupts enabled.

Who knows, I'm far from pmode savvy. It could depend on what DPMI server you're using, whether running under EMM386, whether it switches back to real mode or V86 mode, etc. Maybe you need a DPMI server (e.g. DPMIone) that can support both 16-bit and 32-bit, I dunno. But personally I doubt it will ever work this way (though that's just a guess ...).

Japheth

Germany (South),
30.08.2011, 05:27

@ Rugxulo

INT 15.87 in protected mode

Post reply

> Presumably this was never meant to work when already in pmode ...
> It could depend on what DPMI server you're using ...
> whether running under EMM386 ...
> whether it switches back to real mode or V86 mode...
> Maybe you need a DPMI server ... that can support both 16-bit and 32-bit...
> I doubt it will ever work this way ...

All these guesses are wrong.

Calling int 15h via DPMI int 31h, ax=0300 "should" always work if it's done correctly. If it does not, it's a bug in the DPMI host.

---
MS-DOS forever!

Rugxulo

Usono,
30.08.2011, 05:37

@ Japheth

INT 15.87 in protected mode

Post reply

> All these guesses are wrong.

Well, I knew that much. But a guess for him to "try again with different tools" is better than no guess at all. (You're the resident expert here, but I just assumed you were too busy.)

> Calling int 15h via DPMI int 31h, ax=0300 "should" always work if it's done
> correctly. If it does not, it's a bug in the DPMI host.

Or a bug in the BIOS. I mean, let's be honest, such things are low priority for them these days.

Laaca

Czech republic,
30.08.2011, 07:22

@ Japheth

INT 15.87 in protected mode

Post reply

> Calling int 15h via DPMI int 31h, ax=0300 "should" always work if it's done
> correctly. If it does not, it's a bug in the DPMI host.

Hm, I tried it with cwsdpmi. Most probably with last version - r7.
I will try it with HDPMI32 too.

---
DOS-u-akbar!

Japheth

Germany (South),
30.08.2011, 08:47

@ Laaca

INT 15.87 in protected mode

Post reply

> Hm, I tried it with cwsdpmi. Most probably with last version - r7.
> I will try it with HDPMI32 too.

cwsdpmi works as well. Why I know this? Because DEBUGX's DX command does exactly what you're trying to do - it calls Int 15h, ah=87h directly in real-mode and indirectly via int 31h, ax=300h in protected-mode. And the DX command works with cwsdpmi, hdpmi, Windows, ...

---
MS-DOS forever!

Rugxulo

Usono,
31.08.2011, 01:30

@ Japheth

INT 15.87 in protected mode

Post reply

> > Hm, I tried it with cwsdpmi. Most probably with last version - r7.
> > I will try it with HDPMI32 too.
>
> cwsdpmi works as well. Why I know this? Because DEBUGX's DX command does
> exactly what you're trying to do - it calls Int 15h, ah=87h directly in
> real-mode and indirectly via int 31h, ax=300h in protected-mode. And the DX
> command works with cwsdpmi, hdpmi, Windows, ...

Okay, it's just confusing, esp. as (obviously) I have little to no experience with the innards of pmode.

It's just hard to understand, esp. when you know CWSDPMI and HDPMI do things differently. And certainly Windows is a whole other ball of wax.

Corrections welcome, this is a guess (not looking it up right now, too busy) ...

int 31h, 300h -> CWSDPMI switches back to real mode
int 31h, 300h -> HDPMI32 switches to V86 mode
int 31h, 300h -> Windows (which?) switches to V86 mode

But does Windows even truly call int 15h? I doubt it. I'm pretty sure it doesn't call the "real" BIOS. I'm pretty sure that most memory managers hide / "eat" int 15h anyways unless you're running raw (which isn't really the best choice, IMHO, to use DPMI).

Laaca

Czech republic,
31.08.2011, 07:33

@ Rugxulo

INT 15.87 in protected mode

Post reply

Today in car I maybe found where could be the problem. When I came home I try to fix it. I am affraid I din't set r.AH:=$87 but r.AX:=$87. I can't check it now because I am at work and will return home only tomorrow afternoon.

---
DOS-u-akbar!

Rugxulo Usono, 31.08.2011, 21:27 @ Laaca	INT 15.87 in protected mode Post reply
	> I learned how to use int 15h/ax=87h in real mode. > > Today in car I maybe found where could be the problem. When I came home I > try to fix it. I am afraid I didn't set r.AH:=$87 but r.AX:=$87. I can't > check it now because I am at work and will return home only tomorrow > afternoon. "AH = 87h" (RBIL) Oops, indeed, how did we not see that? Yeah, that seems like your problem!

Laaca

Czech republic,
02.09.2011, 07:10

@ Rugxulo

INT 15.87 in protected mode

Post reply

> "AH = 87h" (RBIL)
>
> Oops, indeed, how did we not see that? Yeah, that seems like your problem!

Fixed! Now everything works OK. Yes, it was really the problem.

---
DOS-u-akbar!

marcov 02.09.2011, 09:58 @ Laaca	INT 15.87 in protected mode Post reply
	> > "AH = 87h" (RBIL) > > > > Oops, indeed, how did we not see that? Yeah, that seems like your > problem! > > > Fixed! Now everything works OK. Yes, it was really the problem. This reminds me of something else, is there something like STRACE for Dos ? IOW something that dumps all interrupts made and their parameters and success/error status of an running file to a readable text file?

Rugxulo

Usono,
03.09.2011, 21:49
(edited by Rugxulo, 03.09.2011, 22:16)

@ marcov

INT 15.87 in protected mode

Post reply

> This reminds me of something else, is there something like STRACE for Dos
> ?
>
> IOW something that dumps all interrupts made and their parameters and
> success/error status of an running file to a readable text file?

Kinda, but I'm not fully sure. But here's a half-valid answer:

If all you want to do is manually trace low-levels of DOS calls themselves, you can do that via a "resident" debugger (386SWAT, DeGlucker, Insight) or similar (BOCHS? DOSEMU?). Logging to file may?? be possible via DOSEMU or FreeDOS debug kernel, but I'm even less sure as I've never tried.

There are other external utils (usually TSRs) that log "some" interrupts, but I'm not sure how much, many, whether they report register values (doubtful), full filenames (or LFNs), etc. Don't get your hopes up, most are old and incomplete (but better than nothing). The only one I've truly used more than once is KGB, and it's woefully incomplete (but good for simple fopen/fread/fclose/exec curiosity).

Argus, KGB, TRACE, UI21DEB.

There might be more (most likely), but I dunno offhand.

DOS386

04.09.2011, 12:43

@ Rugxulo

INT 15.87 in protected mode

Post reply

Laaca wrote:

> > "AH = 87h" (RBIL)
> > Oops, indeed, how did we not see that? Yeah, that seems like your problem!
> Fixed! Now everything works OK. Yes, it was really the problem.

COOL (after all the RM-vs-VV86 AKA HDPMI-vs-CWSDPMI discussions) :clap:

Rugxulo wrote:

> I have not heavily studied any DPMI hosts, even CWSDPMI, but you
> have to admit that "temporarily switching from 386 pmode to 8086
> real mode in order to enable 286 pmode via BIOS" sounds a bit odd

You can get access to all 4 GiB RAM on 80386 or better, but only a 64 KiB segment.

> Argus KGB(PAQ-based???) TRACE UI21DEB

:-) Latter sees only INT $21.

Check also: http://board.flatassembler.net/topic.php?t=9738

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
31.08.2011, 10:11

@ Rugxulo

INT 15.87 in protected mode

Post reply

> Okay, it's just confusing, esp. as (obviously) I have little to no
> experience with the innards of pmode.

Why are you making guesses if you have no experience in the matter? To show the OP that somebody cares about his/her issues? I'm aware that Americans have a strong believe in the power of words, but it shouldn't be exaggerated THAT much, IMO. :-D

> int 31h, 300h -> CWSDPMI switches back to real mode
> int 31h, 300h -> HDPMI32 switches to V86 mode
> int 31h, 300h -> Windows (which?) switches to V86 mode

If the DPMI host runs as VCPI client, it will switch "back" to v86-mode ( hopefully using the VCPI API ), because anything else will cause disaster. I don't think that cwsdpmi or hdpmi differ in this regard.

> But does Windows even truly call int 15h? I doubt it. I'm pretty sure it
> doesn't call the "real" BIOS.

A v86-monitor program - and NTVDM is such a type of program, although it runs in non-privileged mode and hence needs the help of the OS for a few tasks - will always emulate int 15h.87h. The memory functions ( int 15h.88h, ... ) are sometimes also intercepted. However, the rest of Int 15h may be called "really".

---
MS-DOS forever!

Rugxulo

Usono,
31.08.2011, 21:25

@ Japheth

INT 15.87 in protected mode

Post reply

> > Okay, it's just confusing, esp. as (obviously) I have little to no
> > experience with the innards of pmode.
>
> Why are you making guesses if you have no experience in the matter? To show
> the OP that somebody cares about his/her issues? I'm aware that Americans
> have a strong believe in the power of words, but it shouldn't be
> exaggerated THAT much, IMO. :-D

Could I guarantee the OP access to the almighty Japheth? I'm not being sarcastic here, you're clearly the resident genius on the topic. But lacking any easy access to you, since you're always busy it seems, I gave it a (wimpy) guess of my own. Completely wrong, okay, oops, but I tried.

I just hate when somebody has a problem and nobody seems to care to even try to help.

> > int 31h, 300h -> CWSDPMI switches back to real mode
> > int 31h, 300h -> HDPMI32 switches to V86 mode
> > int 31h, 300h -> Windows (which?) switches to V86 mode
>
> If the DPMI host runs as VCPI client, it will switch "back" to v86-mode (
> hopefully using the VCPI API ), because anything else will cause disaster.
> I don't think that cwsdpmi or hdpmi differ in this regard.

I don't know the details. I got the impression that, overall, switching to V86 mode is preferable for speed and other reasons. But, IIRC, CWSDPMI doesn't do that in all cases, and usually only switches to real mode. Since V86 is a submode of pmode, I wasn't sure if the 16-bit low-level bullcrap was incompatible with the 32-bit (GDT, LDT, etc), hence I wasn't sure if it was even supposed to work, well-tested, or whether the DPMI host should have 16-bit support (which CWSDPMI lacks) or DPMI 1.0 (as that's needed to mix 16-bit and 32-bit DPMI clients).

> > But does Windows even truly call int 15h? I doubt it. I'm pretty sure it
> > doesn't call the "real" BIOS.
>
> A v86-monitor program - and NTVDM is such a type of program, although it
> runs in non-privileged mode and hence needs the help of the OS for a few
> tasks - will always emulate int 15h.87h. The memory functions ( int
> 15h.88h, ... ) are sometimes also intercepted. However, the rest of Int 15h
> may be called "really".

Well, there's a big difference from "works under Windows" vs. "works under raw BIOS". If they behave the same, it's mostly coincidence.

I have not heavily studied any DPMI hosts, even CWSDPMI, but you have to admit that "temporarily switching from 386 pmode to 8086 real mode in order to enable 286 pmode via BIOS" sounds a bit odd.

ecm

Düsseldorf, Germany,
01.09.2011, 02:17

@ Rugxulo

INT 15.87 in protected mode

Post reply

> > If the DPMI host runs as VCPI client, it will switch "back" to v86-mode
> > (hopefully using the VCPI API ), because anything else will cause
> > disaster. I don't think that cwsdpmi or hdpmi differ in this regard.
>
> I don't know the details. I got the impression that, overall, switching to
> V86 mode is preferable for speed and other reasons. But, IIRC, CWSDPMI
> doesn't do that in all cases, and usually only switches to real mode.

No, that's not possible. As Japheth pointed out, a DPMI host running as VCPI client needs to switch to V86, it mustn't switch to RM instead. (A DPMI host running stand-alone (from RM and without VCPI) could switch either to RM or to V86, but in the latter case it would need to set up and manage the V86 environment itself.)

---
l

Rugxulo

Usono,
01.09.2011, 04:31

@ ecm

INT 15.87 in protected mode

Post reply

> No, that's not possible. As Japheth pointed out, a DPMI host running as
> VCPI client needs to switch to V86, it mustn't switch to RM instead. (A
> DPMI host running stand-alone (from RM and without VCPI) could switch
> either to RM or to V86, but in the latter case it would need to set up and
> manage the V86 environment itself.)

Right, which I meant CWSDPMI does not do (for whatever reason). I don't know how others fare, e.g. HDPMI32.

(old post on comp.os.msdos.djgpp, 05 Jun 1997):

>>> (Eric Lange): I noticed in the DPMI 0.9 spec that this is
>>> only an OPTION for DPMI servers, but they can also run in real mode.
>
>> (Charles Sandmann): CWSDPMI actually does BOTH. If you are running
>> under HIMEM (or bare) CWSDPMI will leave the machine in real mode when
>> running DOS (since I didn't want to bother writing a V86 monitor). If
>> you are running under an EMM, CWSDPMI uses the V86 provided.

Also, Prashant's pmode overview site says this (feel free to disagree):

> ... the time taken by the CPU to switch from protected mode to real
> mode is considerable and greatly slows down the program. By running the
> program in V86 mode, the program is actually executed faster.

Rugxulo

Usono,
01.09.2011, 05:00

@ Rugxulo

INT 15.87 in protected mode

Post reply

> Right, which I meant CWSDPMI does not do (for whatever reason). I don't
> know how others fare, e.g. HDPMI32.

(another interesting old post from comp.os.msdos.djgpp, 02 March 1999):

>>> (John S. Fine): I never had that good an understanding of the
>>> boundaries between the extender and the DPMI server and the
>>> memory manager. If you run CWSDPMI without EMM386, then CWSDPMI
>>> is responsible for things that otherwise EMM386 would handle.
>>> I think you are saying that CWSDPMI, then uses true real mode for
>>> DOS calls, rather than using V86 mode. I think using true real mode
>>> is a bad design for many reasons, but if CWSDPMI actually works
>>> that way, then I certainly understand why having both real mode
>>> and pmode hooks for an interrupt would be needed for *best*
>>> performance.
>>>
>>> If CWSDPMI really uses real mode that way, and I was seting up a
>>> system to service 20Hz interrupts in djgpp, I think I would make
>>> sure QEMM or EMM386 or something was loaded first. Those certainly
>>> have their own overhead, but I think the problems in either servicing
>>> the interrupts in real mode, or reflecting them to pmode, would
>>> outweigh that overhead.

>> (Eli Z.): You didn't expect a 20K program written by an engineer on
>> his free time to include a memory manager and a V86 monitor, did you?

> (John S. Fine): Someday I ought to take the time to look at that
> source code (I assume it is available somewhere). It must be able
> to handle various reflections of interrupts. Having written a
> few V86 monitors myself, I would think that reflecting
> interrupts in a pmode/V86 design is enough easier than in a
> pmode/real design to cover the entire effort of the V86
> monitor (especially if V86 runs with IOPL 3, which is certianly
> no less protected than real mode).

RayeR

CZ,
07.09.2011, 10:28

@ Laaca

INT 15.87 in protected mode

Post reply

> Hi!
> I learned how to use int 15h/ax=87h in real mode. Now I am able to draw via
> LFB even in real mode or I can work with ACPI in real mode.
>
> But I tried to use this interrupt in 32.bit DPMI via call INT 31h/AX=300h
> I prepared all needed realmode buffers but when I call the service it fails
> and in AH is returned 86h what means "Function not supported".

What you are going to do with this func in pmode? I can't see an advantage of calling it for LFB acces as it is limited to 64kB so you will have to call it more times like when bank-switching so I guess it will impact the speed. Well for accessing MMIO with small areas of memory it would be OK.
How does this function works under NTVDM? I doubt that Bill allows access to full RAM this way.

BTW when I was mailing with C.Sandmann about memory mapping he told me they (together with ID software) was negotiating suport for phys memory mapping under NTVDM to allow run Quake game under WinNT but M$ did not accepted it mostly for a reason that NT is not a gaming platform and didn't implemented it :(

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
07.09.2011, 12:28

@ RayeR

INT 15.87 in protected mode

Post reply

I don't want to use it for LFB of course. But it is OK for ACPI handling. I want to share as much code as possible between realmode and protected mode versions of my programs/libraries.

---
DOS-u-akbar!

RayeR

CZ,
07.09.2011, 21:05

@ Laaca

INT 15.87 in protected mode

Post reply

> I don't want to use it for LFB of course. But it is OK for ACPI handling. I
> want to share as much code as possible between realmode and protected mode
> versions of my programs/libraries.

OK, and what do you plan with ACPI? :) I can read root tables and will look what's interesting inside but no time for coding... :(

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
08.09.2011, 07:33

@ RayeR

INT 15.87 in protected mode

Post reply

> OK, and what do you plan with ACPI? :) I can read root tables and will look
> what's interesting inside but no time for coding... :(

For start I plan to write a small utility which turns my notebook off.
I have the HP Pavilion dv6, it has no APM support (only ACPI) and FDAPM from FreeDOS, althouhg it has some limited support for ACPI, is not able to turn it off.

---
DOS-u-akbar!

bretjohn

Rio Rancho, NM,
08.09.2011, 18:19

@ Laaca

INT 15.87 in protected mode

Post reply

> For start I plan to write a small utility which turns my notebook off.
> I have the HP Pavilion dv6, it has no APM support (only ACPI) and FDAPM
> from FreeDOS, althouhg it has some limited support for ACPI, is not able to
> turn it off.

I have a similar situation to yours, a laptop (in my case, a Sony) that has ACPI but not APM. If you're interested, I have an unreleased program I started to write a couple of years ago called SLOWACPI. I intended the program as an "adjunct" to my SLOWDOWN program, planning to eventually integrate the CPU Duty Cycle/Throttling capability directly into SLOWDOWN. This is similar to the THROTTLE program or what FDAPM does with its SpeedN options, but SLOWACPI doesn't do the APM energy management stuff that FDAPM does -- it just manipulates the CPU duty cycle to slow the computer down, or completely shuts off the computer. SLOWACPI is able to shut off my Sony Laptop, so it might work on your HP as well.

If you want, I'll privately send you the program and source code to try out. It's not yet ready for a public release, but may be help you with your immediate goals.

Laaca

Czech republic,
08.09.2011, 22:39

@ bretjohn

INT 15.87 in protected mode

Post reply

Could you, Bret, provide a patch for FDAPM for this ability?
I cannot do it myself as I don't like C what FDAPM is written in.

(I hope that Eric Auer is reading this converstion as a lurker :-) )

---
DOS-u-akbar!

Rugxulo Usono, 08.09.2011, 22:50 @ Laaca	INT 15.87 in protected mode Post reply
	> Could you, Bret, provide a patch for FDAPM for this ability? > I cannot do it myself as I don't like C what FDAPM is written in. It's actually written in assembly, or did you mean you wish it was written in C?

RayeR

CZ,
08.09.2011, 22:27

@ Laaca

INT 15.87 in protected mode

Post reply

> For start I plan to write a small utility which turns my notebook off.
> I have the HP Pavilion dv6, it has no APM support (only ACPI) and FDAPM
> from FreeDOS, althouhg it has some limited support for ACPI, is not able to
> turn it off.

Good luck. I guess it may not be easy task - would be required interpretation of ACPI AML? I don't know but I'm interested. In my case the interest leading me to ACPI was that I cannot determine real number of CPU cores and from what I read it's needed to parse some ACPI tables to get this info. CPUID is useless in this way because it reports some maximum of cores for whole family not specific CPU. Intel can disable some cores and sell it for lower price but CPUID data is not updated...

---
DOS gives me freedom to unlimited HW access.

bretjohn

Rio Rancho, NM,
09.09.2011, 00:31

@ RayeR

INT 15.87 in protected mode

Post reply

> Good luck. I guess it may not be easy task - would be required
> interpretation of ACPI AML? I don't know but I'm interested. In my case the
> interest leading me to ACPI was that I cannot determine real number of CPU
> cores and from what I read it's needed to parse some ACPI tables to get
> this info. CPUID is useless in this way because it reports some maximum of
> cores for whole family not specific CPU. Intel can disable some cores and
> sell it for lower price but CPUID data is not updated...

There are two "parts" to ACPI. Part of it is stored in fixed-format tables, and part of it is more "free-form" (this includes the AML part). Nothing in ACPI is trivial, but the fixed-format part is not too difficult to wade through. The details on how to change the CPU duty cycle and how to shut down the computer are in the fixed-format part.

The "free-form" part is another matter altogether. AML in particular is EXTREMELY nasty. Unfortunately, determining the number of CPU's must be done by parsing the free-form part, though it is not AML, so I think it could be done without too much difficulty (famous last words, since I've never actually done it). It's definitely not as easy as figuring out how to shut down the computer.

The other thing to keep in mind is that at least some computers store bogus information in ACPI, so you can't necessarily believe what it tells you.

RayeR

CZ,
09.09.2011, 01:51
(edited by RayeR, 09.09.2011, 02:17)

@ bretjohn

INT 15.87 in protected mode

Post reply

> There are two "parts" to ACPI. Part of it is stored in fixed-format
> tables, and part of it is more "free-form" (this includes the AML part).
> Nothing in ACPI is trivial, but the fixed-format part is not too difficult
> to wade through. The details on how to change the CPU duty cycle and how
> to shut down the computer are in the fixed-format part.

Well, could you tell me e.g. what can I read from fixed tables about modifying CPU duty cycle? How ACPI describe it? Will I read some IO port address or memory address and description what data to write in? I though that you have to run AML code for that but if not then it would be easier...

> The "free-form" part is another matter altogether. AML in particular is
> EXTREMELY nasty. Unfortunately, determining the number of CPU's must be
> done by parsing the free-form part, though it is not AML, so I think it
> could be done without too much difficulty (famous last words, since I've
> never actually done it).

I'll see. ACPI spec has many many pages... :P

> It's definitely not as easy as figuring out how to shut down the computer.

Some years ago I made an utility that can shutdown PC in a hard way by programming some PCI registers of ICH via SMBus. It's quite simle:
#define SMB_ICH_SLAVE 0x44 // 1000100 - ICH SMB Slave port #define ICH_SLAVE_CMD_REG 0 // reg. 0 - Command Register #define ICH_SLAVE_WAKEUP_CMD 1 // 0x01 - WakeUp if is in sleep state #define ICH_SLAVE_PWRDOWN_CMD 2 // 0x02 - Unconditional Powerdown #define ICH_SLAVE_HWRESET_CMD 3 // 0x03 - Hardware Reset without power off/on #define ICH_SLAVE_HWRESETOFFON_CMD 4 // 0x04 - Hardware Reset with power off/on #define ICH_SLAVE_WDRELOAD_CMD 6 // 0x06 - WatchDog timer Reload smb_write8(SMB_ICH_SLAVE,cmd,ICH_SLAVE_CMD_REG);

http://rayer.ic.cz/programm/pwrdown.exe

> The other thing to keep in mind is that at least some computers store bogus
> information in ACPI, so you can't necessarily believe what it tells you.

Yes, also windows and linux denied to use ACPI on some old PC but I belive it's clean now.

---
DOS gives me freedom to unlimited HW access.

bretjohn

Rio Rancho, NM,
09.09.2011, 20:09

@ RayeR

INT 15.87 in protected mode

Post reply

> Well, could you tell me e.g. what can I read from fixed tables about
> modifying CPU duty cycle? How ACPI describe it? Will I read some IO port
> address or memory address and description what data to write in? I though
> that you have to run AML code for that but if not then it would be
> easier...

Well, I reviewed some of my code again (it's been a long time since I worked on the program), and I mis-spoke. In both cases (shutting down and changing the duty cycle), only half of what you need is in the fixed-format part, and the other half is in the free-form part. Bad memory on my part -- sorry about that.

I'll still privately send you the code and the program if you want it. I think you could modify it to determine the number of CPU's without too much difficulty, since it already goes partially into one of the CPU sections to do the duty cycle calculations. You can also look at FDAPM for info on this.

> I'll see. ACPI spec has many many pages... :P

Indeed it does. It's actually a really ugly spec -- very difficult to understand, even more difficult to implement.

> Yes, also windows and linux denied to use ACPI on some old PC but I belive
> it's clean now.

I would be really surprised if all modern computers are all perfectly "clean", but they may be better than they were. I find modern hardware generally less compliant with standards than older hardware, not more compliant (especially in the USB world).

bretjohn Rio Rancho, NM, 09.09.2011, 23:17 @ RayeR	INT 15.87 in protected mode Post reply
	I was just going through some of my documentation, and I think maybe SMBIOS might be an easier & more informative way to determine the number of CPU's & Cores than ACPI. I've never messed with SMBIOS directly, but the interface is similar in some respects to ACPI. SMBIOS is definitely MUCH more straightforward than ACPI.