Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.ibm.ps2.hardware > #71497

What, exactly, do C*.ADF files on Reference Diskettes do?

From "Josh Rodd" <joshua.at.rodd.dot.us@rodd.us>
Newsgroups comp.sys.ibm.ps2.hardware
Subject What, exactly, do C*.ADF files on Reference Diskettes do?
Date 2026-08-02 23:43 +0000
Organization csiph.com Internet News Service
Message-ID <6a6fd627.2dd4c08ddfcefa6f@csiph.com> (permalink)

Show all headers | View raw


As many seekers of PS/2 wisdom already know, many IBM options have an
executable C*.ADF file (e.g. @8EFE.ADF has a companion C8EFE.ADF). This
file has a quite simple format: it first has an MZ header, and inside
that, it just contains an executable identical to a .COM program...
entry point at 100h, single combined code/data, & expected to be called
with a stack. So far, so good.

SC.EXE provides some kind of rather complex API where it will both call
out to these programs (I believe the C stands for Card; there are also
S*.ADF files, which are for the System Planar, and are companions to the
P*.ADF files, which must stand for Planar. So you'd find SFDFF.ADF and
PFDFF.ADF for a Model 80.)

The API is overly complex, but the effect is quite clear: one of these
programs gets to hook the entire Automatic Configuration process. Let's
go over what a Type 2 PS/2 Model 80 with a WD8013PE/A Ethernet card, 2
ESDI adapters and 3 SCSI adapters in it does, with version 1.21 of the
Ref. Disk:

- The System Planar program checks the registers for the installed
planar memory and decides if 1 or 2 modules are installed, and then
reports back to expect 2MB or 4MB memory appropriately.

- The Ethernet card doesn't have a C.ADF program. It automatically
assigns CC00-CFFF for that card's shared ROM. The card's ROM is disabled
by default.

- The ESDI adapter automatically places its ROM segment before any SCSI
adapter segments. I am guessing it does this so that ESDI drives are
always C: before any SCSI drivers. The end user doesn't get to choose
where the ROM segment is, although they could with a slightly altered
@.ADF file and removal of the C.ADF file.

It assigns D000-D3FF for its ROM and DMA 5. It bears I/O ports
3510h-3517h as fixed resources.

- The second ESDI adapter runs the same logic and assigns its ROM to
D400-D7FF and DMA 6. It ends up with an I/O port conflict since the I/O
ports can't be reassigned. Two ESDI adapters isn't a supported
configuration (hence why they didn't bother finding a way to share ROM).

- The SCSI adapter's C.ADF checks all installed SCSI adapters. It
inspects the revision of ROM on each one, and prefers the first one it
finds with a 1991 ROM. If it doesn't find an 1991 ROMs, it picks the
first one with a 1990 ROM. All the other SCSI adapters will have their
ROM disabled. They end up with I/O levels 3540h, 3548h, and 3540h, and
DMA 12, 13, and 14.

Of note is that it seems to assign ROM "backwards", that is, going from
the top-down. In my above example, C000-CBFF is free.

Of note is that the Type 2 Model 80 has no fixed disk ROM in it at all,
ST-506/MFM/RLL, ESDI, integrated ESDI, SCSI, or otherwise, in my
preliminary findings so far.

Stay tuned...

https://i.imgur.com/5dlTGIB.png

Back to comp.sys.ibm.ps2.hardware | Previous | Next | Find similar | Unroll thread


Thread

What, exactly, do C*.ADF files on Reference Diskettes do? "Josh Rodd" <joshua.at.rodd.dot.us@rodd.us> - 2026-08-02 23:43 +0000

csiph-web