As a follow-up to a back-channel discussion with Louis, here is a short
primer on how the ROM-resident Stage 1 POST handles the IML process.


*Introduction*
==============

I'll focus primarily on the Type 1 Complex here, but the presented
information applies to most, if not all, other IML-based PS/2s. Some
parts also apply to the flash-based (non-IML) systems that use a
modified version of this process to locate the Reference/Convenience
partition.

First of all, there are two major versions of the POST IML procedure:

1) The original implementation can only load an IML image from a floppy
drive or the first hard drive (limited to 1GB). The T0, early T1, and
early T2 complex ROMs use this method.

2) The later implementation, sometimes called "search IML," is more
flexible and can acquire the IML image from any SCSI hard drive (limited
to ~4GB) or from a floppy drive. This is used by the "enhanced" T1 and
T2 ROMs and the T3 complex ROM.

All T1 system ROMs contain IBM SCSI extensions consisting of the
"standard" Int 13 routines and a proprietary Int 4Bh func. 80h - "IBM
SCSI interface." This iface provides extended SCSI services, incl. SCB (Subsystem Control Block) support.


*The Original Implementation*
=============================

While the advanced SCSI features are present even in the old T1 ROMs,
the POST/IML code does not reference them.

The IML routine starts by checking the first floppy drive for a
compatible IML record. If this succeeds, the Stage 1 POST ends by
calling the boot sector (which then loads the IML image file from the
disk, etc.).

If the floppy method fails, POST checks the planar ID to identify the
machine and decide how to continue. If it detects the Model 90 planar,
it installs the embedded ESDI BIOS extensions and uses the Int 13h
routines to check for an IML record on the first DBA ESDI drive. [Yes,
it should be possible to IML from a DBA ESDI drive on an early Model 90
with one of the "non-enhanced" T1 BIOS ROMs. The same is true for the T0 complex, where the ESDI install happens unconditionally - no planar ID
check is needed since it was only available with Model 90. It's another question whether the system programs can install the IML partition on an
ESDI drive in the first place.] If the ESDI BIOS installation doesn't
finish successfully (no drives?), or if it fails to adjust the reference partition "fencing" (by using somewhat proprietary Int 13h func. 1Fh
calls), it moves on to the SCSI subsystem.

The IML routine code allocates EBDA block for SCSI variables, and if not already present in memory, it installs the embedded SCSI ROM extensions.

If ESDI or SCSI was successfully initialized, the POST uses the standard
Int 13h iface to read the first three sectors of the system partition
from the first hard drive. If a compatible IML record is found, POST
Stage 1 ends by calling it.

If the hard drive IML load fails, the system re-checks the floppy drive
for an IML record. If not found, the system prints an IML error and
finally halts.


*The Enhanced Implementation w/ Search IML* ===========================================

The revised IML differs right from the get-go. It begins by allocating
the SCSI EBDA block and installing the SCSI extensions (if they weren't installed previously). If this completes successfully, POST uses the proprietary Int 4Bh SCSI iface to determine how many drives are
installed and what type they are. Usable drives are then checked for a reference partition. This differs from the original implementation,
where the floppy and ESDI drives are checked first. In fact, ESDI
extensions are entirely missing from the "enhanced" ROMs.

POST then finally checks the first floppy for a compatible IML record,
and if it finds one, it ends by loading it.**

If that fails, it proceeds by checking the previously detected SCSI
drives for compatible records.** SCB calls are used to remove the IML
partition "fencing" (unlike the original implementation that used Int
13h func 1Fh calls to achieve this).

If the SCSI method doesn't succeed, it falls back to the floppy
subsystem (like in the original implementation), checks for IML there,
and if even that fails, it prints an IML error and halts.

(** Note: I don't have that part of the code fully reversed yet, but I
think this revised IML routine not only skips incompatible IML records
but also looks for the latest IML revision across all drives.)


*Conclusion*
============

As you can see, IBM used proprietary BIOS functions in the IML code.
That is the main reason why the process fails on non-IBM controllers.

The original IML implementation relies largely on standard BIOS calls
but uses a few undocumented functions - namely, the Int 13h func. 1Fh
calls used to manipulate the IML fencing.

The "enhanced" method depends heavily on IBM-proprietary interfaces -
Int 4Bh and SCB, moving even further away from what was considered
"standard." On the other hand, these new interfaces no doubt simplified
the implementation of the otherwise relatively complex "search IML"
system. They may also be behind the raised IML drive capacity limit
(I'll look into it...).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Does the T0 do a planar ID check? If not, does that mean installing in a
Model 95 is not easy?

Tomas Slavotinek wrote:

If it detects the Model 90 planar, it installs the embedded ESDI BIOS extensions and uses the Int 13h routines to check for an IML record on
the first DBA ESDI drive. [Yes, it should be possible to IML from a DBA
ESDI drive on an early Model 90 with one of the "non-enhanced" T1 BIOS
ROMs. The same is true for the T0 complex, where the ESDI install
happens unconditionally - no planar ID check is needed since it was only available with Model 90.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28.12.2022 23:09, Louis Ohland wrote:

Does the T0 do a planar ID check? If not, does that mean installing in a Model 95 is not easy?

Tomas Slavotinek wrote:

If it detects the Model 90 planar, it installs the embedded ESDI BIOS
extensions and uses the Int 13h routines to check for an IML record on
the first DBA ESDI drive. [Yes, it should be possible to IML from a
DBA ESDI drive on an early Model 90 with one of the "non-enhanced" T1
BIOS ROMs. The same is true for the T0 complex, where the ESDI install
happens unconditionally - no planar ID check is needed since it was
only available with Model 90.

The T0 doesn't check the planar ID before calling the ESDI init. But
this shouldn't cause any trouble. It's just... unnecessary step.

There is a planar ID check in the T0 "minus" IML code, but it relates to
the ROM-resident Stage 2 POST that is exclusive to the 256K T0- ROM.
(but that code path seems to be bugged anyway...)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28.12.2022 20:50, Tomas Slavotinek wrote:

All T1 system ROMs contain IBM SCSI extensions consisting of the
"standard" Int 13 routines and a proprietary Int 4Bh func. 80h - "IBM
SCSI interface." This iface provides extended SCSI services, incl. SCB (Subsystem Control Block) support.

The "non-enhanced" T1 and T2 IML code doesn't even register the Int 4Bh handler... despite it being available. But that's not surprising I
guess, since it doesn't need it. Stage 2 POST or the standalone SCSI ROM
may still install the handler (and probably do so).

One difference between the "non-enhanced" T1 and T2 ROMs is that the T2
lacks the ESDI code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The original IML implementation relies largely on standard BIOS calls
but uses a few undocumented functions - namely, the Int 13h func. 1Fh
calls used to manipulate the IML fencing.


1) The original implementation can only load an IML image from a floppy
drive or the first hard drive (limited to 1GB). The T0, early T1, and
early T2 complex ROMs use this method.


All T1 system ROMs contain IBM SCSI extensions consisting of the
"standard" Int 13 routines and a proprietary Int 4Bh func. 80h - "IBM
SCSI interface." This iface provides extended SCSI services, incl. SCB (Subsystem Control Block) support.


The IML routine code allocates EBDA block for SCSI variables, and if not already present in memory, it installs the embedded SCSI ROM extensions.

If ESDI or SCSI was successfully initialized, the POST uses the standard
Int 13h iface to read the first three sectors of the system partition
from the first hard drive. If a compatible IML record is found, POST
Stage 1 ends by calling it.

If the hard drive IML load fails, the system re-checks the floppy drive
for an IML record. If not found, the system prints an IML error and
finally halts.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oops, good thing I searched the definition... I DIMMly remembered a book
title from the early 70s...

The original IML implementation relies largely on standard BIOS calls
but uses a few undocumented functions - namely, the Int 13h func. 1Fh
calls used to manipulate the IML fencing. The original implementation
can only load an IML image from a floppy drive or the first hard drive
(limited to 1GB). The T0, early T1, and early T2 complex ROMs use this
method.

Question - 1GB -or- 1,023KB? I remember trying a Fujitsu full height F/W
SCSI drive with 1,024KB (From Hi Tech Cafe). My 8595-0KF and a high
priced Corvette were not having it. Peter sendt me a pair of enhanced T1 complex BIOS chips (one to use, one to lose), and it fired up.

Ah, the Corvette of a high price. Turns out that Caroll Bloyd and I were fighting over it. I beat him with $150, IIRC.


All T1 system ROMs contain IBM SCSI extensions consisting of the
"standard" Int 13 routines and a proprietary Int 4Bh func. 80h - "IBM
SCSI interface." This iface provides extended SCSI services, incl. SCB (Subsystem Control Block) support.

Question - does Int 4Bh func. 80h - "IBM SCSI interface" actually have
any documentation, or is this moniker a SWAG?

Question - The non-enhanced use the Int13 Funct 1Fh to manipulate the
IML fencing. "All T1 system ROMs contain IBM SCSI extensions" that
"provides extended SCSI services, incl. SCB". So SCB is there, but not
used, or does the early BIOS SCB support lack the SOS Max_LBA that the
enhanced BIOS uses to fence the IML partiton?

The IML routine code allocates EBDA block for SCSI variables, and if not already present in memory, it installs the embedded SCSI ROM extensions.

Question - "embedded SCSI ROM extensions" from what? The complex BIOS?
The IBM SCSI controller?

Question - for systems with on-board SCSI, like the Bermuda, can we stop
the IML process from loading the whatever for the SPOCK and then load a Corvette's code or whatever, instead? Something akin to that would be a
P75, with a Corvette as the sole SCSI controller... Sure, the P75 is not
IML, but the system loads the 8032 based SCSI first, and won't let a
Corvette lay rubber...

If ESDI or SCSI was successfully initialized, the POST uses the standard
Int 13h iface to read the first three sectors of the system partition
from the first hard drive. If a compatible IML record is found, POST
Stage 1 ends by calling it.

If the hard drive IML load fails, the system re-checks the floppy drive
for an IML record. If not found, the system prints an IML error and
finally halts.

NOTE: The "non-enhanced" T2 ROM lacks the ESDI code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29.12.2022 14:44, Louis Ohland wrote:

Question - 1GB -or- 1,023KB? I remember trying a Fujitsu full height F/W
SCSI drive with 1,024KB (From Hi Tech Cafe). My 8595-0KF and a high
priced Corvette were not having it. Peter sendt me a pair of enhanced T1 complex BIOS chips (one to use, one to lose), and it fired up.

I'm not sure where exactly the limit comes from, not yet anyway. The
Tool says 1,023 MB.

Question - does Int 4Bh func. 80h - "IBM SCSI interface" actually have
any documentation, or is this moniker a SWAG?

The Int 4Bh interface is officially called "Advanced Services" and func.
80h is "SCSI Devices".

Most of it is documented in the BIOS techref (page 157 physical): https://ardent-tool.com/docs/pdf/ps2bios2.pdf#page=157

The "IBM SCSI interface" moniker came from RBIL: http://www.ctyme.com/intr/rb-6261.htm
(nothing to see there)

Question - The non-enhanced use the Int13 Funct 1Fh to manipulate the
IML fencing. "All T1 system ROMs contain IBM SCSI extensions" that
"provides extended SCSI services, incl. SCB". So SCB is there, but not
used, or does the early BIOS SCB support lack the SOS Max_LBA that the enhanced BIOS uses to fence the IML partiton?

Yes, the IBM SCSI BIOS extensions are present in all processor complex
ROMs (T0-T4). And in all cases it implements not only the standard Int
13 interface, but also Int 4Bh (including, SCB, SOS, and Max LBA).

The "non-enhanced" ROMs don't use the Int 4Bh interface for anything and therefore don't even bother registering it.

Question - "embedded SCSI ROM extensions" from what? The complex BIOS?
The IBM SCSI controller?

The complex ROM.

Question - for systems with on-board SCSI, like the Bermuda, can we stop
the IML process from loading the whatever for the SPOCK and then load a Corvette's code or whatever, instead? Something akin to that would be a
P75, with a Corvette as the sole SCSI controller... Sure, the P75 is not
IML, but the system loads the 8032 based SCSI first, and won't let a
Corvette lay rubber...

The SCSI BIOS extensions are compatible between all IBM SCSI adapters as
far as I know. So they are registered only once for all adapters. But
each adapter gets its own EBDA block...

The IML code doesn't scan for SCSI adapters, that's done earlier on
(during the Stage 1 ROM scan I assume). I'm not sure how that code works
on the P75. I don't have one and the P75 system ROM isn't available either.

I could maybe check Bermuda's ROM to see what's up. But I dunno if it's
any similar to the P75 one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(nothing to see there)

IBM SCSI interface

AH = 80h
AL = 00h-10h (Corel PowerSCSI INT4BCAM.SYS)
further details not yet available

The IBM SCSI interface moniker came from RBIL:

http://www.ctyme.com/intr/rb-6261.htm

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Boring, nothing flashy.

Most of it is documented in the BIOS techref (page 157 physical): https://ardent-tool.com/docs/pdf/ps2bios2.pdf#page=157

Interrupt 13H—Fixed Disk
This interface provides access to fixed disk drives. The following is a
summary of the fixed disk functions of Interrupt 13H.
(AH) = 00H — Reset Disk System
(AH) = 01H — Read Status of Last Operation
(AH) = 02H — Read Desired Sectors into Memory
(AH) = 03H — Write Desired Sectors from Memory
(AH) = 04H — Verify Desired Sectors
(AH) = 05H — Format Desired Track
(AH) = 06H — Format Desired Track and Set Bad-Sector Flags
(AH) = 07H — Format Drive Starting at Desired Cylinder
(AH) = 08H — Read Drive Parameters
(AH) = 09H — Initialize Drive Pair Characteristics
(AH) = 0AH to OBH — Reserved
(AH} = 0CH — Seek
(AH) = 0DH — Alternative Disk Reset
(AH) = 0EH to 0FH — Reserved
(AH) = 10H — Test Drive Ready
(AH) = 11H — Recalibrate
(AH) = 12H to 14H — Reserved
(AH) = 15H — Read DASD Type
(AH) = 16H to 18H ~ Reserved
(AH) = 19H — Park Heads
(AH) = 1AH to 20H — Reserved
(AH) = 21H — Read Multiple Sectors into Memory
(AH) = 22H — Write Multiple Sectors from Memory
(AH) = 23H — Reserved
(AH} = 24H — Set Multiple Mode
{AH) = 25H — Identify Drive
(AH) = 26H to FFH — Reserved

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Int 4Bh interface is officially called "Advanced Services" and func.
80h is "SCSI Devices".

(AH) = 80H—SCSI Devices
These BIOS services are intended for use by device drivers.
Application programs should use operating-system interfaces to
access small computer system interface (SCSI) devices.

The following is a summary of the SCSI functions.
(AH) = 00H — Get Device Count (page 2-IN4B-3)
(AH) = 01H — Get Device Data (page 2-IN4B-4)
(AH) = 02H — Allocate Device (page 2-IN4B-4)
(AH) = 03H — Deallocate Device (page 2-IN4B-5)
(AH) = 04H — Send Device SCB (page 2-IN4B-5)
(AH) = 05H — Send Device Immediate (page 2-IN4B-8)
(AH) = O6H — Reset Adapter (page 2-IN4B-8)
(AH) = 07H — Set Time-Out Value (page 2-IN4B-9)
(AH) = 08H to FFH — Reserved

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)