Many users are having trouble installing 5.25" IBM OS/2 1.1 on 386 clones
having the Phoenix 386 BIOS. The symptom is characteristic: the installer
program starts to copy files, and then aborts because the XXXXX02.SYS files
are missing. Experienced OS/2 users will notice that the installer "thinks"
your 386 clone is a PS/2 machine (which it isn't) instead of a PC-AT clone
(which it is, at least as far as OS/2 1.1 is concerned).

The reason this situation arises is because of an interaction between IBM's
brain-damaged installer script (SYSINST.PIP) and an unfortunate choice of
submodel bytes by Phoenix Technologies. The installer script has a subroutine
designed to sort through the FCh models, which includes both the PC-AT and
80286-based PS/2 models. The routine follows typical "not invented here"
logic: if the submodel number reported by your machine is NOT among those used
by valid IBM PC-AT (or PC-XT/286) models (i.e. 00h, 01h, 02h, 06h, or 09h), it
assumes you have an as-yet unreleased PS/2 model and proceeds to copy the
PS/2-specific files. Since IBM doesn't MAKE a PS/2 model having a 5.25" A:
drive ("not invented here"), they don't even include those files on the 5.25"
disks! Hence, a fatal error results during the installation.

This is compounded by a terribly unfortunate choice by Phoenix. Every other 386
BIOS set made (including Compaq's, which is the "standard") reports itself as
a model FCh, submodel 01h (PC-AT 339). For some reason, Phoenix uses submodel
numbers of 03h and 81h in its 386 BIOS sets. Hence, the fatal interaction,
since NEITHER of these is among the list of valid IBM PC-AT models.
Phoenix maintains that an OEM is free to request any submodel bytes it
wishes. But most simply go with the default offering, and are not even
AWARE of how bizarre the defaults really are!

Fortunately, the offending subroutine is written in ASCII text and can
therefore be easily patched by the end-user. Instead of fixing their BIOS,
Phoenix supplies an "advisory" on how to patch the SYSINST.PIP file. For
greatest clarity, I have reproduced several lines of that code, with line
numbers added, and the required patches marked as "ADD:". This file is
on the installation disk. Make a COPY of the original disk and apply the
following patches to SYSINST.PIP using an ASCII text editor:

50 ESELECT
51 :MDL252
52 SELECT %SUBMDL%
53 WHEN 00 SET PCTYPE=1
54 WHEN 01 SET PCTYPE=1
55 WHEN 02 SET PCTYPE=1
56 WHEN 06 SET PCTYPE=1
57 WHEN 09 SET PCTYPE=1
ADD: WHEN 03 SET PCTYPE=1
ADD: WHEN 81 SET PCTYPE=1
58 SET PCV=1
59 OTHERWISE SET PCTYPE=2
60 ESELECT

End-users having access to EPROM burners can attack the problem directly by
patching the offending BIOS code. The ROM BIOS equipment table can be found
through an INT 15h call. Following the IBM standard, Phoenix has placed it in
the same place as the AT-339. It typically begins at F000:E6F5 (64K BIOS
having setup program) or F000:66F5 (32K code without setup program).

Looking at a typical 64K Phoenix 386 BIOS, one would see at this location:

F000:E6F5 08 00 FC 81 00 70
^
|
OFFENDING
BYTE

To make the Phoenix code match that of Compaq, Award, AMI, DTK, and everyone
else that writes a 386 BIOS, patch the "81" to read "01". However, this will
cause a ROM checksum error unless a compensation is made prior to burning
the ROM.

Newer Phoenix code contains internal anti-modification routines. Changing
the "even-out byte" at F000:FFFF may not work. I have found it easiest to
simply patch an "unused" byte further down in order to compensate. The area
of memory just above this region is typically unused; i.e. filled with FFh,
and so is quite suitable for this purpose. We can therefore even out the
internal checksum by changing a nearby FFh to 7Fh. For instance, in my BIOS
set I changed the submodel number by patching F000:E6F8 (an even byte) from
81h to 01h. To compensate, I patched F000:E7F8 (another even byte) from FFh
to 7Fh. This restores the proper internal checksum painlessly, and does not
produce an error.

Patching the ROM BIOS will allow installation of present and future versions
of OS/2 without modification, and will correct "unknown model number" errors
from utility programs that attempt to identify your computer by examining
the ROM BIOS.