Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!altos!gumby!rcollins
From: rcollins@gumby.Altos.COM (Robert Collins)
Newsgroups: comp.os.msdos.programmer
Subject: Re: CMOS read/write & CPU + CPU SPEED tester
Keywords: CMOS, CPU, SPEED
Message-ID: <4959@gumby.Altos.COM>
Date: 26 Jun 91 19:49:35 GMT
References: <824@jt.dk>
Reply-To: rcollins@altos.COM (Robert Collins)
Organization: Altos Computer Systems, San Jose, CA
Lines: 32

In article <824@jt.dk> pingel@jt.dk (Soren Pingel Dalsgaard) writes:
>  Problem 2: Any fool proof method of determining the CPU type would be of
>             great interest. Whether there is a coprocessor or not, should
>             also be tested. By the way: Is it possible to mix CPU type and
>             coprocessor? e.g. 386 + 287 or 286 + 387 etc, or is it enough
>             to test for CPU type and coprocessor, and then the coprocessor
>             will be same type as the CPU?
>


Look in the Intel 486SX Data sheet, appendix B.  It contains the "Intel-
recommended" algorithm for determing CPU type.  Intel doesn't state this
in the algorithm, but it is intended to run in real mode only.  It also
detects the different math coprocessors.  And no, the math coprocessor
doesn't need to be the same as the CPU.  Some early '386's had provisions
for '287's.


>  Problem 3: Testing for CPU speed (in MHz). Norton does this in the sysinfo
>             tool, but can other people do this too? I though of dis-
>             assembling some parts of sysinfo to see the method, and then
>             rewrite a piece of code to do it, but I'd rather not. (copy-
>             rights and the size of the sysinfo file are major reasons)
>


Determing CPU speed is a "trade secret."  There is a totally reliable way
to do it, and Norton doesn't use this method.  Hint:  Look at the resolution
of the counter/timer chip and CPU instructions that don't do any bus access.


R. Collins