AMD Am386 released March 2, 1991
dfarq.homeip.netMy friend used to have amd ~586 I think. I remember that when playing Colonization on dos you were not allowed to move the mouse beyond the right edge of the screen or the graphics messed up... But pinball fantasies worked well!
> Technically, the Am386 could run Windows 95, but it wasn’t a great experience.
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.
My father got me a second-hand computer with Am386DX-40 somewhere around 1997, IIRC. An upgrade to older 286.
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
NETBSD still can run on it too :) Best and most portable os in the history
I have a 486DX2 at 66 that I have as pet project to mess with Windows 95, MSDOS and S.u.S.E. Linux 5.3 . SuSE 5.3 was my first full distro (the whole pack of 6 cdroms), and I had good memories of how was easy to install stuff with YaST.
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...
Very cool! I have a DX4-100 system with an empty CF card calling for Linux, I'll have to give SuSE 5.3 a try. I see it has KDE 1.0 which will be fun to explore.
I had similar experiences with the Am486DX5, I could only run it at 100MHz and I also suspect it's voltage related.
And Gnome 1. Fun fact, Gnome 1 allows you to use any window manager under it. So you can run Gnome 1 over FVWM, FVWM95, Enlightenment, or... KDE1 !
> most portable os
Eh... I think the Linux kernel + your choice of libc/userland has it beat these days.
The Linux kernel dropped 386 support fourteen years ago.
https://www.theregister.com/2012/12/12/linux_no_longer_runs_...
I'm well aware, thank you. I'm not contesting ability to run on a 386, I'm contesting the title of "most portable OS".
OK. In context -- discussing an article talking specifically about AMD 386 chips -- that was not at all clear.
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:
Modern Linux can't even scratch a 486 and some Motorola platforms. Or VAX. Heck, I run NetBSD 10.1 vanilla under simh 3.8 for 9front emulated on an amd64 laptop (old Celeron, 2GB). Slow, but enough to play Slashem.
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.
That's a very limited view of what portability means.
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.
Yeah, NetBSD's support for modern hardware isn't amazing compared to Linux. I love it (and run my personal web server on it!), but the portability thing feels like a meme from the 4.4BSD days, where it ran on basically every workstation platform.
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"?
I don't think Linux "just works" on VAX, Sun4/75, or Alpha.
My experience with Linux on a Sun Sparcstation 20 circa 2000 was that it was slow as hell compared to Net or OpenBSD.
I was saying that NetBSD works on those older systems, while it either has no support (64-bit POWER) or spotty support (modern ARM) on more modern platforms. I've got netbooting set up for all of them, and it's "useful" for testing, though even a 20 MHz VAX is pain and suffering (12+ hours to generate RSA private keys for SSH).
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...
I doubt NetBSD "just works" fully on those systems either. I see a lot of rose tinted glasses when NetBSD portability comes up. Those older systems barely get stress tested, as the system has become too large to be self-hosted on them anymore and has to resort to using cross compilation to build a working base.
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.
> At least OpenBSD, when it says it supports a platform, _actually supports that platform_
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.
Modern Linux dropped support for a lot of old and niche CPUs.
And NetBSD is missing support for an order of magnitude more SoCs. I like NetBSD. I've run it on several systems in the past, and not just as a toy. I like the whole BSD family, and even deploy FreeBSD in production at work, and use OpenBSD on my home router. But NetBSD's claim as the most portable OS doesn't hold up these days.
Which math copro? If you had a 386DX then I believe you had the math copro? The 386SX did not have an FPU and needed the additional 387SX.
> If you had a 386DX then I believe you had the math copro? The 386SX did not have an FPU and needed the additional 387SX.
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.)
ah, thanks for clearing up my brain cobwebs
Exactly
> If you had a 386DX then I believe you had the math copro? The 386SX did not have an FPU and needed the additional 387SX.
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...
TI with the TMS9900 was in a similar position as IBM with the 386: both threatened their micro/minicomputer markets. This is why TI didn't release other TI-99-like machines. TI also expressed disdain towards hobbyists.
Edit: It might be cool to make a higher-spec TMS9900 home brew system.
The TI-99/8 looks like it would have been awesome. It solved the issues of the 99/4a, had improved basic and pascal built in, all while being backward compatible.
> two years to reverse engineer the 386 and implement their own clean-room design
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.