6

For example, the 8250/16550 chip used to handle serial communication is still simulated by modern chipsets and is enumerated by ACPI as PNP0500/PNP0501. You can find datasheets for these chips.

However, any information on how the chip is wired to other devices on the motherboard (e.g. to the PIC) seems to be only present on various hobbyist websites, I can't find anything official.

Where do I find such documentation?

Edit: I want to clarify my question. I understand that discrete chips aren't used for simple functions anymore. However, for compatibility, the hardware must still look the same from the software perspective. If I stay with the 8250 example, the chip has modem signal outputs, like DTR and RTS, but it also has two general-purpose outputs, OUT1 and OUT2. On ATs, OUT2 controlled a gate that enabled/disabled the connection between the INTR output of 8250 and the IRQ4 input of the PIC. As such, OUT2 served as master enable for the UART interrupts.

This is what I meant by wiring. Although there is no external wiring for modern chipsets, if the chipset emulates the old UART and enumerates it as PNP0500, the software must still set the (nowadays virtual) OUT2 output to enable interrupts.

Now I'd like to know where the authoritative documentation for this behavior is. Surely, an OS writer doesn't have to read the specs of all (even future) chipsets to get the driver for PNP0500 right, does he?

  • You could ask a chipset manufacturer for a datasheet. I don't know how seriously they'd take you, but as long as you weren't asking for something considered confidential I would guess they would provide it. – Jules May 7 '18 at 12:55
  • 2
    Surely, current OSes don't depend on chipset-specific knowledge. They enumerate devices from ACPI and see PNP0500 and somehow know how to use that device. Where's the specs for that device? This document says that it's "Standard PC COM port" and that's literally all the documentation I can find: download.microsoft.com/download/1/6/1/… – avakar May 7 '18 at 13:36
  • The original 8250/16550 datasheets are the "official" documentation for the software interface of these devices. These chips are no longer used so for official documentation on the hardware interfaces you need to see the datasheets for the chip they're using. Something like how a given chip is physically wired on a given motherboard isn't officially documented anywhere, as up to each implementation, but if you look at the chipset documentation you get an idea how it's likely wired. Note that info like what PIC IRQ is used is in the ACPI tables. – Ross Ridge May 7 '18 at 20:47
  • If there's any authoritative documentation on how OUT1 and OUT2 are used in AT compatible serial ports it would be IBM technical documentation for their original serial port cards. Alternatively you can try reading the datasheet for the particular Super I/O chip or compatible PCI/PCI-Express serial port chip you're using, which would be authoritative for that particular chip, and presumably describe a software interface that's compatible with IBM's original cards. For legacy hardware, OS writers don't often have the luxury of complete and authoritative documentation. – Ross Ridge May 8 '18 at 16:42
6

The authoritative documentation for the legacy PC/AT hardware is the "IBM Personal Computer Technical Reference manual", and the "IBM Personal Computer AT Technical Reference manual" These books were sold by IBM and can be found on eBay. Scans can be found online, however I don't know if IBM released the copyright. The books contain full schematics to the IBM PC and PC/AT, as well as the BIOS source code listings. The IBM machines set the de facto standard the rest of the industry copied, so when you see a reference to legacy behavior in the ACPI or UEFI specs, the original IBM manuals is as authoritative as you get.

I grabbed my copy of the manuals and verified the information you want can be found in the "IBM Personal Computer Technical Reference manual" page 1-223 through 1-250. On page 1-226 the manual explains that "bit 3 of the modem control register must be set to 1 (high)" to enable interrupts. Oddly the description of bit 3 in the MCR on page 1-245 makes no mention of this. Also on page D-88 of that same manual you will find the schematic of the original "Asynchronous Communication Adapter" which shows OUT2 (pin 31 of the 8250) connected to the gate control of a 74ls125 which blocks the INTRPT signal (pin 31 of the 8250).

5

I don't think that there is a definitive ISA document: manufacturers generally went with "whatever the PC/AT had." Looking at older computers which still have an ISA architecture, Super I/O chipsets (typically from the BIOS manufacturer) handled a lot of the glue logic, so discrete chips were already disappearing from the boards, probably as early as the late 1980s.

On modern boards, the LPC bus specifies a limited number of ISA-compatible devices (super I/O, audio, and some controllers) which are software-compatible with ISA but not hardware compatible. Here's an example from ITE (don't worry about the "CONFIDENTIAL" watermark: I got it from their Web site.)

So in short, for almost the past 30 years the number of actual chips on the motherboard to support the ISA bus has dropped from dozens to possibly just one (or zero for UEFI-only) computers. It's not because it's a secret, but just because there's not much left to document.

4

ISA bus documentation is very vague and is mostly defined by a mix of the original PC/XT/AT schematics and 8288 / 82288 bus controller provided by Intel.

There was never an "official" timing diagram from IBM for either the PC or AT buses (I remember having to work out the best/worst case timings for the SBHE signal from the individual chips datasheets and the AT schematics). How hardware was connected to the bus originally was defined by the adapter schematics provided in the technical references.

Locations of devices in the IO space usually copied the IBM version with maybe an alternative address which was in a typically free space.

Going back to your example card for the "IBM Asynchronous Communications Adapter" the XT technical reference says this on page 1-218:

"One Interrupt line is provided to the system. This interrupt is IRQ4 for a primary adapter or IRQ3 for an alternate adapter, and is positive active. To allow the communications card to send interrupts to the system, bit 3 of the modem control register must be set to 1 high. At this point, any interrupts allowed by the interrupt enable register will cause an interrupt."

So the behaviour in this case comes from the original PC design.

Oh and PC bus designs ran at various speeds depending on the OEM/Chipset. I had very cheap AT clone that ran the bus at 12MHz (it's usually 6 or 8MHz for an AT) which was useful when testing other hardware for compatibility.

0

In modern PCs, various legacy devices are implemented within the Southbridge chip, or possibly a SuperIO chip alongside it, or occasionally even on the CPU die. There are therefore no actual wires connecting them to anything.

IIRC, the ISA bus was originally just the 8086's main data bus brought out to expansion slots, so some of the interface on original hardware was specified by the 8086's datasheet. Some of the cards you could put in those slots were RAM expansions. Later PC-compatible CPUs got a lot faster, so an interface chip had to be inserted to buffer the ISA bus from the actual memory bus, and later the PCI bus.

Some of the best documentation of these devices exists in the form of the Linux kernel's device driver source code. Some of them also have actual, conventional documentation there.

  • Thanks for the answer, I might have phrased the question too vaguely, could you have a look at my edit? – avakar May 8 '18 at 10:27
0

For example, the 8250/16550 chip used to handle serial communication is still simulated by modern chipsets and is enumerated by ACPI as PNP0500/PNP0501. You can find datasheets for these chips.

However, any information on how the chip is wired to other devices on the motherboard (e.g. to the PIC) seems to be only present on various hobbyist websites, I can't find anything official.

Simple: There can't be any, as they are emulated.

The whole idea of an emulation is to hide the real implementation, thus enabling the manufacturer to improve implementation and internal working. Otherwise they would need to implement outdated (internal) Interfaces over and over.

Where do I find such documentation?

If at all, check with each chip manufacturer.

It wasn't an issue while chipsets still supported ISA - but already back then Intel implemented the LPC (Low Pin Count) Interface (Specs here) to cut down on wiring cost. It laid out a de-facto standard during the 2000s and can still be found on several CPUs.

Nowadays it's eventually all replaced by USB.


Regarding the Edit:

I'm not really sure what you're asking for. As the function is emulated by hard or firmware, one can still access the same registers and bits (at least on OS privilege level). Of course, it depends how deep the emulation goes.

And yes, OS developers do have to read each spec of new CPUs and chipsets. After all, how else are new drivers to be developed?

Last but not least, the PNP0500 driver you mention is some Windows specific thing, not really a hardware issue.

  • Thanks for the answer, I might have phrased the question too vaguely, could you have a look at my edit? – avakar May 8 '18 at 10:27
  • PNP0500 is not Windows-specific thing, that's the id of 8250-compatible devices when enumerated by ACPI. – avakar May 8 '18 at 18:02
  • Ofc it's windows specific, as is everything that gores beyond basic power management in ACPI - After all,beingWindows only was one of the main design goaly for ACPI: antitrust.slated.org/www.iowaconsumercase.org/011607/3000/… – Raffzahn May 8 '18 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.