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

    From Josh Rodd@joshua.at.rodd.dot.us@rodd.us to comp.sys.ibm.ps2.hardware on Sun Aug 2 23:43:35 2026
    From Newsgroup: comp.sys.ibm.ps2.hardware

    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
    --- Synchronet 3.22a-Linux NewsLink 1.2