3 ms·

As I understand it, the 8086 has a separate address space for io. As in, memory address $3f8 is just a RAM location and not the same thing as the base register

As I understand it, the 8086 has a separate address space for io. As in, memory address $3f8 is just a RAM location and not the same thing as the base register of the COM1 serial port. This is unlike 1980's home computers that use a 6502, where things like the keyboard interface appear to be just another memory location from software. Is there anything interesting related to how that is handled in hardware?

kens 4y ago
The 8086 inherited the separate I/O space from the Datapoint 2200, a "programmable terminal". Since the Datapoint 2200 had a custom TTL processor, it was convenient to build in instructions to manipulate its I/O hardware directly. It doesn't make as much sense for a general-purpose microprocessor, which is why the 6502 etc didn't follow that approach. (Separate I/O instructions make sense in something like the IBM System/360 mainframes, where they were executed by a separate channel controller and gave you more performance.) As far as the implementation of I/O in the 8086 chip, I haven't come across anything particularly interesting yet. It's essentially the same bus state machine as memory, except it signals an I/O access rather than a memory access.
- controversial97 4y ago
  Is there an output from the instruction decoder that indicates an instruction is doing io? or maybe one for read and one for write?
  - kens 4y ago
    Yes, there's an output from the Group Decode ROM that indicates the instruction is an IN or OUT instruction. This causes the M/IO line to signal an I/O operation rather than a memory operation.
ajross 4y ago
To the 8086 hardware, the "IO Space" is a single line[1] on the bus, essentially a 21st address bit. When that is set, the "memory-like" devices know to ignore the transaction and "io" devices know to decode the address. At the software level, it's accessed by different instructions. Instead of MOV with a memory location, you use IN or OUT. And notably those instructions take only a 16 bit address and no segment selector, so IO space is limited to 64kb. Also note that to the IBM PC, IO space was routinely truncated to just 10 bits. I honestly don't know if that was ever standardized or not, but that's the way production devices and chipsets have always worked. The extra address lines never worked, and generally aliased with devices in the bottom of the space that were ignoring the top bits. [1] Actually it's multiplexed in a group of 8 bus states addressed by three lines, because Intel was stingy about pins. But logically it's an extra address line. [This is the spot where I repeat my request to Ken to please do a blog post on the insane bus management on this device, which I'd dearly love to see.]
- kens 4y ago
  > please do a blog post on the insane bus management on this device I'm working on it, but it's a difficult topic. The bus management circuitry is both very complicated (a bunch of flip flops making a complex state machine full of special cases) and lacking in general concepts. So it's hard to figure out how to make it comprehensible and interesting.
  - ajross 4y ago
    Heh, no rush. But if nothing else that validates my confusion. :)
- controversial97 4y ago
  This reminds me of Chris Tarnovski criticizing some microcontroller designs because the buses run all over the die, rather than being gated by a central multiplexor, and that much capacitance and logic inputs to drive being limiting the maximum clock speed. Relevant? I'm not a cpu expert.

kens 4y ago

The 8086 inherited the separate I/O space from the Datapoint 2200, a "programmable terminal". Since the Datapoint 2200 had a custom TTL processor, it was convenient to build in instructions to manipulate its I/O hardware directly. It doesn't make as much sense for a general-purpose microprocessor, which is why the 6502 etc didn't follow that approach. (Separate I/O instructions make sense in something like the IBM System/360 mainframes, where they were executed by a separate channel controller and gave you more performance.) As far as the implementation of I/O in the 8086 chip, I haven't come across anything particularly interesting yet. It's essentially the same bus state machine as memory, except it signals an I/O access rather than a memory access.

controversial97 4y ago
Is there an output from the instruction decoder that indicates an instruction is doing io? or maybe one for read and one for write?
- kens 4y ago
  Yes, there's an output from the Group Decode ROM that indicates the instruction is an IN or OUT instruction. This causes the M/IO line to signal an I/O operation rather than a memory operation.

ajross 4y ago

To the 8086 hardware, the "IO Space" is a single line[1] on the bus, essentially a 21st address bit. When that is set, the "memory-like" devices know to ignore the transaction and "io" devices know to decode the address. At the software level, it's accessed by different instructions. Instead of MOV with a memory location, you use IN or OUT. And notably those instructions take only a 16 bit address and no segment selector, so IO space is limited to 64kb. Also note that to the IBM PC, IO space was routinely truncated to just 10 bits. I honestly don't know if that was ever standardized or not, but that's the way production devices and chipsets have always worked. The extra address lines never worked, and generally aliased with devices in the bottom of the space that were ignoring the top bits. [1] Actually it's multiplexed in a group of 8 bus states addressed by three lines, because Intel was stingy about pins. But logically it's an extra address line. [This is the spot where I repeat my request to Ken to please do a blog post on the insane bus management on this device, which I'd dearly love to see.]

kens 4y ago
> please do a blog post on the insane bus management on this device I'm working on it, but it's a difficult topic. The bus management circuitry is both very complicated (a bunch of flip flops making a complex state machine full of special cases) and lacking in general concepts. So it's hard to figure out how to make it comprehensible and interesting.
- ajross 4y ago
  Heh, no rush. But if nothing else that validates my confusion. :)
controversial97 4y ago
This reminds me of Chris Tarnovski criticizing some microcontroller designs because the buses run all over the die, rather than being gated by a central multiplexor, and that much capacitance and logic inputs to drive being limiting the maximum clock speed. Relevant? I'm not a cpu expert.