[HN Gopher] AMD Am386 released March 2, 1991
___________________________________________________________________
AMD Am386 released March 2, 1991
Author : jnord
Score : 83 points
Date : 2026-03-02 12:56 UTC (10 hours ago)
(HTM) web link (dfarq.homeip.net)
(TXT) w3m dump (dfarq.homeip.net)
| Zardoz84 wrote:
| > 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.
| iberator wrote:
| NETBSD still can run on it too :) Best and most portable os in
| the history
| messe wrote:
| > most portable os
|
| Eh... I think the Linux kernel + your choice of libc/userland
| has it beat these days.
| actionfromafar wrote:
| Modern Linux dropped support for a lot of old and niche
| CPUs.
| messe wrote:
| 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.
| anthk wrote:
| 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.
| messe wrote:
| 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.
| spijdar wrote:
| 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"?
| hulitu wrote:
| 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.
| messe wrote:
| 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.
| spijdar wrote:
| 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/spa
| rc/spar...
| lproven wrote:
| The Linux kernel dropped 386 support _fourteen years_ ago.
|
| https://www.theregister.com/2012/12/12/linux_no_longer_runs
| _...
| messe wrote:
| 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".
| lproven wrote:
| 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_releas
| es_...
|
| 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:
|
| https://netbsd-jails.petermann-digital.de/
| Zardoz84 wrote:
| 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...
| killerstorm wrote:
| 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
| snarfy wrote:
| 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.
| to11mtm wrote:
| > 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...
| dragonwriter wrote:
| > 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.)
| snarfy wrote:
| ah, thanks for clearing up my brain cobwebs
| Zardoz84 wrote:
| Exactly
| burnt-resistor wrote:
| 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.
| KeyBoardG wrote:
| 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.
| p0w3n3d wrote:
| My 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!
___________________________________________________________________
(page generated 2026-03-02 23:01 UTC)