jmv@sppy00.UUCP (Jim Vickroy) (08/04/89)
Just recently a friend forwarded to me an assembler routine which identifies the type (i.e. 8086,80286, etc) of microprocessor is present in the machine which the probgram is running. The method was to execute cpu-specific op codes and see if you get to the illegal op-code interrupt handler (which was previously stolen). I was wondering if there was possibly a more reliable way (such that you don't have to have an assembler which generates 286, 386, op-codes? I have been told that there was an artical in PC TechJournal some time ago which explained a different method. Unfortunately I am unable to locate this artical. I did find, however, a Tech Notebook which outlined an algorythm which identified co-processors (Aug '87 - if your interested). Any help would be appreciated. Thanks, jim __ ============================================================================== :::: ::: :: :: : : Jim Vickroy |OC| ||| || || | | Technical Services Department |LC| ||| || || | | Online Computer Library Center, Inc. :::: ::: :: :: : : Dublin, Ohio ------------------------------------------------------------------------------ UUCP: {att|pyramid|killer}!osu-cis!sppy00!jmv domain: jmv@sppy00.uucp USSNAIL: 6565 Frantz Rd., Dublin, Ohio 43017-0702 ------------------------------------------------------------------------------ "Don't it always seem to go; you don't know what you've got 'til it's gone"-jm ==============================================================================
wales@valeria.cs.ucla.edu (Rich Wales) (08/12/89)
I'm posting, rather than e-mailing, this response because it is pre-
sumably of general interest.
In article <490@sppy00.UUCP> jmv@sppy00.UUCP (Jim Vickroy) writes:
Just recently a friend forwarded to me an assembler routine
which identifies the type (i.e. 8086,80286, etc) of micropro-
cessor is present in the machine which the program is running.
The method was to execute cpu-specific op codes and see if you
get to the illegal op-code interrupt handler (which was previ-
ously stolen).
I was wondering if there was possibly a more reliable way (such
that you don't have to have an assembler which generates 286,
386, op-codes?
There is a program called CPUID, available in the SIMTEL20 archive as
PD1:<MSDOS.SYSUTL>CPUID.ASM
This program works by taking advantage of minor differences among the
various CPU's in situations that are "weird", but legal. For example,
as I recall, if you try to do a shift by 33 bits, an 8088 or 8086 will
do it "as is" (and give you an all-zero result), while the 80188/80186
looks only at the low-order 5 bits of the shift (and thus shifts by only
one bit). By doing several undocumented checks of this kind, you can
tell the various CPU's apart without risking illegal op codes.
CPUID can distinguish the 8088, 8086, V20, 80188, 80186, and 286. It
can NOT identify a 386 (it'll mistake it for a 286, I think). I think
CPUID also checks for a coprocessor, but it doesn't tell you want kind
(though you should be able to infer that from the CPU type).
There is another, more recent, program on SIMTEL20, available as
PD1:<MSDOS.SYSUTL>CHIPS.ARC
(This is an ARC archive, as the name implies.) The CHIPS program seems
to do the same kind of tricks as CPUID; in addition, it knows how to
identify a 386, and it'll tell you what kind of coprocessor you have
(if any). It doesn't, however, seem to check for the different kinds
of coprocessors available in a 386 system.
Both of these programs are reasonably short (10-20K bytes).
If you can't get to SIMTEL20 via Internet FTP access, look in recent
net articles for instructions on how to request SIMTEL20 stuff via one
of several e-mail servers. PLEASE DO NOT deluge me with requests for
these programs (or with requests for SIMTEL20 e-mail server info)!!!
-- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683
3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales
"Electricity?!? That hasn't been used in over 400 years, Buck."