• Please review our updated Terms and Rules here

CPU/FPU Detection Program / Routines

M

MMoeller

Experienced Member
Joined
Aug 19, 2011
Messages
70
Hello People,

I present a program to detect the installed CPU/FPU.
The program is written in NASM.

It determines the following CPUs:
- 8086/8088
- 80186
- 80286
- 80386, and so on, up to the newest processor available.

FPU supported:
- 8087
- 80287
- 80387

The Source Code contains the following routines:
IsInWindows - Determines the Operating System under which the program is running:
- True DOS
- Windows (even supports the detection of Windows NT)
- or OS/2 v2.0 or higher

IsInV86 - Determines whether running in Virtual 8086 Mode
GetCPUType - Determines the CPU Type, returns the CPU Family ID, eq. 4 for 80486, and so on. Supports the Family ID Extraction via CPUID (if supported by the CPU)
HasFPU - Checks whether a FPU is installed or not (Returns 0 if not, 1 if exists)
HasCPUID - Checks whether the CPUID routine is supported by the CPU
GetFPUType - Returns the type of FPU installed

The source code is fully commented.

Example Output: 80486, 80387 or newer, CPUID present, in Real Mode, running under True DOS.

It was successful tested on a IBM PS/2 Model 30/286, an older 80486 (without the CPUID Insn) and a newer 80486 (which supports CPUID).
Would someone please test it on a system not listed here ?

Knowns someone a method to check for a 80487 ?

Files:
-----
Source Code
Executable (.com)

With best regards,
Martin
 
Since this is vintage, you may want to add checks for NEC V-series CPUs (V20, V30, V35, V40, V50) as well as alternative FPUs (e.g. Cyrix, Weitek).
 
looks good, and seems to work well. detected my 286, a 386, a real 8088, and worked in my emulator which surprised me. lots of detection programs detect it as a 286 or a 486 (at least PC Pro thinks its a Cyrix 486) when i'm trying to emulate an 80186.
 
V20 detection would be handy, I'm thinking about the XT/IDE BIOS for revised CPLD build.
 
hmm, i wonder what a good way of going about V20 detection would be. maybe try to use the BRKEM opcode to enter 8080 mode and see what it does? or maybe there's a simpler method based on flags results after some operation?
 
I extended the program so that it prints EMS Memory Informations (XMS functionality currently doesn't works), SoundBlaster and Adlib Detection
I will maybe add video card detection, soon.

Files
-----
Source Code
Executable (.com)
 
how are you trying to work with the XMS driver? it is kind of a strange interface to have to work with. you need you check for the presence of a driver by calling interrupt 2Fh with:

AH = 43h
AL = 0

on return, if AL = 80h then there is an XMS driver loaded. anything else, there isn't one. after this comes the interesting stuff. i was a bit confused the first time i tried to interface with XMS. there is another interrupt call you have to make after you determine there is a valid driver in place (int 2Fh, AH=43h, AL=10h), and it returns with the driver entry point in ES:BX.

you have to far jump directly to that address for all XMS function calls rather than using normal INT instructions. i can't remember if you need to push flags, CS, IP for the handler to return properly or simply CS and IP. iirc, flags must be included but not positive.

anyway, to get free XMS memory in KB, call that address with AH = 08h, BL = 0. it will return to you with the amount of total free XMS available in DX, and the largest single block in AX. again, these values are in KB.
 
A new version of the program is available. This version differentiates between the 8086/88/V20/V30/80186/80188. V20/30 Detection support was added.

@Chuck(G), pearce_jj: V20/30 Detection was added
@Mike_Chambers: Thanks for testing dcpu. Would you please check why my XMS code doesn't work ?

V20/V30 Detection was stolen from the CPU/FPU Detection Library (TMi0SDGL).
Would someone please check this new version of dcpu
On my IBM PS/2 Model 30/286 the program hangs, will test why it hangs

To assemble dcpu:
NASM -o dcpu.com dcpu.asm
 
Sorry I missed this, I'll check it out on a V20 in a bit. Is the link on the first post the most updated executable?
 
> Is the link on the first post the most updated executable?
Yes this is always the link to most recent version
 
OK so the output is thus,

"V20, No FPU present, CPUID not present" then 170 characters of nonsense (uninitialised string maybe?) followed by "8086, running under true DOS" where upon it hung with (floppy) drive activitiy light solid.

Tested on Tandy 1400FD laptop (8MHz V20), Tandy MS-DOS 3.3. Same result with CPU at 4.77MHz.

HTH!
 
Last edited:
thanks for the fast testing pearce_jj!!!

Ok, it has at least detected the cpu correctly !!!
That's fine.

The Bug: I used the SMSW (Store Machine Status Word) Instruction, which is not available on your V20.
I will solve the problem, tomorrow.

Good Night !
 
It should be possible to separate many more of the unique variations of 8088 and 8086 CPUs. Some of these bugs were documented by forum member Trixter in a blogpost some years ago, while the remaining ones are taken from forum member Sergey's website. I haven't looked into how many of these bugs are examined in your program, so I just list all I could find by default.
  • Early 8088 CPUs with copyright date of only 1978 will not ignore interrupts during the instruction after a segment registers has been altered. This may not nessecarely be the case for the early 8086 CPUs.
  • 808x CPUs with copyright date of either 1978 or '78 '81 will have another interrupt bug, allowing interrputs to occur for a single cycle after a POPF instruction, even if interrupts are disabled with the CLI flag!
  • Most, if not all of intel's 808x CPUs will store the wrong return address if an interrupt fires of during a segment-overrided REP MOVSx or REP LODSx instruction. This issue was fixed in the 8018x CPUs, and nonexistent in the V20/V30.
  • All 808x CPUs from Intel (and problably most other vendors) will support the POP CS instruction.
  • Harris 80C88 CPUs will disable interrupts for the instruction following PUSH SegmentRegister.
 
Last edited:
I'm still waiting for the detection of V40 and V50 CPUs. Entirely vintage, BTW. And there are others, V25, V33, V53, V35, V25 plus...not to mention the variation of the 80188 and 80186 CPU (i.e. on-chip peripherals or lack of them).
 
You must log in or register to reply here.
Back
Top