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)
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)
Back in the before times, Papa Delni setup an old 486 (actually 386 using a cyrix "486" cpu) as an X terminal. This was a hot setup with an ATI Graphics Wonder, AMD Lance network, 8mb of ram, the whole 9 yards.
Everything worked great except the network was terribly slow. Except when I moved the mouse, then it was nice and normal.
Turned out the network card and mouse were on the same IRQ, or maybe the driver was looking at the wrong IRQ, and the network buffers only got drained when the mouse was wiggled.
I actually used that little nugget of knowing things to know to switch to polled network buffers on a big fat firewall that was running freebsd -- it was constantly under huge load so there was no real advantage to waiting for IRQs.
Don't miss that world at all.
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.
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.
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.
Compilers like Turbo Pascal and Microsoft C all gave you a choice of which memory model you wanted to use, often you wrote programs where a 64k code and 64k data space is all you need.
TP forcing use of large pointers for everything, and its lack of even trivial peephole optimizations, probably contributed to the myth that C was somehow inherently more efficient.
[BT]P7 includes for compatibility: tiny (.COM), small, compact, medium, large, and large w/ overlays (which can use EMS when available). There are DPMI clients for [BT]P7 that make it possible to switch to protected mode and use more memory.
It definitely generated offset-only pointers in the tiny, small, and medium memory models because that's how they referred to data with the common DS segment. I did plenty of memory and instruction-level debugging in [BT] Profiler/Debugger and inspected plenty of pointers where they lived in RAM.
http://bitsavers.trailing-edge.com/pdf/borland/turbo_pascal/...
Page 221: "A Pointer type is stored as two words"
Who cares about address space organization? (k|)ASLR, PIC & PIE means this is a detail not worth your time. This kind of standardization is vital for security, debugging, and profiling.
The 386 has LDT that generally isn't used, and there's only one TS that is updated rather than multiple ones. FS and GS tend to be used for thread-local storage.
As an aside, this reminds me of an amusing early example of a rough-and-ready configure-style script[1] included in the BSD source for the compress(1) utility, used to limit the maximum supported LZW code length based on an estimate of memory that will be available to the process[2].
[1] https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3...
[2] https://github.com/dspinellis/unix-history-repo/blob/BSD-4_3...
386 support was dropped, 486 support has not yet been dropped as of writing.
Not saying this to brag, just to establish that I probably know more about that chip than the average poster. And you're also posting plainly wrong claims elsewhere in this thread. I don't get why you're doing this?
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)
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.
Nope.
8086 and 80286 multitasked fine.
It was memory management hardware that came in with the 80386. You need that for virtual memory.
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.
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.
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.)
Motherboards with PCI slots are becoming rarer and rarer though. Most modern boards only seem to have PCI Express.
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).