Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.ibm.ps2.hardware > #71497
| 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) |
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
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