• Please review our updated Terms and Rules here

CPU/FPU Detection Program / Routines

Plantronics

Code:
;*	Search_Env - Search for an environment variable.
;	------------------------------------------------
;
;	On entry - (es) = PSP segment
;		   (ds:bx) = search string, terminated by '=',0
;
;	Returns -  (es:di) = first character of value if carry clear.
;		   if carry set, no such variable was found.
;

Search_Env	proc	near public
	push	es
	mov	si,bx
	mov	ax,word ptr es:[02ch]		; get param paragraph
	mov	es,ax
	xor	di,di				; es:0 is search start
	cld
Search_Env2:
	xor	bx,bx
	test	byte ptr es:[di],-1
	jnz	Search_Env4			; if need to keep on searching

;	There was no  variable, return failure.

	pop	es
	stc
	ret					; exit...

Search_Env4:
	mov	al,es:[di]			; get a character of search string
	inc	di
	test	al,al
	jz	Search_Env2			; if at end of source string
	call	ToUpper
	cmp	al,[bx+si]			; see if match here
	jne	Search_Env6			; if not
	inc	bx
	test	byte ptr [bx+si],-1
	jnz	Search_Env4			; keep looping
	pop	ax				; clear stack
	clc
	ret					; exit, success

;	No hit here, go to next string.

Search_Env6:
	xor	al,al
	mov	cx,-1
	repne scasb				; scan past the 00 byte terminator
	jmp	Search_Env2			; look at next string
Search_Env    endp

ToUpper simply converts the value in (AL) to uppercase.
 
Last edited:
The problematic thing is that the Plantronics compatibility mode in the Paridise EGA card uses Port 03DDH ('Plantronics Mode Register').
Does the original Plantronics ColorPlus card also has this register ?

And if yes, this register is write-only. So i could not use is to make a read/write-test (e.g. toggle some bits and check whether they changed).
 
I solved the problem with the detection of the AT&T 6300/Olivetti PC by using function 0FEH of interrupt 01AH.
This function is only present on this computers.

Again, are the Olivetti PC/AT&T 6300 the same ?
 
I'm not certain what Olivetti calls the PC; Olivetti's efforts were rather diffuse in the early 80s.

The AT&T PC6300 and the Olivetti M24 are the same machine under the covers. I don't know, however how the AT&T PC 6300 WGS bears any similarity to a given Olivetti model.

As far as my memory can recall, yes the original Plantronics has 3DD. In fact, it seems that one could write to 3DD to enable or disable the 16-color mode and then check for extra RAM present.

If you haven't seen this, check out the other weird color implementations
 
I will drop support for these cards, because:
1. They should simply be detected as CGA cards
2. There is no easy way to detect them
3. Making a mode change for detection purpose doesn't come into question.

I recheckted the code for TIGA detection, and i saw that I also need the sscanf function, to detect these cards successful.
Maybe i need to convert the code to Microsoft Makro Assembler or Turbo Assembler to successfully detect these cards.

With regards,
Martin
 
I found a bug in dcpu, where the 8086 was detected as 8088, the 80186 as 80188, and maybe the V20 as V30. The problem was solved.

The program was successfully tested with pce http://www.hampa.ch/pce/ with all possible video/cpu configurations.
@Chuck, this emulator also contains a emulation for the Plantronics ColorPlus, this is detected as CGA as expected.

Check it out, NOW !!!!
 
I will drop support for these cards, because:
1. They should simply be detected as CGA cards
2. There is no easy way to detect them
3. Making a mode change for detection purpose doesn't come into question.

I recheckted the code for TIGA detection, and i saw that I also need the sscanf function, to detect these cards successful.
Maybe i need to convert the code to Microsoft Makro Assembler or Turbo Assembler to successfully detect these cards.

With regards,
Martin

sscanf is a C function, i don't see how switching assemblers is going to do anything for you unless you are implying you would link in a C routine. just write something equivalent to it in asm.



I found a bug in dcpu, where the 8086 was detected as 8088, the 80186 as 80188, and maybe the V20 as V30. The problem was solved.

The program was successfully tested with pce http://www.hampa.ch/pce/ with all possible video/cpu configurations.
@Chuck, this emulator also contains a emulation for the Plantronics ColorPlus, this is detected as CGA as expected.

Check it out, NOW !!!!

i wouldn't rely too heavily on results in an emulator. their implementation of hardware is often not exactly the same as the real thing.
 
If you're trying to determine the presence or absence of a TIGA card by already-installed drivers, that would seem at the very least to be a cheat.

It would seem that checking for a TMS340 chip would be the best way to go, as the system may have no drivers for the card installed.

That's why the environment functions and the need for sscanf() have me puzzled.
 
I thought about using Makro Assembler or Turbo Assembler together with C.

@Chuck: I don't know how to detect/checking for an TMS340 Chip. I searched the whole internet using google and couldn't find anything, i need help.

Martin
 
BTW I tried dcpu in an XT with FPU, and it picked up the FPU just fine.

In a Pentium class machine it picked up Pentium OK and then said 387 or newer, but I don't think there ever was a Pentium without an internal FPU so, being very pedantic, perhaps it should just say integrated FPU for Pentium class?

HTH!
 
@Chuck: I don't know how to detect/checking for an TMS340 Chip. I searched the whole internet using google and couldn't find anything, i need help.

Start with the datasheet--it's definitely online. Then all you need to do is find the reference design from TI. It's a pretty safe bet that most vendors followed their specs.
 
@pearce_jj: Does it also correctly identified the CPU ? Please use the newest version. As stated in a previous post, i corrected a bug where a 8086 was detected as 8088, a 186 as 188 and vice versa. I currently work on a version which prints the Computer Class (e.g. PC, PC/XT, PC/AT) and the Computer Model. The code for detecting the class is done, but was not published.
 
Yes it detected the 8088 as 8086 as you'd noted, hence I didn't comment on it. Will check the latest version later!
 
Quick update. On IBM 5160 with MDA and 256K (and an XT-IDE at D0000) the utility correctly detects 8088/8087 and true DOS, then hangs. Running in a cmd window on XP, Windows traps "the video device failed to initialise full screen mode".

Since neither of these happened in the earlier version (with 8088/8086 detection bug) perhaps they are related?
 
first: thanks for testing dcpu (i need a better name for it). I tried it with pce (an PC, PC/XT Emulator) using an 8088, MDA and 256 K, as you described your PC, and it worked without problems. I don't know why it doesn't work on a real XT. That's a real problem, since this tool has the goal to work on every Computer running DOS. So, I can't reproduce the bug. If you have some assembler knowledge, and some time, .... Here on Windows Vista (on which i develop dcpu), the NTVDM doesn't assert this error ('the video device failed to initialise full screen mode'). But it switches automatically to fullscreen, deletes all previous messages, and only prints the type of video subsystem.
This should be a bug in XP, solved in Vista. The program runs fine on DOSBox, it doesn't automatically switch to fullscreen, nor does it in Windows 95. There's no reason to switch to fullscreen, since i don't use a video mode switching function.

I first thought that the 8088 maybe hasn't the DIV BX instruction, but this isn't the case, since ISA of the 8088 is the same the one used in the 8086.

I don't think that it has something to do with the solving of the 8086/8088 detection bug (I'm absolutely sure).

With regards,
Martin
 
BTW the hang (or reset) occurs before it prints RAM or video type (I think - will double check later). The machine has 256KB only - hence just wanted to mention, in case that is significant.
 
I was just looking through the code but can't see any graphics detection at all... what am I missing?
 
Back
Top