• Please review our updated Terms and Rules here

What fun-OS can be run on a 386SX?

one -bit tricky- OS to try is CTOS (Convergent Technologies later UNISYS), any CTOSian here?
I wrote 'bit tricky' as this wont be installed on *any* 386/486 this OS is very picky, it normally requires a ClusterCard for the networking, bit it can be installed as standalone - if you are lucky.
 
Doesn’t work on 486 (or less) CPUs at all, and is considered unlikely to work with a lot of software on less than a “686”

ReactOS originally targeted Windows XP compatibility, which makes sense. Windows XP RTM dropped support for the i486 architecture. By the time that SP3 rolled around, CPUs without SSE support were dropped (not officially, but you'd experience system instability and crashes from updates/drivers/apps trying to use SSE.) SSE2 was also starting to become a requirement on some software, so anything pre Pentium 4 Northwood or Athlon 64 was dropped as well.

I recently tried Windows XP SP3 on an Athlon 800 and it was basically unusable. Several Windows updates by that point had integrated SSE instructions, as did some of the drivers. It was constantly blue screening or having processes crash at random.

For me, I find the POSIX "i386" platform definition to be somewhat ambiguous. Recently there was a guy on another forum that was trying to run the "i386" build of Free Pascal on his "Pocket 386" laptop that has been mentioned above, and failing at it; according to him it was built with 486 instructions. I consider "i386" to be a shorthand for "32-bit x86" which doesn't generally mean it will execute on a physical 80386, even if the rest of requirements could be potentially satisfied. Your mileage may vary.

It's been that way since the late 90s/early 2000s. There was some minimal effort by people to specify the architecture a package was compiled for, but you couldn't trust that either. This resulted in a pile of nonsense package suffixes like i386, i486, i586, i686 and I remember seeing at least a handful of i786, which was an unofficial term used for Pentium 4 and Athlon 64 chips. All this did was exacerbate dependency hell.

These days, "i386" is just a generic moniker for 32 bit. But, it is not explicitly limited to only 32 bit processors. Both Intel and AMD further extended 32 bit x86 well into the 64 bit era, so there are some cases where you require a 64 bit processor to run 32 bit code.
 
This resulted in a pile of nonsense package suffixes like i386, i486, i586, i686 and I remember seeing at least a handful of i786, which was an unofficial term used for Pentium 4 and Athlon 64 chips. All this did was exacerbate dependency hell.

These days, "i386" is just a generic moniker for 32 bit. But, it is not explicitly limited to only 32 bit processors. Both Intel and AMD further extended 32 bit x86 well into the 64 bit era, so there are some cases where you require a 64 bit processor to run 32 bit code.

Heh, never ran into i786. The entire nomenclature is stupid, 786 sounds off because it's like a fictitious platform, 586 and 686 sound "ok", reminiscent of those old Cyrix chips, but they're not that.
Funny situations were with RH based distros, some of them used i686, some still used i386, so when you install rpm from another distro, in package tree you have i386 package dependent on i686 packages...

Spot on about the moniker - it's dead wrong to associate it to 386 the CPU. There is alot of 32-bit software around still especially OSS on Windows. I did some tweaking of GPG4Win package recently and the default crosscompilation target is 32-bit, that's also in the release installer, regardless of the flags being set for a very modern CPU. Labeling this package as "i386" would be highly misleading.
 
  • Gray386Linux is the other partition on muh mSATA-->IDE SSD.

Isn't this kernel+busybox only? What kind of applications can you build for it? Seems to me it's quite hard to make a pure 386 compilation target with either gcc or clang for some already existing project.
 
Isn't this kernel+busybox only? What kind of applications can you build for it? Seems to me it's quite hard to make a pure 386 compilation target with either gcc or clang for some already existing project.

If the user has a 387 FPU there is an "i486 UD Handler" out there somewhere that uses the x87 instructions to handle the "missing" i486 instructions. IIRC it was on Reddit ages ago, worked with GCC 3.x

So basically a silly "FPU-enhanced upgrade" to 486.
 
If the user has a 387 FPU there is an "i486 UD Handler" out there somewhere that uses the x87 instructions to handle the "missing" i486 instructions. IIRC it was on Reddit ages ago, worked with GCC 3.x

So basically a silly "FPU-enhanced upgrade" to 486.
OS/2 had a 387 emulator built in. If no FPU was available, the invalid instruction would be caught, and emulated. I had a customer that wrote some code using the FPU (time sensitive). It ran perfectly on a 486. On a 486SX, it took way too long. It had to be re-written to not use the FPU.
 
Having asked about the minimum requirements for Doom in another thread and the answer was 486/66, I was wondering what I could run on my various 386, especially the slower 386SX
There's an optimized version of Doom currently in development that runs faster on 386/486 hardware. It also supports more sound cards than the original release.
 
For varying values of "fun", you can try XINU: https://hackaday.io/project/194283-pc-xinu-brought-from-the-abyss

I was able to get into Comer's last class he taught on XINU, and it was a lot of "fun". For an OS geek, anyway. Although we used LSI-11s, it was further developed to run on PCs, and apparently a 386 version. This is a teaching OS, not a productivity OS, so the idea would be to play with the source code, recompile it and run it. Rinse and repeat.

More info:
 
This was mentioned before, but just to bring it up again, 386BSD would be an interesting trip down memory lane. I remember reading the Dr. Dobbs journal articles about this original port of the Berkeley UNIX code to the 386 platform in a stack of issues I picked up from the library (the local library regularly purged extra copies of periodicals, so I often found myself reading some of the more obscure computer journals a few months late for free) but I've never actually run it. I gather the actual binary releases were *extremely* picky about what hardware they would run on, but a plain vanilla 386sx might just qualify.
 
I struggled through trying to install and run OS/2 2.1 and Windows 95 on a 386SX. I wouldn't recommend either.

Although not truly an OS on its own, Breadbox Ensemble (the last iteration of GEOS / GeoWorks) would run great on one. In fact, that's what the Brother GeoBook was: a 33 MHz AMD Elan SC300 (an embedded version of the 386SX) running Datalight ROM-DOS and GeoWorks.
 
I was wondering what I could run on my various 386, especially the slower 386SX, machines except DOS and Windows. I do have Suse 1.2 from April 1995 laying around but IMHO it is not "fun" enough.
If SuSE 1.2 on a i386 is not "fun" enough, then I don't know what else to say.

I've found Red Hat 6.2 (classic) can run in multi-user, network-enabled mode with 8 MB of RAM, and with 16 MB of RAM it can do X11 graphics just fine. A i386sx should be able do this, slowly, but surely.

Past that, with 32 MB of RAM you can comfortably run Netscape Communicator 4.7 plus quite some xterms concurrently. Very litle things in vintage-land would be more "fun" than that.
 
OS/2 had a 387 emulator built in. If no FPU was available, the invalid instruction would be caught, and emulated. I had a customer that wrote some code using the FPU (time sensitive). It ran perfectly on a 486. On a 486SX, it took way too long. It had to be re-written to not use the FPU.

I've recently been experimenting with a couple 386DX's (were DX's first and SX's later as a cost savings?? I can't really recall).

I found that StarTrek TNG Final Unity, NFS 1 and MechWarrior II won't run on it - they all really do use 486+ instructions, and the system barfs a big opcode-not-found exception. But I wonder if a TSR could be written to trap that and emulate the missing instructions? Maybe the FPU was more forgiving on that kind of capability, since it was understood many end users wouldn't have that math coprocessor. But years later when they added the MMX instruction set, people didn't include MMX-enabled and non-MMX EXE's (was that due to compiler-support magic? i.e. any "use MMX" option proxied in appropriate jump vectors for MMX and non-MMX hosts?) Anyway, just feels that if MS-DOS can trap opcode-not-found, then emulating the instruction and "future-proofing" the old 386 seems possible?

I did get Quake to run on the 386DX (after adding a clock matched 387), but it is indeed 2-3 fps. I actually didn't try Doom, it might not be all that bad if it could get 8-10fps :) But there is the 8088DOOM that runs just on 8086 and text-mode (plus an MDA version). There is a text-color version also now, which of course runs just fine on the 386. // I'm not sure yet if I'd call Falcon3 playable on the 386 - it sort of is, but then I got into some glitchy camera angles (but I've read the "realistic" flight model that uses the 387 was never really that great). Tyrian is playable (but slows when enabling audio), and OG Warcraft 1 (but both require 4MB RAM). I still find MOD MASTER as the best audio player IMO (and does support more than just .mod), I tried about 8 others that used graphics modes and just didn't work out even on the 386DX.

I haven't branched out too much on "exotic operating systems" for the 386, other than I did run DONKEY.BAS from MS-BASIC 1.0 to show it does still work on a 386 (and is throttled appropriately to be playable!). As 386's don't have built in BASIC ROM anymore, I used BASIC.EXE maybe from DOS 3.2 or 3.3 (or BASICA? something like that).

I was hoping to see how OS/2 WARP goes, on a 386 (I used it heavily on 486DX/100 and Pentiums for years, but never verified if a 386 could actually handle WARP in any satisfactory way) - but I'm really not into stacks of 3.5 floppies, and I can't find a 386 mainboard with firmware that supports CD-ROM booting (took awhile to find an IBM release of WARP on a CD-ROM, but I do have that now and it installs great on later model ThinkPad Pentiums).. I did finally get a CD-ROM working with the 386 (one 386 does so via the SoundCard IDE, the other 386 just uses a CD-backpack across LPT). Don't suppose anyone already has an OS/2 IMG file that we could DiskWrite to a CF card and boot?

NOTE: Speaking of that 8088DOOM that's text mode... I had hoped I could run MOD MASTER under DesqView, and then 8088DOOM in another window on a 386. But so far I never got that to really work out. But that'd be interesting to see IMO (I forget which DesqView version I was using - but maybe MS DOS 4 Concurrent could handle it?). It would be wild if OS/2 2 had enough DOS compatibility to pull it off. Note that MOD MASTER also supports dropping to a DOS shell, I can't recall if I had enough memory left to run 8088DOOM (been a few months since I tried it).
 
Last edited:
I've recently been experimenting with a couple 386DX's (were DX's first and SX's later as a cost savings?? I can't really recall).

The 386SX was released three years after the 386DX as a budget part. It has a half width 16 bit data bus and 24 bit address bus, making the chip much slower than a regular 386DX at the same clock speed. It also limits the CPU to 16 MB of physical memory.

The crippled bus did give it another use case, upgrading old 286 systems more easily because they shared the same bus widths. There was a big upgrade market for 286 machines and manufacturers that released hybrid 286/386 motherboards. Later on, Intel and Cyrix released 386/486 hybrids with the same bus that could be run on budget boards to squeeze every last ounce of performance out of the crippled platform. These hybrid CPUs also had clock doubled and tripled versions that got clock speeds up to 100 MHz.
 
Back
Top