Identifying various IBM machines for RBIL
Matthias Paul
I am currently in the process to collect machine IDs
for the next issue of Ralf Brown's Interrupt List
(http://www.pobox.com/~ralf/files.html).
Having a collection of identification bytes and strings
(BIOS version etc.) is interesting in itself to see what
is (or was) actually "out there", and it can also help in
tracking down bugs or working around problems found on some
particular systems.
Lurking around here for a while, I think some of you PS/2
fans would be able to come up with many more ID bytes for
original IBM and OEM machines not yet included in RBIL61.
Of course, I am also interested in missing IDs for other
IBM PC, XT, or AT class machines (in particular those old
"incompatible clones"), as well as any other brand name
clones, laptops, palmtops, industrial systems, etc.
So, I would like to ask you to spend a few minutes to read
out the IDs on your own machines and check if they and the
BIOS dates are already in the list. If they are not, I would
very much appreciate your report, either here, or in private
mail. Alternatively, you can also report this directly to Ralf.
The model byte is usually located at F000h:FFFEh and the BIOS
date at F000h:FFF5h. It's trivial to read out with DEBUG.
However, most machines since ca. 1985/1986 should support
INT 15h/AH=C0h, which will give much more detailed information,
including sub-model and revision bytes. If you have a system
info tool, you can use this to retrieve these values. For MSD,
it may look similar to:
+------------------ Computer -------------------+
¦ Computer Name: Award ¦
¦ BIOS Manufacturer: Award ¦
¦ BIOS Version: Award Modular BIOS v4.51PG ¦
¦ BIOS Category: IBM PC/AT ¦
¦ BIOS ID Bytes: FC 01 00 ¦
¦ BIOS Date: 04/28/99 ¦
¦ Processor: ??? ¦
¦ Bus Type: ISA/AT/Classic Bus ¦
+-----------------------------------------------¦
If you only have DEBUG, the following may do as well:
--- GETID.DEB (the blank line is important!) ---
A 100
mov ax,3515
int 21
mov ax,es
or ax,bx
jz 100
mov ax,es
and ax,bx
inc ax
je 100
mov ah,C0
int 15
push es
pop ds
mov si,bx
push cs
pop es
mov di,200
mov cx,30
cld
rep movsw
mov ax,F000
push ax
pop ds
mov si,FFE0
mov cx,10
rep movsw
P=100 1A
D CS:200
Q
Q
---------
Copy this script into a text file named GETID.DEB and at the
plain DOS prompt run DEBUG as follows:
DEBUG < GETID.DEB > GETID.TXT
The resulting GETID.TXT file contains a dump of the first 96 bytes
of the data structure returned by INT 15h/AH=C0h and pointed to by
ES:BX, as well as the last 32 bytes of the ROM. Together with the
exact name of the machine this is all that's needed to derive the
necessary info from.
Here is the model byte ID table (Table 00515 in RBIL61 with
some changes, additions, and reformattings for this post):
Values for model/submodel/revision:
Model Submdl Rev BIOS date System
(mm/dd/yy)
FFh [1] [1] 04/24/81 PC (original "PC1")
FFh [1] [1] 10/19/81 PC (some bugfixes)
FFh [1] [1] 10/27/82 PC (HD, 640KB, EGA support)
FFh 00h rev ??? Tandy 1000SL
FFh 01h rev ??? Tandy 1000TL
FFh 46h [3] ??? Olivetti M15
FEh [1] [1] 08/16/82 PC XT ("XT1")
FEh [1] [1] 11/08/82 PC XT and Portable PC
FEh [1] [1] ../..x.. Toshiba laptops up to ~1987
("x"=product ID) (see #00521)
FEh 00h [1,3] ??? Olivetti M19
FEh 43h [3] ??? Olivetti M240
FEh A6h ??? ??? Quadram Quad386
FDh [1] [1] 06/01/83 PC Junior ("PCjr")
FCh [1] [1] 01/10/84 AT models 068,099 6MHz 20MB("AT1")
FCh [1] [1] 02/25/93 Linux DOSEMU (all versions)
FCh 00h 00h ??? PC3270/AT
FCh 00h 01h 06/10/85 AT model 239, 6 MHz 30MB ("AT2")
FCh 00h > 01h ??? 7531/2 Industrial AT
FCh 01h ??? ??? int. rel. "AT3" (before 1985-11-15)
FCh 01h 00h 11/15/85 AT mdls 319,339 8 MHz,Enh.keyb.,3.5"
FCh 01h ??? ??? ("AT4" models after 1985-11-11)
FCh 01h 00h 09/17/87 Tandy 3000
FCh 01h 00h ../..x.. Toshiba laptops since ~1988
("x"=product ID) (see #00521)
FCh 01h 00h 03/08/93 Compaq DESKPRO/i
FCh 01h 00h various Compaq DESKPRO, SystemPro,ProSignia
FCh 01h 00h 07/20/93 Zenith Z-Lite 425L
FCh 01h 00h 04/09/90 AMI BIOS
FCh 01h 20h 06/10/92 AST
FCh 01h 30h ??? Tandy 3000NL
FCh 01h ??? ??? Compaq 286/386
FCh 02h 00h 04/21/86 PC XT-286
FCh 02h 00h various Compaq LTE Lite
FCh 02h 00h 08/05/93 Compaq Contura 486/486c/486cx
FCh 02h 00h 08/11/88 SoftWindows 1.0.1 (Power Macintosh)
FCh 04h 00h 02/13/87 PS/2 Model 50 (10 MHz/1 ws. 286)
FCh 04h 01h 05/09/87 PS/2 Model 50 (10Mhz 286,HDD-type32)
FCh 04h 02h ??? PS/2 Model 50
FCh 04h 02h 01/28/88 PS/2 Model 50Z (10Mhz286,HDD-type33)
FCh 04h 03h 04/18/88 PS/2 Model 50Z (10 MHz/0 waitst.286)
FCh 04h 04h ??? PS/2 Model 50Z
FCh 05h 00h 02/13/87 PS/2 Model 60 (10 MHz 286)
FCh 06h ??? (11/15/85) IBM "AT4" (1985-11-15 or later)
FCh 06h 00h ??? IBM 7552-140 "Gearbox"
FCh 06h 01h ??? IBM 7552-540 "Gearbox"
FCh 08h [3] ??? Epson, unknown model
FCh 08h 00h ??? PS/2 Model 25/286
FCh 09h 00h ??? PS/2 Model 25 (10 MHz 286)
FCh 09h 00h 08/25/88 PS/2 Model 30 286 (10Mhz,HDD-type37)
FCh 09h 02h 06/28/89 PS/2 Model 30-286
FCh 09h 02h 06/28/89 PS/2 Model 25 286 (10Mhz,HDD-type37)
FCh 09h ??? ??? IBM "Vail" (sup. 19200Bd serport)
FCh 0Bh 00h 12/01/89 PS/1 (HDD-type 44)
FCh 0Bh 00h 02/16/90 PS/1 Model 2011 (10 MHz 286)
FCh 20h 00h 02/18/93 Compaq ProLinea
FCh 25h 09h 12/07/91 PS/2 Model 56 SLC (20 MHz 386SLC)
FCh 30h [3] ??? Epson, unknown model
FCh 31h [3] ??? Epson, unknown model
FCh 33h [3] ??? Epson, unknown model
FCh 42h [3] ??? Olivetti M280
FCh 45h [3] ??? Olivetti M380 (XP 1, XP3, XP 5)
FCh 48h [3] ??? Olivetti M290
FCh 4Fh [3] ??? Olivetti M250
FCh 50h [3] ??? Olivetti M380 (XP 7)
FCh 51h [3] ??? Olivetti PCS286
FCh 52h [3] ??? Olivetti M300
FCh 81h 00h 01/15/88 Phoenix 386 BIOS v1.10 10a
FCh 81h 01h ??? "OEM machine"
FCh 82h 01h ??? "OEM machine"
FCh 94h 00h ??? Zenith 386
FBh 00h 01h 01/10/86 PC XT-089 ("XT2"), Enh. keyb.,3.5"
FBh 00h ??? ??? HP 200LX 1Mb/2Mb??? BIOS 1.00A Jap
FBh 00h 01h 05/13/94 HP 200LX 2Mb BIOS 1.01A D German
FBh 00h ??? ??? HP 200LX 2Mb, 1.02A, <SG543* max. 5 Mb
FBh 00h ??? ??? HP 200LX 2/4Mb 1.02A >SG543* max.6/8Mb
FBh 00h??? ??? ??? HP OmniGo 700LX
FBh 00h 02h 05/09/86 PC XT
FBh 00h ??? ??? HP 100LX 1Mb BIOS 1.01A (org., EPROM)
FBh 00h ??? ??? HP 100LX 1Mb BIOS 1.02A (w/ shift bug)
FBh 00h ??? ??? HP 100LX 1Mb BIOS 1.03A (w/ shift bug)
FBh 00h 04h 08/19/93 HP 100LX 1Mb BIOS 1.04A (Phoenix 2.14)
FBh 00h ??? ??? HP 100LX 1Mb/2Mb BIOS 1.05A
FBh 00h ??? ??? HP 100LX 1Mb/2Mb BIOS 1.06A
??? ??? ??? ??? HP 95LX
FBh 4Ch [3] ??? Olivetti M200
FAh 00h 00h 09/02/86 PS/2 Model 30 (8 MHz 8086)
FAh 00h 01h 12/12/86 PS/2 Model 30
FAh 00h 02h 02/05/87 PS/2 Model 30
FAh 01h 00h 06/26/87 PS/2 Model 25/25L (8 MHz 8086)
FAh 30h 00h ??? IBM Restaurant Terminal
FAh 4Eh [3] ??? Olivetti M111
FAh FEh 00h ??? IBM PCradio 9075
F9h 00h 00h 09/13/85 PC Convertible
F9h 00h 00h 09/13/85 IBM 5140, PC Convertible (French)
F9h FFh 00h ??? PC Convertible
F9h 00h ??? ??? IBM AP (Advanced Portable =
German version of PC Convertible
introduced 1987-03)
F8h 00h 00h 03/30/87 4 PS/2 Model 80 (16 MHz 386)
F8h 00h 00h ??? 4 PS/2 Model 75 486 (33 Mhz 486)
F8h 01h 00h 10/07/87 4 PS/2 Model 80 (20 MHz 386)
F8h 02h 00h ??? PS/2 Model 55-5571
F8h 04h 00h 01/29/88 5 PS/2 Model 70 (20Mhz386DX,HDD-type33)
F8h 04h 02h 04/11/88 5 PS/2 Model 70 20 MHz,type 2 sysbrd
F8h 04h 03h 03/17/89 5 PS/2 Model 70 20 MHz, type 2 sysbrd
F8h 05h 00h ??? IBM PC 7568
F8h 06h 00h ??? PS/2 Model 55-5571
F8h 07h 00h ??? IBM PC 7561/2
F8h 07h 01h ??? PS/2 Model 55-5551
F8h 07h 02h ??? IBM PC 7561/2
F8h 07h 03h ??? PS/2 Model 55-5551
F8h 09h 00h 01/29/88 5 PS/2 Model 70 16MHz 386DX,type 1 sysbrd
F8h 09h 02h 04/11/88 5 PS/2 Model 70 some models
F8h 09h 03h 03/17/89 5 PS/2 Model 70 some models
F8h 09h 04h 12/15/89 5 PS/2 Model 70 (16 Mhz 386, HDD-type 33)
F8h 0Bh 00h 01/18/89 5 PS/2 Model P70 (8573-121) type 2 sysbrd
F8h 0Bh 02h 12/16/89 5 PS/2 Model P70 ??
F8h 0Ch 00h 11/02/88 PS/2 Model 55SX (16 MHz 386SX)
F8h 0Dh 00h ??? 4 PS/2 Model 70 25MHz, type 3 sysbrd
F8h 0Dh 00h 06/08/88 4 PS/2 Model 70 386 25MHz, type 3 sysbrd
F8h 0Dh 01h 02/20/89 4 PS/2 Model 70 386 25MHz, type 3 sysbrd
F8h 0Dh ??? 12/01/89 4 PS/2 Model 70 486 25Mhz, type 3 sysbrd
F8h 0Eh 00h ??? PS/1 486SX
F8h 0Fh 00h ??? PS/1 486DX
F8h 10h 00h ??? PS/2 Model 55-5551
F8h 11h 00h 10/01/90 5 PS/2 Model 90 XP (25 MHz 486)
F8h 12h 00h ??? PS/2 Model 95 XP
F8h 13h 00h 10/01/90 5 PS/2 Model 90 XP (33 MHz 486)
F8h 14h 00h 10/01/90 5 PS/2 Model 90-AK9 (25 MHz 486),95 XP
F8h 15h 00h ??? PS/2 Model 90 XP
F8h 16h 00h 10/01/90 5 PS/2 Model 90-AKD / 95XP486 (33MHz 486)
F8h 17h 00h ??? PS/2 Model 90 XP
F8h 19h 05h ??? 5 PS/2 Model 35/35LS or 40 (20 MHz 386SX)
F8h 19h 05h 03/15/91 5 PS/2 Model 35 SX / 40 SX (HDD-type37)
F8h 19h 06h 04/04/91 5 PS/2 Model 35 SX / 40 SX (HDD-type37)
F8h 1Ah 00h ??? PS/2 Model 95 XP
F8h 1Bh 00h 09/29/89 5 PS/2 Model 70 486 (25 Mhz 386DX)
F8h 1Bh 00h 10/02/89 5 PS/2 Model 70-486 (25 MHz 486)
F8h 1Ch 00h 02/08/90 5 PS/2 Model 65-121 / 65 SX (16MHz 386SX)
F8h 1Eh 00h 02/08/90 PS/2 Model 55LS (16 MHz 386SX)
F8h 23h 00h ??? 5 PS/2 Model L40 SX
F8h 23h 01h ??? 5 PS/2 Model L40 SX (20 MHz 386SX)
F8h 23h 02h 02/27/91 5 PS/2 Model L40 SX(20Mhz386SX,HDDtype37)
F8h 25h 00h ??? 5 PS/2 Model 57 SLC
F8h 25h 06h ??? 5 PS/2 Model M57 (20 MHz 386SLC)
F8h 26h 00h ??? 5 PS/2 Model 57 SX
F8h 26h 01h ??? 5 PS/2 Model 57 (20 MHz 386SX)
F8h 26h 02h 07/03/91 5 PS/2 Model 57 SX (20Mhz 386SX,SCSI)
F8h 28h 00h ??? PS/2 Model 95 XP
F8h 29h 00h ??? PS/2 Model 90 XP
F8h 2Ah 00h ??? 5 PS/2 Model 95 XP (50 MHz 486)
F8h 2Bh 00h ??? 5 PS/2 Model 90 / 90XP486 (50 MHz486)
F8h 2Ch 00h ??? 5 PS/2 Model 95 XP
F8h 2Ch 01h ??? 5 PS/2 Model 95 (20 MHz 486SX)
F8h 2Dh 00h ??? 5 PS/2 Model 90 XP (20 MHz 486SX)
F8h 2Eh 00h ??? PS/2 Model 95 XP
F8h 2Eh 00h ??? PS/2 Model 95 XP486 (20 Mhz 486SX)
F8h 2Eh 01h ??? PS/2 Model 95 (20 MHz 486SX+487SX)
F8h 2Fh 00h ??? 5 PS/2 Model 90 XP (20 MHz 486SX+487SX)
F8h 30h 00h ??? PS/1 Model 2121 (16 MHz 386SX)
F8h 33h 00h ??? PS/2 Model 30-386
F8h 34h 00h ??? PS/2 Model 25-386
F8h 36h 00h ??? PS/2 Model 95 XP
F8h 37h 00h ??? PS/2 Model 90 XP
F8h 38h 00h ??? PS/2 Model 57
F8h 39h 00h ??? PS/2 Model 95 XP
F8h 3Eh ??? ??? 5 PS/2 ???
F8h 3Fh 00h ??? PS/2 Model 90 XP
F8h 40h 00h ??? PS/2 Model 95 XP
F8h 41h 00h ??? PS/2 Model 77
F8h 45h 00h ??? PS/2 Model 90 XP (Pentium)
F8h 46h 00h ??? PS/2 Model 95 XP (Pentium)
F8h 47h 00h ??? PS/2 Model 90/95 E (Pentium)
F8h 48h 00h ??? PS/2 Model 85
F8h 49h 00h ??? PS/ValuePoint 325T
F8h 4Ah 00h ??? PS/ValuePoint 425SX
F8h 4Bh 00h ??? PS/ValuePoint 433DX
F8h 4Eh 00h ??? PS/2 Model 295
F8h 50h 00h ??? PS/2 Model P70 (8573) (16 MHz 386)
F8h 50h 01h 12/16/89 5 PS/2 Model P70 (8570-031)
F8h 52h 00h ??? PS/2 Model P75 (33 MHz 486)
F8h 56h 00h ??? PS/2 Model CL57 SX
F8h 57h 00h ??? 5 PS/2 Model 90 XP
F8h 58h 00h ??? 5 PS/2 Model 95 XP
F8h 59h 00h ??? 5 PS/2 Model 90 XP
F8h 5Ah 00h ??? 5 PS/2 Model 95 XP
F8h 5Bh 00h ??? PS/2 Model 90 XP
F8h 5Ch 00h ??? PS/2 Model 95 XP
F8h 5Dh 00h ??? PS/2 Model N51 SLC
F8h 5Eh 00h ??? IBM ThinkPad 700
F8h 61h [3] ??? Olivetti P500
F8h 62h [3] ??? Olivetti P800
F8h 80h 00h ??? 4 PS/2 Model 80 (25 MHz 386)
F8h 80h 01h 11/21/89 4 PS/2 Model 80-A21 (25 Mhz 386)
F8h 81h 00h ??? PS/2 Model 55-5502
F8h 87h 00h ??? PS/2 Model N33SX
F8h 88h 00h ??? PS/2 Model 55-5530T
F8h 97h 00h ??? PS/2 Model 55 Note N23SX
F8h 99h 00h ??? PS/2 Model N51 SX
F8h F2h 30h ??? Reply Model 32
F8h F6h 30h ??? Memorex Telex
F8h FDh 00h ??? IBM Processor Complex (with VPD)
F8h ??? ??? ??? PS/2 Model 90 (25 MHz 486SX)
F8h ??? ??? ??? PS/2 Model 95 (25 MHz 486SX)
F8h ??? ??? ??? PS/2 Model 90 (25 MHz 486SX+487SX)
F8h ??? ??? ??? PS/2 Model 95 (25 MHz 486SX+487SX)
F8h ??? ??? ??? IBM "Snowmass" (supports 19200 Bd)
E4h ??? ??? ??? Triumph Adler PC/XT
E1h ??? ??? ??? ??? (checked for by DOS4GW.EXE)
E1h 00h 00h ??? PS/2 Model 55-5530 Laptop
D9h ??? ??? ??? Peacock XT
9Ah [1] [1] ??? Compaq XT/Compaq Plus
4Bh ??? ??? ??? Micromint XT
30h ??? ??? ??? Sperry PC
2Dh [1] [1] ??? Compaq PC/Compaq Deskpro
??? 56h ??? ??? Olivetti, unknown model
??? 74h ??? ??? Olivetti, unknown model
00h ??? ??? ??? Olivetti M24
00..06h [1] [1] ??? c't86 (by German c't magazine)
Notes:
[4] According to Key Tronic's SE.EXE/SL.EXE utilities, these
PS/2 machines have a conventional keyboard controller
on the mainboard, which uses the AT-style communication
protocol and expects to see AT-style keyboard scan codes
in set 2 (which are normally converted to PC-style scan
codes in set 1 for INT 09h by the keyboard controller on
the mainboard in "translation mode").
[5] According to Key Tronic's SE.EXE/SL.EXE utilities, these
newer PS/2 machines have a hybrid keyboard controller on
the mainboard, which uses an AT-style communication
protocol, but expects to see PC-style keyboard scan codes
in set 1 (that is, the keyboard controller does not
translate the codes, and just passes them through).
If you find errors or omissions, please let me know. Thanks alot.
Greetings,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
The Merry Prankster
> Hi folks,
>
> I am currently in the process to collect machine IDs
> for the next issue of Ralf Brown's Interrupt List
> (http://www.pobox.com/~ralf/files.html).
>
> Having a collection of identification bytes and strings
> (BIOS version etc.) is interesting in itself to see what
> is (or was) actually "out there", and it can also help in
> tracking down bugs or working around problems found on some
> particular systems.
>
> Lurking around here for a while, I think some of you PS/2
> fans would be able to come up with many more ID bytes for
> original IBM and OEM machines not yet included in RBIL61.
Darn! V6.1 already? But, that's the "nature of the beast" - has a snooze
every now and then - but, suddenly has a good charge about feeding on
whatever it can find?
> Of course, I am also interested in missing IDs for other
> IBM PC, XT, or AT class machines (in particular those old
> "incompatible clones"), as well as any other brand name
> clones, laptops, palmtops, industrial systems, etc.
I'm afraid you'll have to wait for my later IBM PC Servers (720 etc.) and
other rarer systems.
> So, I would like to ask you to spend a few minutes to read
> out the IDs on your own machines and check if they and the
> BIOS dates are already in the list. If they are not, I would
> very much appreciate your report, either here, or in private
> mail. Alternatively, you can also report this directly to Ralf.
You may wish to Google Search this group for additional "Information Panel"
I/O port and BIOS support interrupt function information, "VPD" and/or "POS
SubAddress" details. You may find many additional snippets of highly
interesting information for "the next Edition". All pre-publication, draft
copies gratefully received. For proof-reading purposes, of course. 8^)
> The model byte is usually located at F000h:FFFEh and the BIOS
> date at F000h:FFF5h. It's trivial to read out with DEBUG.
> However, most machines since ca. 1985/1986 should support
> INT 15h/AH=C0h, which will give much more detailed information,
> including sub-model and revision bytes. If you have a system
> info tool, you can use this to retrieve these values. For MSD,
> it may look similar to:
>
> +------------------ Computer -------------------+
> ¦ Computer Name: Award ¦
> ¦ BIOS Manufacturer: Award ¦
> ¦ BIOS Version: Award Modular BIOS v4.51PG ¦
> ¦ BIOS Category: IBM PC/AT ¦
> ¦ BIOS ID Bytes: FC 01 00 ¦
"Stock" AT-Class BIOS Id. (pretty much anything with a 386 or higher,
including laptops, ThinkPads etc. which *aren't* MCA-bus). May even apply to
"advanced" 286-class systems/mobos etc. (e.g. Early Apricot Xen Series?)
> ¦ BIOS Date: 04/28/99 ¦
> ¦ Processor: ??? ¦
> ¦ Bus Type: ISA/AT/Classic Bus ¦
> +-----------------------------------------------¦
>
> If you only have DEBUG, the following may do as well:
Comments added, for the uninitiated - omit all including ";" comment lead-in
for input to DEBUG
> --- GETID.DEB (the blank line is important!) ---
> A 100 ; Start Assembly insertion at CS:100
{std. DOS .COM pgm.]
> mov ax,3515 ; Query Interrupt Vector for Int 15h
> int 21 ; Go do it
> mov ax,es ; Get Segment in AX
> or ax,bx ; Test for non-zero vector, otherwise
it's useless
> jz 100 ; Erk! Go to start [CS:100] if
vector IS 0? Loopy!
> mov ax,es ; Get [non-zero] Vector Segment in AX
> and ax,bx ; AND with Vector Offset
> inc ax ; Bump by 1 [FFFF=>0000]
> je 100 ; Dang! It was FFFF:FFFF (Why?)
Loopy!
> mov ah,C0 ; Get "System Configuration Table"
pointer in ES:BX (ideally, these should be zeroed before call/Int)
> int 15 ; Get pointer now
> push es ; Save returned ES
> pop ds ; Restore to DS
> mov si,bx ; Oh! I see, we're going to do a
"string copy" - DS:SI=ES:BX after call
> push cs ; Now we have to set the "target"
address = ES:DI
> pop es
> mov di,200 ; Hmm, seems CS:200 has been
nominated as the "to" area.
> mov cx,30 ; 96 bytes?! (48 words). That seems a
little excessive. Still, it does no harm.
> cld ; Ensure that we're working with
increasing (word) addresses [i.e. DS:SI++]
> rep movsw ; Copy the 96 bytes
> mov ax,F000 ; Hey up! BIOS locations!
> push ax
> pop ds
> mov si,FFE0 ; DS:SI=>"Processor reset" code @
F000:FFF0 (See your Intel doc.s) minus 16?
> mov cx,10 ; 16 words (huh?)
> rep movsw ; Copy 32 bytes down to AFTER where
we left ES:DI last time (i.e. CS:0260++)
>
> P=100 1A ; Now *that's* one I haven't seen
recently, checking.... O.K. PROCEED, starting with CS:100 (set IP=100), for
1Ah = 26 instructions!!! A funny, cryptic way of running the code entered.
> D CS:200 ; DUMP (i.e. Hex+ASCII
Display/Print) the data copied to local storage.
Alternatively and/or additionally (to Write as program GETID.COM *with* the
data copied, for attachment):
RBX ; Set BX (High Write Length word)
to 0
xxxx: 0
RCX ; Set CX (Low Write Length word)
to 180 (280h - 100h)
xxxx: 180
NGETID.COM ; Set filename to be writtem
W ; Write (default start = CS:100)
file of Length BX:CX (double-word)
> Q ; Quit
> Q ; Just in case we forgot some
mode-terminating command/return - Quit (I Said!)
> ---------
>
> Copy this script into a text file named GETID.DEB and at the
> plain DOS prompt run DEBUG as follows:
>
> DEBUG < GETID.DEB > GETID.TXT
If the "Write" section was added (and you only intend attaching the
GETID.COM file) you only need:
x:\path>DEBUG <GETID.DEB (GETID.COM should be created in x:\path directory).
=====
Contributor's Notes:
1) Per processor complex, the (latest) BIOS revision(s) detect(s)/queries
the 16-bit Planar-Id (FF6F = 8590/9590, FF9F = 95XP, E3EF = Type-4/Server
95/Server 95A/PC Server 500 [dual serial + dual parallel port] planar) and
returns a different result (address) in ES:BX for Int 15h AH=C0h. *All*
possible "System Configuration" tables for all complex/planar combinations
are embedded, sequentially (as an indexed table) within the (Flash) ROM BIOS
code contents.
2) There exist "revised" BIOS ROMs FRU 52G9509 and FRU 41G9361,
respectively, for the "Type-1" (25/33Mhz base clock, optional 17ns 256KB WB
L2 cache module), and "Type-2" (25Mhz base clock, no L2 cache option,
enhanced memory access timing) complexes, which, in addition, provide the
*overriding* and equivalent IBM (SCB) SCSI BIOS (<=4032MB drive and enhanced
IML/System Partition "search") functionality that is present on later IBM
SCB (SubSystem Control Block = Int 4Bh AH=80h AL=??) SCSI
interface-compliant adapters - generally referred to by their "upgrade"
EPROM IBM FRU (Field-Replaceable Unit) Part No.s 92F2244 and 92F2245.
Relevant adapters :- "Tribble" (8EFE), uncached SCSI [-1, with some SCSI-2
command extensions, 12MB/sec across the MCA bus, 16.6MB/sec across the MCA
bus], "Spock" (8EFF), 512KB [or 2MB, if you can find the appropriate 30-pin
parity SIMMs] cached SCSI [-1, with some SCSI-2 command extensions] and
"Corvette" (8EFC), SCSI-2 Fast+Wide buffered adapters [20-40MB/sec
SynchroStream-capable across the MCA bus]). All these adapters have Id.s
which fall within the inclusive "architected" range 8EF8-8EFF, which the
complex BIOS automatically detects, disables the on-adapter BIOS ROM(s) of,
and substitiutes its own SCSI BIOS support for (up to 8 adapters per system,
with up to 15 devices per adapter, 56 Total supported).
3) The IBM SCSI (SCB) BIOS functonality relies *heavily* upon *very
specific* areas of the XBDA [as does XGA(-2) functionality] See: Int 15h
AH=C1h. Multiple IBM SCB SCSI Adapters (and/or XGA(-2) Adapters) and
attached devices may cause the XBDA to grow *significantly* beyond the
"usual" 1KB allocation. Byte XBDA:0 (XBDA size in KB) is *always* correctly
maintained to reflect this, by the BIOS/POST process. Windows, MS-DOS,
PC-DOS and DR-DOS/NDOS EMM386.* (and other memory managers) may *relocate*
the XBDA from its "normal" position at the absolute top of "conventional
memory" (i.e. 640KB [Seg: A000h] minus XBDA size) to low memory (i.e.
immediately above the DOS "Data Segment" [often found at 70h:0], somewhere
around 02xxh:0).
4) Word XBDA:00B4h - Number of 16-byte paragraphs (offset from XBDA:0) after
which the IBM (SCB) SCSI BIOS area begins
Dword XBDA:00B8h - "Reported Usable Size" See: Int 13h AH=08h etc. (i.e.
Also, sector offset to start of "hidden" System Partition). If following
byte is "S" this value is added to all sector accesses to "Drive C:" (80h).
Byte XBDA:00BEh - IBM "System Partition" Boot Indicator = "S" for
"System Partition is C:, rest hidden"
Byte XBDA:00C1 - Flag(s), unknown precise function/usage, at this time.
Word XBDA:00E3h - "Currently operating" Model-Submodel (big-endian) e.g.
F836 (See: error code 0169)
Word XBDA:00ECh - Under analysis(?)
Word XBDA:0122h - Boot Device Id. (See: Int 15h AH=D6h AL=00, BL=00
Read/01 Write, DX=Value).
Word XBDA:0124h - Boot Device Key (See: Int 15h AH=D6h AL=01, BL=00
Read/01 Write, DX=Value).
Byte XBDA:012Fh - Flag(s), unknown precise function/usage, at this time.
5) XBDA:180h 1st "extended/multiple instance" Area
Area:00 Word Offset (relative to XBDA segment address) to next "Area"
(linked list)
Area:02 Adapter Id. of 1st adapter with "extended/multiple instance"
support.
Area:04 "Area, Function-specific"
6) IBM (SCB) SCSI "Area" (multiple, linked-list, per adapter)
Area:00 Word Offset (relative to XBDA segment start address) to next
"Area" (linked-list)
Area:02 Adapter Id. of 1st (IBM (SCB) SCSI) Adapter
Area:04 Byte No. of IBM (SCB) SCSI Adapters under mangement (Id.s
8EF8-8EFF inclusive)
Area:05 Byte RETVAL in AL (AH zeroed) for Func 01 (?Last Completion
Return Code?)
Area:06 Byte "DOS Device No." of *First* IBM (SCB) SCSI Hard Drive
managed *by this adapter instance*.
Area:07 Byte Count of IBM (SCB) SCSI *Hard Drives* (Removable/Fixed)
managed *by this adapter instance*.
Area:08 Bit flags 40h = Allocated/In use (ORed into port 92h contents)
Area:0Ah Offset (within Area) to "Device Array" *for this adapter
instance*
Area:0Ch Word Offset (within Area) to "non-DASD (HD)" Device Array
Area:12h Byte No. of non-DASD (HD) Device Type entires in "non-DASD
(HD)" Array
Area:14h Byte Offset (within Area) to [Byte SCSI device-type, Byte (SCSI
device-type) count] Table/List
Area:18h Byte count (Global Adapter operation timeout value, seconds
[usually 60 = 1Min.])
The "Device Array(s)" may, confusingly, and dependant upon BIOS revision
level (complex and/or adapter, further dependant upon Adapter Id. and
support [SCSI-2 F+W supports 15 devices Wide and/or Narrow]) consist of
4-byte *or* 5-byte entries. No clear understanding of the "equation", at
this time. Basically, per device timeout, removable media + 512-byte sector
flags, PUN & LUN nibbles, "SCB SCSI Device No." etc.
===== [Sorry, cull the relevant bits out of this]
Processor Board Submodel Value
| Type Description Model 90 Model 95 Server 95
1 25MHz i486DX . . . . . . . . . . . . 11 14 --
1 33MHz i486DX . . . . . . . . . . . . 13 16 --
3 50MHz i486DX (Enhanced) . . . . . . 29 28 --
1 50MHz i486DX (Original) . . . . . . 2B 2A --
1 20MHz i486SX . . . . . . . . . . . . 2D 2C --
1 20MHz i486SX w/ 20MHz i487SX . . . . 2F 2E --
1 33/66MHz i486DX2 (Original). . . . . 37 36 --
2 25/50MHz i486DX2 . . . . . . . . . . 3F 40 --
+ 4 33/66MHz i486DX2 (Enhanced). . . . . 43 42 44
#@4 Pentium-60, -66, -90 . . . . . . . . 45 46 47
2 25MHz i486SX . . . . . . . . . . . . 57 58 --
2 25MHz i486SX w/ 25MHz i487SX . . . . 59 5A --
2 25MHz i486SX w/ 25/50MHz ODP486SX . 5B 5C --
| Added information for the Type 4 card
+ Added information for the Type 4 DX2-66 card
# Added information for the Type 4 Pentium-66 and -90 cards
=====
> F8h 19h 05h ??? 5 PS/2 Model 35/35LS or 40 (20 MHz 386SX)
> F8h 19h 05h 03/15/91 5 PS/2 Model 35 SX / 40 SX (HDD-type37)
> F8h 19h 06h 04/04/91 5 PS/2 Model 35 SX / 40 SX (HDD-type37)
> F8h 1Bh 00h 09/29/89 5 PS/2 Model 70 486 (25 Mhz 386DX)
> F8h 1Bh 00h 10/02/89 5 PS/2 Model 70-486 (25 MHz 486)
> F8h 1Ch 00h 02/08/90 5 PS/2 Model 65-121 / 65 SX (16MHz 386SX)
> F8h 1Eh 00h 02/08/90 PS/2 Model 55LS (16 MHz 386SX)
> F8h 23h 00h ??? 5 PS/2 Model L40 SX
> F8h 23h 01h ??? 5 PS/2 Model L40 SX (20 MHz 386SX)
> F8h 23h 02h 02/27/91 5 PS/2 Model L40 SX(20Mhz386SX,HDDtype37)
> F8h 25h 00h ??? 5 PS/2 Model 57 SLC
> F8h 25h 06h ??? 5 PS/2 Model M57 (20 MHz 386SLC)
> F8h 26h 00h ??? 5 PS/2 Model 57 SX
> F8h 26h 01h ??? 5 PS/2 Model 57 (20 MHz 386SX)
> F8h 26h 02h 07/03/91 5 PS/2 Model 57 SX (20Mhz 386SX,SCSI)
> F8h 30h 00h ??? PS/1 Model 2121 (16 MHz 386SX)
> F8h 33h 00h ??? PS/2 Model 30-386
> F8h 34h 00h ??? PS/2 Model 25-386
> F8h 3Eh ??? ??? 5 PS/2 ???
> F8h 41h 00h ??? PS/2 Model 77
> F8h 48h 00h ??? PS/2 Model 85
> F8h 49h 00h ??? PS/ValuePoint 325T
> F8h 4Ah 00h ??? PS/ValuePoint 425SX
> F8h 4Bh 00h ??? PS/ValuePoint 433DX
> F8h 4Eh 00h ??? PS/2 Model 295
> F8h 50h 00h ??? PS/2 Model P70 (8573) (16 MHz 386)
> F8h 50h 01h 12/16/89 5 PS/2 Model P70 (8570-031)
> F8h 52h 00h ??? PS/2 Model P75 (33 MHz 486)
> F8h 56h 00h ??? PS/2 Model CL57 SX
> F8h 5Dh 00h ??? PS/2 Model N51 SLC
--
Cheers,
Tim Clarke
Monetaim Limited
Guildford, U.K.
http://homepage.ntlworld.com/tim_n_clarke/index.htm
http://members.ebay.co.uk/aboutme/tim-clarke/
Matthias Paul
> You may wish to Google Search this group for additional
> "Information Panel" I/O port and BIOS support interrupt
> function information, "VPD" and/or "POS SubAddress" details.
> You may find many additional snippets of highly interesting
> information for "the next Edition".
Yup, this sounds interesting, indeed. Any direct links or so
to cut down the necessary time for sorting and processing?
Or even better, is someone volunteering to pre-compile the
stuff into semi-RBIL style?
> "Stock" AT-Class BIOS Id. (pretty much anything with a 386 or
> higher, including laptops, ThinkPads etc. which *aren't* MCA-bus).
> May even apply to "advanced" 286-class systems/mobos etc. (e.g.
> Early Apricot Xen Series?)
Yup, pretty standard ASUS P55T2P4 good "old" 1997 working horse here.
Of course, it doesn't make any sense at all to collect data for
boards like this, we'd have to fill thousands of pages then... ;-)
Maybe my comment to see what's "out there" was a bit misleading.
I am looking for original IBM (and OEM) stuff as well as clone
machines of the Eighties und early Nineties. Many of the old and
not so compatible ones had non-standard IDs - this is interesting
to some people who still write software for older systems.
And if brand name machines (like the various Apricots?) used
standard IDs this is also interesting info.
The main idea is to collect and document everything that was
*not* totally obvious standard, so that in the end virtually
all IDs ever used anywhere will be listed. Most if not almost
all of the "100% compatible" clone boards today also use standard
IDs, no possible distinction there. You'd have to resort to other
means to identify them...
> Comments added, for the uninitiated - omit all including ";"
> comment lead-in for input to DEBUG
In fact, DEBUG supports ;comments in many cases, but since not all
issues of DEBUG support them in all cases, I thought it would be
better to omit them in public scripts.
>> or ax,bx ; Test for non-zero vector, otherwise it's useless
>> jz 100 ; Erk! Go to start [CS:100] if vector IS 0? Loopy!
;-) Yes, it's ugly, but this is just a DEBUG script, not a program.
No danger for an endless loop, because of the P=100 1A use later on.
>> inc ax ; Bump by 1 [FFFF=>0000]
>> je 100 ; Dang! It was FFFF:FFFF (Why?)
Some rare, old, and odd(!) systems initialized with FFFFh:FFFFh
rather than 0000h:0000h. For obvious reasons, we'll have to cut
them off as well.
>> mov ah,C0 ; Get "System Configuration Table" pointer in ES:BX
>> ; (ideally, these should be zeroed before call/Int)
Yup, definitely in a proper program.
>> mov cx,30 ; 96 bytes?! (48 words). That seems a little
>> ; excessive. Still, it does no harm.
Yes, 16 bytes should be sufficient in most cases, but sometimes
there are interesting vendor specific strings following the
structure, so I copied a bit more.
>> mov si,FFE0 ; DS:SI=>"Processor reset" code @ F000:FFF0
>> ; (See your Intel doc.s) minus 16?
>> mov cx,10 ; 16 words (huh?)
POST entry is F000h:FFF0h. I actually meant F000h:FFE0h here because
I'm interested in the last 32 bytes of the ROM, whereby in most
cases only the last 11 are of any actual interest here. But sometimes
there's an ASCII string in the FFExh area, which could be useful
for identification purposes.
>> P=100 1A ; Now *that's* one I haven't seen recently,
>> ; checking.... O.K. PROCEED, starting with
>> ; CS:100 (set IP=100), for 1Ah = 26 instructions!!!
>> ; A funny, cryptic way of running the code entered.
This ensures that you see the progress of the script on the screen
or in the redirected file (thereby "self-documenting" the run in
case INT 15h does not work), and also that you don't run into an
endless loop in case INT 15h was undefined. So, G was not a good
alternative here.
>> Q ; Quit
>> Q ; Just in case we forgot some mode-terminating
>> ; command/return - Quit (I Said!)
>> ---------
Yup. Actually, the second Q is only a placeholder for the empty line
which would have to reside there otherwise - just error prevention.
Many people would cut off a pending empty line (which is there for
the CR/LF) and thereby they may cause the script to "hang" waiting
for the final CR/LF which never comes in input redirection.
*Any* other text would serve the same purpose.
> Contributor's Notes:
>
> [<Omitted lots of interesting stuff here for further processing>]
>
> Processor Board Submodel Value
> Type Description Model 90 95 Server 95
>
> 1 25MHz i486DX . . . . . . . . . . . . 11 14 --
> 1 33MHz i486DX . . . . . . . . . . . . 13 16 --
> 3 50MHz i486DX (Enhanced) . . . . . . 29 28 --
> 1 50MHz i486DX (Original) . . . . . . 2B 2A --
> 1 20MHz i486SX . . . . . . . . . . . . 2D 2C --
> 1 20MHz i486SX w/ 20MHz i487SX . . . . 2F 2E --
> 1 33/66MHz i486DX2 (Original). . . . . 37 36 --
> 2 25/50MHz i486DX2 . . . . . . . . . . 3F 40 --
>+ 4 33/66MHz i486DX2 (Enhanced). . . . . 43 42 44
Ah, a completely "new" one. Fits in nicely in the gap. :-)
>#@4 Pentium-60, -66, -90 . . . . . . . . 45 46 47
> 2 25MHz i486SX . . . . . . . . . . . . 57 58 --
> 2 25MHz i486SX w/ 25MHz i487SX . . . . 59 5A --
> 2 25MHz i486SX w/ 25/50MHz ODP486SX . 5B 5C --
>
> | Added information for the Type 4 card
> + Added information for the Type 4 DX2-66 card
> # Added information for the Type 4 Pentium-66 and -90 cards
Great, thanks.
Question: RBIL lists most of them as "Model 90 XP" or "95 XP",
while you write just "Model 90" or "95". If there is any,
what's the difference?
Do you also have the model *numbers* rather than only the *names*?
With all these different versions out there, maybe it would be
useful to add them as well to this list.
>> F8h 19h 06h 04/04/91 5 PS/2 Model 35 SX / 40 SX (HDD-type37)
>
>> F8h 1Bh 00h 09/29/89 5 PS/2 Model 70 486 (25 Mhz 386DX)
Since you sub-divided the remainder of the list into various
sub-sections, any idea what's missing here?
Thanks and keep the stuff rolling in!
Tim (the Merciless) Clarke
> > You may wish to Google Search this group for additional
> > "Information Panel" I/O port and BIOS support interrupt
> > function information, "VPD" and/or "POS SubAddress" details.
> > You may find many additional snippets of highly interesting
> > information for "the next Edition".
>
> Yup, this sounds interesting, indeed. Any direct links or so
> to cut down the necessary time for sorting and processing?
> Or even better, is someone volunteering to pre-compile the
> stuff into semi-RBIL style?
Maybe the former, certainly not the latter, I have more than enough on my
plate as it is. Although I found the "PC Interrupts" publication and
likewise the "Undocumented xxx..." books great reading, I always ended up
"wanting more" (a bit like Chinese food) so, I was more than happy to
contribute what I have thus far. However, pecuniary demands (and prior
obligations) take precedence, I'm afraid.
=====
[VPD & POS SubAddressing (Reg.s 106 & 107)]
Hi Unal...
> > N.B. in some testing of mine POS register 7 cannot be read as 00h after
> > writing 00h, but returns 0FFh. I believe that this indicates that only
POS
> > register 6 is being used for subaddressing. I'm still trying to work out
the
> > empirical method to determine "Subaddressed data access". The Corvette
> > returns values for Index values xx00, xx01 and xx02. The latter two I
would
> > expect to be written as POS[4] and POS[5], in ADF syntax.
>
> I get subaddress extensions of 0000h (no any), FFFFh (?) and FF00h. There
> might be possibly specified bit(s) at some specified pos which put the
> card/planar into extended config mode. Further reading & digesting will be
> necessary and the already specified bit fields should be analysed. We make
> some progress, nevertheless.
N.B. all numerics are hexadecimal. ASCII data shown in "". nul = 00h
Subaddressing for adapters seems to work out as follows:
Test Subaddressing support by writing Index 0000 to Reg6 (LSB) and Reg7
(MSB) and read them back.
Results: FFFF - Subaddressing not supported
FF00 - High Subaddressing Index not supported (values 0001-00FF
*may* be)
0000 - Subaddressing supported (including High Subaddressing
index?)
Then read Subaddressed POS and/or VPD data as follows:
R7R6
Index Reg3 Reg4
0000 r3r3 r4r4
0001 x1x1 y1y1 Start of POS[4-n] (Subaddressed POS data). May be
empty.
0002 x2x2 y2y2 If vvv1 = 0001 then NO Subaddressed POS[4-n] data
exists.
...
vvv1 "V" v1v1 Start of VPD data, if vnvn = r4r4 then ignore
vvv2 "P" v2v2
vvv3 "D" v3v3
vvv4 nul v4v4
...
To supply some examples of how this works, I will describe some things using
the term "Index" instead of "Subaddress" to try to clarify matters.
During writing of increasing indexes to R7R6, the value read back *may* have
wrapped.
Write 0002 and read back FF00 (Corvette) then the high index is not
supported and the maximum index is nn01. *No* VPD is supported (insufficient
length).
Write up to 0100 when value read back is FF00 (RS6K Ultimedia Audio) and
high index is *not* supported and maximum index is 00FF (VPD limit). VPD
*may* be supported, scan for it. Subaddressed POS data may *not* be
supported if VPD starts at index 0001.
Write up to 0102 when value read back is 0000 or 0100 and high index is
supported and maximum index is 0101 (e.g. Miami POS 3A and 3B values). VPD
*may* be supported, scan for it. Subaddressed POS data may *not* be
supported if VPD starts at index 0001.
If VPD is found at a certain starting Index "vvv1" (say 0010, as hinted at
in the Miami chip spec.), then for Indexes greater than or equal to that
Index, the data read from Reg4 may either equal the "base" Reg4 value (when
Index is 0000, or FF00 if high index is not supported) or be specialised POS
data that doesn't fall into the normal "Subaddressed POS data"
classification. For Index values less than "vvv1" *both* Reg3 and Reg4
should return "Subaddressed POS data" values such that POS[4] = Index 0001,
Read Reg3, POS[5] = Index 0001, Read Reg4, POS[6] = Index 0002, Read Reg3,
POS[7] = Index 0002, Read Reg4 ... etc. etc. up to POS[30] = Index POS[31] =
Index 000E, Read Reg4. There is scope for another 2 bytes of POS-related
data (using Index value 000F), which I believe is used as a checksum for
POS[4]-POS[31], if index 000F is less than "vvv1".
--
Cheers
Tim
=====
[PS/2 & PC Server Information Panel]
> > > I wonder if anyone knows how to write to the info panel on a Server
> > > 720...?
It claims "Information Panel Installed" under QCONFIG /D /P, so the Real
Mode BIOS Int 15h AH=CBh interface should be supported. This mechanism
should work for *any* system which has the Information Panel Installed
flag set (Feature Byte 3, Bit 2).
MOV AH,C0
INT 15
TEST BYTE PTR ES:[BX+7],4 Test for Information Panel
JZ NOPANEL Ooops!!!
MOV BH,aa ASCII Value
MOV BL,n Display Position (0-7 = Left to Right, Model 95 and
Server 500)
*** Display Position (0-Fh = Left to Right, Top
Line, Server 720) ***
*** Dunno how to get at Bottom Line yet!!! ***
MOV AL,n Control Flag (0=Insert, 1=Replace [Model 95, Server
500 only],
*** 2=Repeat [Server
720 only]) ***
MOV AH,CB
INT 15
On Return:-
If successful, CARRY CLEAR and :-
AH = 00
If error, CARRY SET and :-
AH = 86 call not supported
AH = 01 BL out of range (0-?)
AH = 02 BH out of range (20h-5Fh on Model 95 and Server 500,
*** 20h-7Ah on Server 720) ***
AH = 03 Control Failure (Insert and position not empty/Replace and position
not full)
Additional note: Server 720s BIOS plays with ports 0E9h (control?) and 0E8h
(data?) to achieve the desired effect, but I don't fully understand it yet.
Seems to be a pseudo-serial interface with buffer-full, buffer-empty flags
for command and data values, or something similar.
--
Regards,
Tim Clarke
=====
And that's your lot for now, I'm afraid.
=====
Which I alluded to, as some of our denizens aren't into "cut-and-paste (into
NOTEPAD)" then "save as", yet. 8^)
Also, I tend to plug PC-DOS 7/2000 for its DOS REXX features, but it's an
uphill struggle.
> >> or ax,bx ; Test for non-zero vector, otherwise it's useless
> >> jz 100 ; Erk! Go to start [CS:100] if vector IS 0? Loopy!
>
> ;-) Yes, it's ugly, but this is just a DEBUG script, not a program.
> No danger for an endless loop, because of the P=100 1A use later on.
>
> >> inc ax ; Bump by 1 [FFFF=>0000]
> >> je 100 ; Dang! It was FFFF:FFFF (Why?)
>
> Some rare, old, and odd(!) systems initialized with FFFFh:FFFFh
> rather than 0000h:0000h. For obvious reasons, we'll have to cut
> them off as well.
What about the "use the high interrupt vector area as a temporary stack,
nonsense, in DOS initialisation"? I wrote (a long time ago) a device driver
to specifically clear that area to zeroes, so that any "vector claimed"
tests (by subsequent device drivers/TSRs) wouldn't get confused by this
oversight.
> >> mov ah,C0 ; Get "System Configuration Table" pointer in ES:BX
> >> ; (ideally, these should be zeroed before call/Int)
>
> Yup, definitely in a proper program.
>
> >> mov cx,30 ; 96 bytes?! (48 words). That seems a little
> >> ; excessive. Still, it does no harm.
>
> Yes, 16 bytes should be sufficient in most cases, but sometimes
> there are interesting vendor specific strings following the
> structure, so I copied a bit more.
>
> >> mov si,FFE0 ; DS:SI=>"Processor reset" code @ F000:FFF0
> >> ; (See your Intel doc.s) minus 16?
> >> mov cx,10 ; 16 words (huh?)
>
> POST entry is F000h:FFF0h. I actually meant F000h:FFE0h here because
> I'm interested in the last 32 bytes of the ROM, whereby in most
> cases only the last 11 are of any actual interest here. But sometimes
> there's an ASCII string in the FFExh area, which could be useful
> for identification purposes.
Ah, I see what you're getting at. The "COMPAQ" or other strings?
> >> P=100 1A ; Now *that's* one I haven't seen recently,
> >> ; checking.... O.K. PROCEED, starting with
> >> ; CS:100 (set IP=100), for 1Ah = 26 instructions!!!
> >> ; A funny, cryptic way of running the code entered.
>
> This ensures that you see the progress of the script on the screen
> or in the redirected file (thereby "self-documenting" the run in
> case INT 15h does not work), and also that you don't run into an
> endless loop in case INT 15h was undefined. So, G was not a good
> alternative here.
It's just that I'd never seen it used previously.
Ergh! There are three types of planar that accept a "processor complex" -
the Model 90 (both 8590 and 9590 Types) - Planar Id FF6F (read from 100h and
101h during "Planar Setup", like an adapter id.), the "95XP" (8595 and
"entry-level" 9595s Types) - Planar Id. FF9F (single serial and parallel
ports), for which the Types 1, 2 and 3 processor complexes were designed,
finally we have "la piece de resistance" the "95A (RAID)" (9595A) - Planar
E3?? (I forget, Dual serial and parallel ports, only accepts a Type-4
complex).
Each complex's BIOS determines (during POST) the planar it is installed in
and returns one from a table of "System Configuration Data Tables" in
response to an Int 15h AH=C0h call. Note that the later revisions of BIOS of
the four Type-4 complexes (DX2-66, P60, P66 and P90) were "retrofitted" to
work in the "old" 90 and 95XP planars. The resverse does *not* apply (but
could, with a lot of work) to using Types 1, 2 and 3 in a 95A planar.
> Do you also have the model *numbers* rather than only the *names*?
Ugh again! 859n-xCy and/or 959n-xCy, where n = 0 or 5 and "C" =
"0" Type-1 386DX20 (rare and never "released" in any great quantity)
"G" Type-2 SX25
"H" Type-2 DX25
"J" Type-1 DX25
"K" Type-1 DX33
"L" Type-2 DX2-50
"M" Type-3 DX50
"N" Type-4 DX2-66
"P" Type-4 Pentium 60
"Q" Type-4 Pentium 66
("Y") Type-4 Pentium 90 (psuedo-code, only used in referenece to 95s
upgraded with the PC Server 500 complex)
Note: "x" indicates one of many things, drive type, OS-preload, National
language-specific, Special Features/Build (e.g. a CTO system - Configured To
Order, or "Open-Bay" system - specify HDs and controller)
In general, "y" indicates HD capacity, which I'll leave aside as being
relatively irrelevant.
> With all these different versions out there, maybe it would be
> useful to add them as well to this list.
>
> >> F8h 19h 06h 04/04/91 5 PS/2 Model 35 SX / 40 SX (HDD-type37)
> >
> >> F8h 1Bh 00h 09/29/89 5 PS/2 Model 70 486 (25 Mhz 386DX)
>
> Since you sub-divided the remainder of the list into various
> sub-sections, any idea what's missing here?
I keep on the lookout, as it has relevance to some of the arcaner
System/Planar ADF logic (Pxxxx.ADF files). It took me a while to realise
that there really *was* a 386DX complex for the 90s and 95s (which would
have to have been allocated two "Id.s", one for each planar). Check with
David Beem, as he's been sniffing at this again.
> Thanks and keep the stuff rolling in!
I try. That's all.
--
Cheers,
Tim Clarke
Monetaim Limited
Guildford, U.K.
http://homepage.ntlworld.com/tim_n_clarke/index.htm
http://members.ebay.co.uk/aboutme/tim-clarke/
"Resistance is futile (recalcitrant piece of computer equipment)...
Your uniqueness will be assimilated and added to the perfection that is
Ours!!!"
or, alternatively...
"Look out! It's Speaker to Geeks!
Don't go anywhere near him
when his tongue's that funny colour!"
David L. Beem
> > Yup, this sounds interesting, indeed. Any direct links or so
> > to cut down the necessary time for sorting and processing?
> > Or even better, is someone volunteering to pre-compile the
> > stuff into semi-RBIL style?
> Maybe the former, certainly not the latter, I have more than enough
> on my plate as it is. Although I found the "PC Interrupts" publication
> and likewise the "Undocumented xxx..." books great reading, I
> always ended up "wanting more" (a bit like Chinese food) so, I was
> more than happy to contribute what I have thus far. However,
> pecuniary demands (and prior obligations) take precedence, I'm afraid.
errors I found in the text. If I too had my cost-of-living covered I would
be more helpful here.
> ...finally we have "la piece de resistance" the "95A (RAID)"
> (9595A) - Planar E3?? (I forget, Dual serial and parallel
> ports, only accepts a Type-4 complex).
PS/2 Model 9595A, Server 500 E4FEh
> > Do you also have the model *numbers* rather than only the *names*?
> Ugh again! 859n-xCy and/or 959n-xCy, where n = 0 or 5 and "C" =
> "0" Type-1 386DX20 (rare and never "released" in any great quantity)
> "G" Type-2 *486SX-20*
> "H" Type-2 *486*DX25
> "J" Type-1 *486*DX25
> "K" Type-1 *486*DX33
> "L" Type-2 *486*DX2-50
> "M" Type-3 *486*DX50
> "N" Type-4 *486*DX2-66
> "P" Type-4 Pentium 60
> "Q" Type-4 Pentium 66
> ("Y") Type-4 Pentium 90 (psuedo-code, only used in referenece
> to 95s upgraded with the PC Server 500 complex)
> Note: "x" indicates one of many things, drive type, OS-preload,
> National language-specific, Special Features/Build (e.g. a CTO
> system - Configured To Order, or "Open-Bay" system - specify
> HDs and controller) In general, "y" indicates HD capacity, which
> I'll leave aside as being relatively irrelevant.
Excluding the 25, 30, 50, 60, 70, & 80 type that table also pertains to
other PS/2s. Other "C" codes are:
"1" = 386SX-16
"2" = 386SLC-16
"3" = 386SX-16
"4" = 386SX-20
"5" = 386SLC-20
"8" = 386DX-20
"B" = 486SLC2-50
"C" = 386DX-25
"D" = 386DX-33
"E" = 486SLC3-75
"G" = 486SX-20 (corrected above)
"U" = 486SX-33
"V" = 486SX-33
> I keep on the lookout, as it has relevance to some of the arcaner
> System/Planar ADF logic (Pxxxx.ADF files). It took me a while to
> realise that there really *was* a 386DX complex for the 90s and 95s
> (which would have to have been allocated two "Id.s", one for each
> planar). Check with David Beem, as he's been sniffing at this again.
Mostly stolen from Peter's pages:
http://www.gilanet.com/David/Interrupts/PlanarID.html.
David
Da...@gilanet.com
Unal Z
> I am looking for original IBM (and OEM) stuff as well as clone
> machines of the Eighties und early Nineties. Many of the old and
> not so compatible ones had non-standard IDs - this is interesting
> to some people who still write software for older systems.
Hmm ... the machine ID alone won't suffice, and if they still write that
software, in assembler presumably, they will have to know how to identify
the machine and be aware of the differences.
This one below may have been already "undocumented", but anyway:
ListFile: mov ah,60h ;Add the drive and path to
mov si,bp ;the file name by calling
add si,30 ;undocumented MS-DOS
mov di,offset FileName ;function 60h
int 21h
(seen in a MS sample code).
--
Unal
Tim Clarke
> > > You may wish to Google Search this group for additional
> > > "Information Panel" I/O port and BIOS support interrupt
> > > function information, "VPD" and/or "POS SubAddress" details.
> > > You may find many additional snippets of highly interesting
> > > information for "the next Edition".
> >
> > Yup, this sounds interesting, indeed. Any direct links or so
> > to cut down the necessary time for sorting and processing?
> > Or even better, is someone volunteering to pre-compile the
> > stuff into semi-RBIL style?
See:
<http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&newwindow=1&q=Int+1
5h&btnG=Google+Search&meta=group%3Dcomp.sys.ibm.ps2.hardware>
for additional "later model" BIOS Int 15h (AH=0Cxh+) functions.
NOTE: the "Model 90, 95, Server 95" columns refer to the three planar id.s
previously described:
Planar Ids. FF6F (Model 90) FF9F (Model 95[XP]) and E4FE (Server 95[A] and
PC Server 500), respectively. The "--", not applicable, entries show that
*only* Type-4 complexes may be used in the E4FE planar.
> > > Processor Board Submodel Value
> > > Type Description Model 90 95 Server 95
> > >
> > > 1 25MHz i486DX . . . . . . . . . . . . 11 14 --
> > > 1 33MHz i486DX . . . . . . . . . . . . 13 16 --
> > > 3 50MHz i486DX (Enhanced) . . . . . . 29 28 --
> > > 1 50MHz i486DX (Original) . . . . . . 2B 2A --
> > > 1 20MHz i486SX . . . . . . . . . . . . 2D 2C --
> > > 1 20MHz i486SX w/ 20MHz i487SX . . . . 2F 2E --
> > > 1 33/66MHz i486DX2 (Original). . . . . 37 36 --
> > > 2 25/50MHz i486DX2 . . . . . . . . . . 3F 40 --
> > >+ 4 33/66MHz i486DX2 (Enhanced). . . . . 43 42 44
> >
> > Ah, a completely "new" one. Fits in nicely in the gap. :-)
> >
> > >#@4 Pentium-60, -66, -90 . . . . . . . . 45 46 47
> > > 2 25MHz i486SX . . . . . . . . . . . . 57 58 --
> > > 2 25MHz i486SX w/ 25MHz i487SX . . . . 59 5A --
> > > 2 25MHz i486SX w/ 25/50MHz ODP486SX . 5B 5C --
> > >
> > > | Added information for the Type 4 card
> > > + Added information for the Type 4 DX2-66 card
> > > # Added information for the Type 4 Pentium-66 and -90 cards
IBM PC Server 720:
Model-SubModel: F8FD
Latest BIOS revision level: 14 (0Eh?)
Planar Id.:FEE7
IBM PS/2 Model 57 with Reply PowerBoard Model 56/57/76/77 planar upgrade
(using 16-bit 5-slot riser).
Model-SubModel: F80F
BIOS revision level: 0 (00h)
Planar Id. 0F76
David L. Beem
> IBM PS/2 Model 57 with Reply PowerBoard Model
> 56/57/76/77 planar upgrade (using 16-bit 5-slot riser).
> Model-SubModel: F80F
> BIOS revision level: 0 (00h)
> Planar Id. 0F76
on the agenda? I've not been progressing on the Industrial systems Planar
IDs.
Otherwise, I am looking for these Planar IDs too (Thanks to Tam Pham for
the pictures):
http://www.tampham.com/madmax/pics/planars/reply55pb.jpg
http://www.tampham.com/madmax/pics/planars/reply80.jpg
Any other non-IBM/non-Reply MCA planars
Updated at http://www.gilanet.com/David/Interrupts/PlanarID.html.
David
Da...@gilanet.com
Tim Clarke
> > IBM PS/2 Model 57 with Reply PowerBoard Model
> > 56/57/76/77 planar upgrade (using 16-bit 5-slot riser).
> > Model-SubModel: F80F
> > BIOS revision level: 0 (00h)
> > Planar Id. 0F76
> Thanks. Is the Planar ID for what the 3-slot (8556/9556) riser reports
> on the agenda?
Sometime, eventually (if I can find the little devil - 3-slot riser, that
is), but not soon. Other priorities, you know?
> I've not been progressing on the Industrial systems Planar
> IDs.
> Otherwise, I am looking for these Planar IDs too (Thanks to Tam Pham
for
> the pictures):
> http://www.tampham.com/madmax/pics/planars/reply55pb.jpg
Not a chance here. BTW, I spy and Adaptec chip and no obvious SCSI
header/connector? What gives? I think someone wittered recently about
planar-upgraded Model 55s.
> http://www.tampham.com/madmax/pics/planars/reply80.jpg
That should be the Model 80 Reply *Power*Board (4 SIMM slots). Dan Kalish
has a "sick" *Turbo*Board (8 SIMM slots) upgraded Model 80. I've never had
one of either.
> Any other non-IBM/non-Reply MCA planars
>
> Updated at http://www.gilanet.com/David/Interrupts/PlanarID.html.
Good to know.
--
Cheers,
Tim
Tim Clarke
P.S. the PC Server 720 has seven shared PCI/MCA slots (either/or) and seven
Memory/CPU CBus-II slots .
--
Cheers again,
Tim
Tim Clarke
> > IBM PS/2 Model 57 with Reply PowerBoard Model
> > 56/57/76/77 planar upgrade (using 16-bit 5-slot riser).
> > Model-SubModel: F80F
> > BIOS revision level: 0 (00h)
> > Planar Id. 0F76
>
> Thanks. Is the Planar ID for what the 3-slot (8556/9556) riser reports
> on the agenda? I've not been progressing on the Industrial systems Planar
> IDs.
'Fraid you're SOL there, I only have a 32-bit 3-slot (9576) riser, which is
expressly "Verboten" in the doc.s. Unless someone want to send me the pukka
Reply 32-bit risers and/or a 9556 riser. Or perform the dirty deed for
David.
--
Cheers,
Tim
David L. Beem
> > Is the Planar ID for what the 3-slot (8556/9556) riser reports
> > on the agenda?
> which is expressly "Verboten" in the doc.s. Unless someone want
I've got a spare 8556/9556 riser.
David
Da...@gilanet.com
Tim Clarke
> > > to cut down the necessary time for sorting and processing?
> > > Or even better, is someone volunteering to pre-compile the
> > > stuff into semi-RBIL style?
IBM PC Server 320/520 MCA/PCI (Micronics OEM planar, Intel Neptune 430NX
chipset):
Model-SubModel: F83B
Latest BIOS revision level: 02 (Version 29A)
Planar Id.:FEBE (Unknown to QCONFIG)
e.g. 8640-S0Y (PC Server 320) and 8641-SMZ (PC Server 520).
Cheers,
Tim
Tim Clarke
> > > > to cut down the necessary time for sorting and processing?
> > > > Or even better, is someone volunteering to pre-compile the
> > > > stuff into semi-RBIL style?
>
> IBM PC Server 320/520 MCA/PCI (Micronics OEM planar, Intel Neptune 430NX
> chipset):
Changes
Model-SubModel: F83B - PC Server 320/520 (early BIOSes) PC Server 520
(latest BIOS)
Model-SubModel: F83A - PC Server 320 (latest BIOS)
> Latest BIOS revision level: 02 (Version 29A)
> Planar Id.:FEBE (Unknown to QCONFIG)
>
> e.g. 8640-S0Y (PC Server 320) and 8641-SMZ (PC Server 520).
--
Cheers,
Tim
Tim Clarke
Given the lack of other offers, would you care to send it to me?
--
Cheers,
Tim
David L. Beem
> > I've got a spare 8556/9556 riser.
> Given the lack of other offers, would you care to send it to me?
remainder of my Army Reserve annual training (one week) during the day &
then 5 hours a night at my civilian job. We've got drill on this weekend, so
it may be after Saturday.
David
Da...@gilanet.com
Tim Clarke
Not a problem, as you may imagine I've a thousand things to be done in the
meantime.
--
Cheers,
Tim
