AMD Am386 released March 2, 1991
dfarq.homeip.net
dfarq.homeip.net
Technically not. It can run it. Was slow? Yes, but my Am386DX40 keep working fine from 1991 to 1996. Running DR-DOS 6, MS-DOS 6.11, Windows 3.1 and finally Windows 95. And, of course, I could play DooM 2 on it. At some point, I got a math copro. Finally, my father upgraded the machine with an AMD 486DX5 133MHz.
Eh... I think the Linux kernel + your choice of libc/userland has it beat these days.
On portability on compilers, plan9/9front it's unbeatable. Do you now Go compiling from any OS to any arch? The same here, but just for an OS obviously. Albeit I can still run Golang under i386, and tools like Rclone under 9front i386. That's really cool.
Driver support for a niche SoC? Good luck getting NetBSD on before Linux. The sheer amount of SoCs supported by the Linux kernel dwarfs anything NetBSD has to offer.
Like sure, it runs on my VAX, my Sun4/75, and my Alpha box, but it doesn't run on my POWER9 workstation nor does it run my Amlogic A311D ARM device (at least in a usable capacity), and I couldn't even get i.MX 8M running. I didn't try super hard, to be fair, but why would I burn cycles getting an OS with less peripheral support running when Linux "just works"?
My experience with Linux on a Sun Sparcstation 20 circa 2000 was that it was slow as hell compared to Net or OpenBSD.
At least OpenBSD, when it says it supports a platform, _actually supports that platform_, and the system is stable enough that it can build itself.
I always thought it was cool OpenBSD compiled on each arch itself. IIRC, there is or was a rack of servers, each with a unique architecture that all built their respective release files. The various targets could help catch arch-specific bugs leading to more portable code.
VAX was always last and the slowest, which was part of why VAX support was dropped some time ago.
FWIW, Linux does work fine on the Alpha, it's just slow. Both NetBSD and Linux have busted framebuffers on my workstation, which has a 3DLabs graphics chipset. Having acceleration enabled causes Linux to output pure garbage, and NetBSD to kernel panic. The CPU performance is surprisingly okay, though. About half the performance of an original Raspberry Pi, in pure integer math...
Linux is busted on my SPARC box though, not because of the system itself, but a bug in the Weitek 2000A CPU. It was an aftermarket part from Weitek, and in order to retrofit an 80 MHz CPU into a system with discrete MMU and cache chips that expect a 40 MHz single-issue RISC processor, it adds a funky on-chip cache, branch-predictor, and instruction prefetcher.
Details on specifics are ~impossible to find nowadays, but the word on Usenet was that chips made before 1995 are no good for Linux. My limited testing with a '93 chip corroborates this. I really ran into this while building a new Sprite [0] distribution, where I learned this chip makes tons of spurious page faults from the branch predictor hitting bogus instructions, which causes the Sprite (and Linux?) kernel to freak out. This corroborates the Usenet reports for random signal 11s killing processes on Linux...
Doesn't effect NetBSD, though. I think this [1] code is why (replaces the bogus fault address with the process counter) but I'm not sure. I have a partial fix for Sprite's kernel which allows userspace to boot up and work, and have networking fixed, but if you sneeze it kernel panics and murders the Sprite-bespoke filesystem, so testing has been a slog. :-)
[0] https://en.wikipedia.org/wiki/Sprite_(operating_system)
[1] https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/spar...
https://www.theregister.com/2012/12/12/linux_no_longer_runs_...
I was at a talk celebrating NetBSD's 30th anniversary. I wrote about it:
https://www.theregister.com/2024/04/17/30yo_netbsd_releases_...
They're well aware of this.
But as Linux edges closer to dropping 32-bit x86 completely -- most distros already have -- I think NetBSD may suddenly regain some relevance in this specific area.
There's also a new initiative to improve its jails facility:
I could try to upgrade to the mighty Am486DX5 at 133. I managed to get one, but I need to mod the MBO to give the low voltage required by it. The MBO it's prepared to it, but don't have populated the regulator...
I had similar experiences with the Am486DX5, I could only run it at 100MHz and I also suspect it's voltage related.
It was two generations old at that time but still a lot of fun: it could run a lot of games (incl. DOOM, of course), programming (largely Turbo Pascal 7), and some word processing under Windows 3.11.
I didn't bother with Win95, though.
I've been using it up until 1999, when I finally got a then-modern computer with Windows 98. But in some ways MS-DOS felt more capable - I really knew what each file is for, what computer is doing, etc. I.e. the entire machine is fully comprehensible. You really don't get it with Windows unless you're Russinovich or something.
So in a way 386 was a peak computer for me
Neither had FPUs... Closest you can get is RapidCAD (which is really a 486DX adapted to 386 bus, IIRC it uses a 'jumper' for the 387 slot.)
For 386, the difference between SX and DX was whether it was a 16 or 32 bit data bus.
Where things can get more curious, is that some early 386 motherboards actually took a 287 instead of a 387...
The 386DX/386SX distinction was the external databus (32-bit on the DX, 16-bit on the SX)
DX was “Double word eXternal", SX was “Single word eXternal”. Neither had an FPU builtin, and there were corresponding 387DX and 387SX coprocessors.
Then Intel used the same naming split (despite the abbreviations not applying) for high-end vs low-end of the 486 where the DX had a builtin FPU and the SX required a “487SX coprocessor” to get an FPU (which IIRC was internally just a 486DX processor which went into a separate “coprocessor slot” which just bypassed the “main” processor when populated.)
Edit: It might be cool to make a higher-spec TMS9900 home brew system.
Am386 was _not_ clean room. It was a copy, just not 1:1 mask copy because of https://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_... AMD admitted to copying 386 microcode and parts for 486
Sept. 4, 1993 LA Times https://www.latimes.com/archives/la-xpm-1993-09-04-fi-31680-...
>AMD said Friday that its “independently derived” 486 microprocessor borrowed some microcode from Intel’s earlier 386 chip.
In 1995 settlement AMD fully admitted copying and agreed to pay $58mil penalty while Intel gave them official license for 386, 486 microcode and infamous patent 338(mmu). Intel really wanted a legal win confirming validity of their patent 338 to threaten other competitors like UMC https://www.cpushack.com/2012/09/06/intel-vs-the-world-the-3...
> Effectively, Intel forced AMD into remaining a CPU generation behind for more than a decade
Nobody forced AMD to copy 1:1 Intel designs. AMD was lazy in late 80s. Am2900 was ancient seventies design, Am29000 was BAD and expensive. 1991 Q1 25MHz CPU prices according to "Semiconductor procurement worldwide" 1991-1993 by Dataquest:
Am29K $135 ~15-20 mips only with expensive SRAM/caches
88100 $82 ~15 mips but supposedly TERRIBLE CPU according to Apple engineers
R3000 $150 25 mips?
SPARC $100 20 mips
Companies like Cyrix somehow managed to build novel x86 implementations, but still had to employ legal tricks due to that stupid AMD settlement providing precedent for legality of patent 338. Cyrix was forced to manufacture with IBM and TI as both had iron clad foundry agreements with Intel. Cyrix Corp. v. Intel Corp https://law.justia.com/cases/federal/district-courts/FSupp/8...
"Section 1.23 of the IBM Agreement states that IBM Licensed Products "shall mean IHS Products ..." The only logical conclusion is that the parties meant those IHS Products specifically identified in Section 1.2 of the Agreement. Section 1.2 does not limit the products to IBM designed products."
"Therefore, IBM has the right to act as a foundry and to make, use, lease, sell and otherwise transfer the microprocessors in question to Cyrix free of any claims of patent infringement."
>while AMD sold entry-level CPUs at the low end of the market.
thats on AMD not being able to design good product. Their breaks came in form of first acquiring NexGen and selling their chip as K6 and later hiring bunch of great DEC engineers who helped design K7 architecture.
>More modern fabs meant lower production cost, which meant better profit margins.
In one of Computer History Museum interviews Intel engineer mentioned releasing 386SX to battle AMD at the low end and that it cost Intel $5 to manufacture one including packaging in 1988. There was plenty of margin to go around even at the low end if you were good at what you were going. Intel initially priced 386SX at $219, money printer goes BRRRR. i386SX-25 went from Q1 1990 $184 to Q4 1992 $59 due to losing AMD Am386 microcode lawsuit. This move relegated Am386DX-40 Q2 1991 $231 flagship to the title of Q1 1993 $51 bottom feeder.
>Running at the same clock rate, AMD’s version of the 386 had essentially identical performance to the Intel original.
because 1:1 clone
>Value-oriented power users
no, bargain bin shoppers. I should know, I was one of them :)
>40 MHz 386 was faster than a 20 MHz Intel 486SX, and roughly comparable to a 25 MHz 486SX.
Am386DX-40 was somewhere between 486SX16 and 20 when running 32bit code like DOOM. Cyrix Cx486DLC-40 was about 486SX-25.
> favored the AMD Am386DX-40 well into the 486 era
Am386DX came out well into 486 era :) no one favored Am386DX. You bought it or Cyrix Cx486DLC if you couldnt afford 486 platform.
I loved my little Am386DX. 8MB, 40MB stepper motor IDE drive, random VGA, Aztech Sound Blaster 2 clone with matching Mitsumi x2 CDROM. All scrounged together from used discounted parts piece by piece in $50 increments.