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!
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.
> 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.
> 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.)
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...
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 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. :-)
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.
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.
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!
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.
> 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
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.)
Exactly
ah, thanks for clearing up my brain cobwebs
> 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...
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...
> 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:
https://netbsd-jails.petermann-digital.de/
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.
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.