5 ms·

This is awesome. I miss the ISA bus and its simplicity. People raved about PCI's Plug and Play, but in practice I found it very straightforward to set IRQ jum

This is awesome. I miss the ISA bus and its simplicity. People raved about PCI's Plug and Play, but in practice I found it very straightforward to set IRQ jumpers and the experience was free of the quirky issues I encountered with PnP (especially in the early days). I recall wiring an LED display and some very simple logic (like a buffer IC or something enabled by an address line in a non-existent memory segment) directly to an ISA wire wrap card and getting it to work on the first try. One of the reasons I love working with microcontrollers (especially the relatively clean 8-bit architectures like AVR) is they lack so many layers of abstractions. One major aspect of PCI which I do respect is it's incredible backwards compatibility. I still use a 20 year old Adaptec PCI SCSI card via an adapter carrier in in my latest PC (drivers were fun but it works).

burnt-resistor 2y ago
I don't miss it because the resources and choices were extremely limited. PnP (ISA, VLB, AGP, PCI/-X, and to some degree MCA and EISA) was revolutionary because it automated the mundane.
contingencies 2y ago
My first machine was a 286, so they have a special place in my heart. It should be pointed out that the clock speed of an ATMega328P (original Arduino / Arduino nano) is nearly exactly the same as an 80286. Two of the same could easily outcompute a 286! You can buy them for ~$3 at the moment... I've put plenty of AVRs on ethernet - and once, a 386, using an ancient DOS TCP/IP stack, but never a 286. Linux doesn't support it due to requiring an FPU. It'd be fun to design the electronics for an old-style computer, but IMHO it'd be far more amusing to do it from scratch with an original architecture than try recreating a third party motherboard using a similar layout scheme. Something with parallelism and auto-scaling would be quaint.
- einr 2y ago
  I've put plenty of AVRs on ethernet - and once, a 386, using an ancient DOS TCP/IP stack, but never a 286. Linux doesn't support it due to requiring an FPU. mTCP (http://brutmanlabs.org/mTCP/ http://brutmanlabs.org/mTCP/) is a currently-maintained TCP/IP stack for MS-DOS that will run on any PC, 8088 and up. You also need a packet driver for your NIC. 286 machines are easy; nearly any 16-bit ISA NIC will work. XT-class machines are slightly trickier because not all NICs will work in 8-bit ISA slots and some packet drivers use 186/286 instructions.
- pantalaimon 2y ago
  Linux runs fine without an FPU, it even has a software emulation. It’s the hardware task switching features that the 386 introduced that it requires (and the reason why Linus got one in the first place back in the day)
  - rep_lodsb 2y ago
    Hardware task switching was introduced on the 80286. And no modern OS - including Linux, except for the earliest versions - uses it, because the way it is implemented, the mechanism will do a lot of unnecessary duplicate work (preserving "garbage" register contents from just before the kernel is about to return to user mode, and will consequently have to restore them itself). The only situation where it would be required to use this misfeature is for handling exceptions like stack overflow in the case that they can occur in kernel mode. A "Task State Segment" is really more like a pre-allocated stack frame anyway, the CPU puts active ones in a linked list and does not allow freely switching between them, only returning to the outer level. x86-64 does not have hardware task switching anymore, instead it is now possible to switch to another stack on an exception or interrupt, which is all that the TSS was used for in practice anyway.
    - actionfromafar 2y ago
      Linux started on 80386.
      - rep_lodsb 2y ago
        Where am I disagreeing with that? Hardware task switching already existed on the 16-bit 80286, and remained supported on newer generations until being finally removed in x86-64. Early versions of Linux did use it for a time, but doing it in software turns out to be faster, because the mechanism was badly designed for what a general-purpose kernel has to do.
        actionfromafar 2y ago
        Sorry, I see now that your comment could be read both ways, and my misinterpretation was actually a bit far-fetched.
- fredoralive 2y ago
  It's the lack of a "modern" paged memory management unit that's the main issue for mainline Linux on a 286 AFAIK. Nobody wants to deal with x86 segmented memory, having a nice flat addressing paged mode is one of the big wins of the 386. Although I believe Linux dropped support for 386 (and 486?) a while back so they could remove some special cases for such old chips.
  - rep_lodsb 2y ago
    Yes, paging is what is necessary to run Linux. The main problem it solves is how to allocate physical memory without having to constantly move variably-sized segments around to get rid of fragmentation. But I'm kind of sad that all OSes converged on a flat address space for the sake of ~PoRtAbIlItY~. Monocultures are bad, and we currently have one, where everything is basically a UNIX clone written in C. 32-bit x86 allowed to use both segments (of any length up to 4 GiB) and paging at the same time. Before the NX bit was introduced, this was the way to have write-xor-execute permissions. And some security features of segmentation can't be replicated at all in a flat address space: with a separate stack segment (or one with the same flat base address but a different limit), it will be impossible to add the wrong offset to a pointer to stack and get access to data that is outside of it. IMHO, the iAPX 432 had some good ideas, and x86 should have evolved in that direction, adding a few more "extra" segment registers which code can use freely as pointers to isolated objects. Each would have two "limit" fields (for negative and positive offsets from the base), with one of these spaces used for storing pointers to other objects, which can only be manipulated through CPU microcode that guarantees memory safety. Instead they eliminated segments completely in 64-bit mode, except for FS/GS serving as an extra offset that gets added with no limit checking whatsoever.
    - AshamedCaptain 2y ago
      I do agree with what you say and also have nice memories of 8086 segmentation. I find it funny that we are continuously forced to add workaround on top of workarounds to the flat address space in order to avoid accidental memory errors. Segmentation had all that decades ago, and easier debugability to begin with. But it is clear to me that we are moving again towards something like that, even if enforced at a different level.
- cesarb 2y ago
  > Linux doesn't support it due to requiring an FPU. I have used Linux on a 386SX which did not have any FPU. Linux had x87 floating point emulation for a long time (AFAIK, that emulation has since been removed, together with the rest of the support for very old CPUs). The main reasons Linux doesn't support the 80286 are AFAIK that the 80286 is a 16-bit CPU, and Linux (other than the short-lived ELKS fork) has never supported 16-bit CPUs; and that the 80286 doesn't have paging (it has only segmentation), which would require running it as a "no-MMU" CPU.
  - lproven 2y ago
    They meant MMU.
- int_19h 2y ago
  Linux doesn't support it, but https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset does.
- lproven 2y ago
  > Linux doesn't support it due to requiring an FPU. This is incorrect. FPU means "floating point unit". Linux does not need this. Few OSes do at all. You meant "MMU", meaning memory management unit. This is what Linux uses to perform virtual memory handling, and that is why Linux can't run on an 80286: the '286 had no MMU (or FPU). The difference being that 99% of computers without an FPU could just have one added. This was never true of an MMU. Indeed some early Unix machines based on CPUs with no MMU used an entire 2nd CPU just for MMU duties.
- burnt-resistor 2y ago
  Incorrect. Clock speed is not a 1:1 correlation with cycle efficiency. There are plenty of "slow" single-cycle architectures with very good cycle efficiency, and there are many architectures like the older P4 that have very poor cycle efficiency to chase the MHz wars.
toast0 2y ago
IRQ jumpers weren't too bad, but it was easy to run out of them, and not all devices could share interrupts well. PCI made IRQ sharing more accessible, but the real improvement was (in band) Message Signalled Interrupts, which allows for a much larger number of interrupts, ending sharing in most cases and also resulting in a knowable ordering between I/O and interrupts, which can eliminate the race condition between interrupt arrival and status reads/interrupt enable. The other big pains of ISA were finding working I/O assignments with lots of cards, and finding DMA channels (although ISA devices started doing their own bus mastering DMA because the motherboard DMA controllers were a fixed, slow, speed, by spec)
- einr 2y ago
  IRQ sharing on PCI came with its own pains though which were sometimes harder to diagnose and fix. In the early 2000's I was recording and mixing music with DAWs on Windows 2000 and you always had to be very careful that your PCI ASIO sound card did not share resources with anything else or you got to deal with dropouts and glitches. Plenty of futzing around in BIOS setup and Device Manager, very flaky stuff.
  - toast0 2y ago
    Definitely. Sharing was better than not being able to use your slots when you ran out of IRQs, but sharing wasn't great. The idea of wiring 4 IRQs to the slot and let the card/driver pick was good, but the reality wasn't great if your motherboard just tied all 4 to the same pin on the interrupt controller.
- rkagerer 2y ago
  but it was easy to run out of them So often in computing we've completely overhauled the stack with loads of new complexity, when simply adding more of some limited but unexpectedly popular resource would have sufficed (great example... IPv6). (Ps. Thanks for your informative reply to my comment)
  - thrw42A8N 2y ago
    How do you propose we add more IPv4? Not to mention that the IPv6 protocols are less complex than IPv4 - as they were designed after the "natural" evolution of IPv4 concluded.
p_l 2y ago
The problematic era of PnP was the ISAPNP, which was complex and prone to failure, and gave us the jokes about Plug'N'Pray
- hulitu 2y ago
  It was also because a lot of HW (soundcards mostly) had a morbid preferrence for IRQ already allocated to the parallel (or serial) port. Sometimes one could fix this in BIOS, sometimes not.
russdill 2y ago
It's really about engineering trade-offs and cost. It used to be the cost of extra logic to allow for devices to work out resource allocation would be much higher than the cost of a set of pin-headers and jumpers. Now the cost of those extra pin-headers and jumpers dwarf the cost of the extra logic.
theamk 2y ago
If you want to do something like connect a LED driver today, give SMBUS a try! It's basically I2C bus with some limitations, and a lot of motherboards bring it out right via convenient headers. In general, I2C bus is a great way to interface with computers: it's needs only 2 wires, can be easily connected even to 8-bit MCU, and it has great development experience: start with $10 USB-I2C bridge (like CP2112) for development, then connect final device via internal SMBus connector or via unused monitor port. Linux comes with all the drivers, so there is no need to write kernel code. (You can also do USB, but this is annoying to implement from scratch, without any libraries. And USB-Serial bridge might be taken over by ModemManager and various embedded IDEs.)
_yb2s 2y ago
I remember using early plug and play devices- often I had two devices that both worked, but not if installed in the same machine at the same time, and I would have to shut down the machine and swap cards to use the other device. I am still not sure exactly that the problem was that caused that.
Gormo 2y ago
> One major aspect of PCI which I do respect is it's incredible backwards compatibility. I still use a 20 year old Adaptec PCI SCSI card via an adapter carrier in in my latest PC (drivers were fun but it works). Motherboards with PCI slots are becoming rarer and rarer though. Most modern boards only seem to have PCI Express.
- rasz 2y ago
  $20 PCIe to PCI Adapters get you back in the game.

burnt-resistor 2y ago

I don't miss it because the resources and choices were extremely limited. PnP (ISA, VLB, AGP, PCI/-X, and to some degree MCA and EISA) was revolutionary because it automated the mundane.

contingencies 2y ago

My first machine was a 286, so they have a special place in my heart. It should be pointed out that the clock speed of an ATMega328P (original Arduino / Arduino nano) is nearly exactly the same as an 80286. Two of the same could easily outcompute a 286! You can buy them for ~$3 at the moment... I've put plenty of AVRs on ethernet - and once, a 386, using an ancient DOS TCP/IP stack, but never a 286. Linux doesn't support it due to requiring an FPU. It'd be fun to design the electronics for an old-style computer, but IMHO it'd be far more amusing to do it from scratch with an original architecture than try recreating a third party motherboard using a similar layout scheme. Something with parallelism and auto-scaling would be quaint.

einr 2y ago
I've put plenty of AVRs on ethernet - and once, a 386, using an ancient DOS TCP/IP stack, but never a 286. Linux doesn't support it due to requiring an FPU. mTCP (http://brutmanlabs.org/mTCP/ http://brutmanlabs.org/mTCP/) is a currently-maintained TCP/IP stack for MS-DOS that will run on any PC, 8088 and up. You also need a packet driver for your NIC. 286 machines are easy; nearly any 16-bit ISA NIC will work. XT-class machines are slightly trickier because not all NICs will work in 8-bit ISA slots and some packet drivers use 186/286 instructions.
pantalaimon 2y ago
Linux runs fine without an FPU, it even has a software emulation. It’s the hardware task switching features that the 386 introduced that it requires (and the reason why Linus got one in the first place back in the day)
- rep_lodsb 2y ago
  Hardware task switching was introduced on the 80286. And no modern OS - including Linux, except for the earliest versions - uses it, because the way it is implemented, the mechanism will do a lot of unnecessary duplicate work (preserving "garbage" register contents from just before the kernel is about to return to user mode, and will consequently have to restore them itself). The only situation where it would be required to use this misfeature is for handling exceptions like stack overflow in the case that they can occur in kernel mode. A "Task State Segment" is really more like a pre-allocated stack frame anyway, the CPU puts active ones in a linked list and does not allow freely switching between them, only returning to the outer level. x86-64 does not have hardware task switching anymore, instead it is now possible to switch to another stack on an exception or interrupt, which is all that the TSS was used for in practice anyway.
  - actionfromafar 2y ago
    Linux started on 80386.
    - rep_lodsb 2y ago
      Where am I disagreeing with that? Hardware task switching already existed on the 16-bit 80286, and remained supported on newer generations until being finally removed in x86-64. Early versions of Linux did use it for a time, but doing it in software turns out to be faster, because the mechanism was badly designed for what a general-purpose kernel has to do.
      - actionfromafar 2y ago
        Sorry, I see now that your comment could be read both ways, and my misinterpretation was actually a bit far-fetched.
fredoralive 2y ago
It's the lack of a "modern" paged memory management unit that's the main issue for mainline Linux on a 286 AFAIK. Nobody wants to deal with x86 segmented memory, having a nice flat addressing paged mode is one of the big wins of the 386. Although I believe Linux dropped support for 386 (and 486?) a while back so they could remove some special cases for such old chips.
- rep_lodsb 2y ago
  Yes, paging is what is necessary to run Linux. The main problem it solves is how to allocate physical memory without having to constantly move variably-sized segments around to get rid of fragmentation. But I'm kind of sad that all OSes converged on a flat address space for the sake of ~PoRtAbIlItY~. Monocultures are bad, and we currently have one, where everything is basically a UNIX clone written in C. 32-bit x86 allowed to use both segments (of any length up to 4 GiB) and paging at the same time. Before the NX bit was introduced, this was the way to have write-xor-execute permissions. And some security features of segmentation can't be replicated at all in a flat address space: with a separate stack segment (or one with the same flat base address but a different limit), it will be impossible to add the wrong offset to a pointer to stack and get access to data that is outside of it. IMHO, the iAPX 432 had some good ideas, and x86 should have evolved in that direction, adding a few more "extra" segment registers which code can use freely as pointers to isolated objects. Each would have two "limit" fields (for negative and positive offsets from the base), with one of these spaces used for storing pointers to other objects, which can only be manipulated through CPU microcode that guarantees memory safety. Instead they eliminated segments completely in 64-bit mode, except for FS/GS serving as an extra offset that gets added with no limit checking whatsoever.
  - AshamedCaptain 2y ago
    I do agree with what you say and also have nice memories of 8086 segmentation. I find it funny that we are continuously forced to add workaround on top of workarounds to the flat address space in order to avoid accidental memory errors. Segmentation had all that decades ago, and easier debugability to begin with. But it is clear to me that we are moving again towards something like that, even if enforced at a different level.
cesarb 2y ago
> Linux doesn't support it due to requiring an FPU. I have used Linux on a 386SX which did not have any FPU. Linux had x87 floating point emulation for a long time (AFAIK, that emulation has since been removed, together with the rest of the support for very old CPUs). The main reasons Linux doesn't support the 80286 are AFAIK that the 80286 is a 16-bit CPU, and Linux (other than the short-lived ELKS fork) has never supported 16-bit CPUs; and that the 80286 doesn't have paging (it has only segmentation), which would require running it as a "no-MMU" CPU.
- lproven 2y ago
  They meant MMU.
int_19h 2y ago
Linux doesn't support it, but https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset does.
lproven 2y ago
> Linux doesn't support it due to requiring an FPU. This is incorrect. FPU means "floating point unit". Linux does not need this. Few OSes do at all. You meant "MMU", meaning memory management unit. This is what Linux uses to perform virtual memory handling, and that is why Linux can't run on an 80286: the '286 had no MMU (or FPU). The difference being that 99% of computers without an FPU could just have one added. This was never true of an MMU. Indeed some early Unix machines based on CPUs with no MMU used an entire 2nd CPU just for MMU duties.
burnt-resistor 2y ago
Incorrect. Clock speed is not a 1:1 correlation with cycle efficiency. There are plenty of "slow" single-cycle architectures with very good cycle efficiency, and there are many architectures like the older P4 that have very poor cycle efficiency to chase the MHz wars.

toast0 2y ago

IRQ jumpers weren't too bad, but it was easy to run out of them, and not all devices could share interrupts well. PCI made IRQ sharing more accessible, but the real improvement was (in band) Message Signalled Interrupts, which allows for a much larger number of interrupts, ending sharing in most cases and also resulting in a knowable ordering between I/O and interrupts, which can eliminate the race condition between interrupt arrival and status reads/interrupt enable. The other big pains of ISA were finding working I/O assignments with lots of cards, and finding DMA channels (although ISA devices started doing their own bus mastering DMA because the motherboard DMA controllers were a fixed, slow, speed, by spec)

einr 2y ago
IRQ sharing on PCI came with its own pains though which were sometimes harder to diagnose and fix. In the early 2000's I was recording and mixing music with DAWs on Windows 2000 and you always had to be very careful that your PCI ASIO sound card did not share resources with anything else or you got to deal with dropouts and glitches. Plenty of futzing around in BIOS setup and Device Manager, very flaky stuff.
- toast0 2y ago
  Definitely. Sharing was better than not being able to use your slots when you ran out of IRQs, but sharing wasn't great. The idea of wiring 4 IRQs to the slot and let the card/driver pick was good, but the reality wasn't great if your motherboard just tied all 4 to the same pin on the interrupt controller.
rkagerer 2y ago
but it was easy to run out of them So often in computing we've completely overhauled the stack with loads of new complexity, when simply adding more of some limited but unexpectedly popular resource would have sufficed (great example... IPv6). (Ps. Thanks for your informative reply to my comment)
- thrw42A8N 2y ago
  How do you propose we add more IPv4? Not to mention that the IPv6 protocols are less complex than IPv4 - as they were designed after the "natural" evolution of IPv4 concluded.

p_l 2y ago

The problematic era of PnP was the ISAPNP, which was complex and prone to failure, and gave us the jokes about Plug'N'Pray

hulitu 2y ago
It was also because a lot of HW (soundcards mostly) had a morbid preferrence for IRQ already allocated to the parallel (or serial) port. Sometimes one could fix this in BIOS, sometimes not.

russdill 2y ago

It's really about engineering trade-offs and cost. It used to be the cost of extra logic to allow for devices to work out resource allocation would be much higher than the cost of a set of pin-headers and jumpers. Now the cost of those extra pin-headers and jumpers dwarf the cost of the extra logic.

theamk 2y ago

If you want to do something like connect a LED driver today, give SMBUS a try! It's basically I2C bus with some limitations, and a lot of motherboards bring it out right via convenient headers. In general, I2C bus is a great way to interface with computers: it's needs only 2 wires, can be easily connected even to 8-bit MCU, and it has great development experience: start with $10 USB-I2C bridge (like CP2112) for development, then connect final device via internal SMBus connector or via unused monitor port. Linux comes with all the drivers, so there is no need to write kernel code. (You can also do USB, but this is annoying to implement from scratch, without any libraries. And USB-Serial bridge might be taken over by ModemManager and various embedded IDEs.)

_yb2s 2y ago

I remember using early plug and play devices- often I had two devices that both worked, but not if installed in the same machine at the same time, and I would have to shut down the machine and swap cards to use the other device. I am still not sure exactly that the problem was that caused that.

Gormo 2y ago

> One major aspect of PCI which I do respect is it's incredible backwards compatibility. I still use a 20 year old Adaptec PCI SCSI card via an adapter carrier in in my latest PC (drivers were fun but it works). Motherboards with PCI slots are becoming rarer and rarer though. Most modern boards only seem to have PCI Express.

rasz 2y ago
$20 PCIe to PCI Adapters get you back in the game.