[HN Gopher] Don't waste money on a math coprocessor they said
___________________________________________________________________
Don't waste money on a math coprocessor they said
Author : jandeboevrie
Score : 246 points
Date : 2023-11-13 07:51 UTC (15 hours ago)
(HTM) web link (virtuallyfun.com)
(TXT) w3m dump (virtuallyfun.com)
| enriquto wrote:
| Those were the gpus of the day. At some point, everything got
| integrated into the cpu. Will we see a similar reintegration any
| soon?
| wenyuanyu wrote:
| Possible... The recent Intel Xeon Max with the "brand-new" AMX
| instructions and 64GB on-chip HBM memory could be an
| example[0]...
|
| [0]
| https://www.intel.com/content/www/us/en/products/details/pro...
| mytailorisrich wrote:
| A whole range of CPUs have integrated GPUs, but nothing on the
| high end.
|
| I think there are technical limitations re. die size and heat
| dissipation if we wanted to integrate a high end CPU and a high
| end GPU in the same package.
| Aromasin wrote:
| Precisely this. Most modern CPUs would be better called SoCs,
| with CPU/GPU/XPU cores all on a single package. If you want
| any sort of stopping power in terms of the number of cores or
| the clocking speed of said cores, you need massive amounts of
| cooling, hence why GPUs are sold as bulky PCIe cards.
| eru wrote:
| I think the Apple chips are the highest end integrated
| CPU/GPU chips? Especially on the mobile site, and if measured
| in terms of price.
|
| They are far from the best performers, of course. They are
| meant to run on low-ish power, especially compared to a
| desktop or server chip.
| hyperionplays wrote:
| the top spec RyzenG Chip is no slouch.
| antupis wrote:
| Is the Apple Mx series about that?
| MBCook wrote:
| Yep. GPU is built into the same die as the CPU. Not the same
| package, the same die.
|
| You can see a (small) annotated die shot of the M1 here:
|
| https://www.tomshardware.com/news/apple-m1-vs-
| apple-m14-floo...
| bonton89 wrote:
| I've often thought Intel kind of ignored the discrete GPU
| market for so long because they just assumed they would
| eventually absorb those functions into the CPU like they did
| with everything else.
| devit wrote:
| Current CPU vector instruction sets are as good as the ones on
| GPUs and they also have tensor/matrix instructions comparable
| to the ones on GPUs.
|
| However, usually CPUs don't have enough cores and execution
| units to compete with GPUs, because they spend the transistors
| on out-of-order execution, cache and other features instead.
|
| Intel Larrabee was the only attempt to actually make a CPU with
| a GPU-sized vector unit and they dropped it.
| justsomehnguy wrote:
| we are on the another iteration: wifi cards are integreted now
| smegsicle wrote:
| http://catb.org/jargon/html/W/wheel-of-reincarnation.html
| rob74 wrote:
| I was actually hoping that by the end of the blog post, the
| mystery of why the game didn't run would be cleared up, but sadly
| it wasn't. Looks like it had trouble accessing the HDD - but why
| should HDD access for a DOS game running under OS/2 require a
| math coprocessor?!
|
| I have my own story of living happily without a math coprocessor
| for quite some time: from 1992 to 1997, I had an IBM PS/1000 with
| a "Blue Lightning" CPU which can be best described as a "486SX3"
| (25 MHz bus clock, 75MHz internal). Then I tried to run the Quake
| demo and found out that "real" 3D games need an FPU :(
| mobilio wrote:
| I have similar experience DX4 overclocked to 120 MHz vs.
| Pentium running on 75 MHz
|
| Hint: Pentium FPU was faster
| consp wrote:
| My Retro-socket3-toy-unit with a P83@100 MHz is fast (40MHz
| bus), but the DX5x86@150mhz (50MHz bus) beats everything
| except in quake. Timings aren't that great for the memory but
| the synchronous PCI bus (and working PCI VGA card at that
| speed) beats everything you throw at it.
| mobilio wrote:
| Same here - all DOS games was faster on DX4, but Pentium
| was so smooth on Quake.
| TerrifiedMouse wrote:
| Carmack and Abrash optimized the heck out of Quake making
| use of a "quirk" in the Pentium where you can overlap
| integer operations and floating point DIV to eke out
| every last drop of performance.
|
| Unfortunately the trick doesn't work on early AMD K5/6
| nor Cyrix CPUs - although Cyrix CPUs probably had other
| more serious problems.
|
| https://youtu.be/DWVhIvZlytc?si=DBE9zpTLj_16-GAt
| Sharlin wrote:
| Yeah. Their perspective correct texture mapping did a
| perspective div only every 16 pixels drawn - in itself a
| considerable optimization with almost imperceptible loss
| in quality - but the big deal was that on the Pentium
| _specifically_ , the integer pipeline could be almost
| perfectly cycle-optimized to process sixteen pixels in
| the time the FPU executed the next perspective division
| in parallel so the result was ready just as it was
| needed!
| touisteur wrote:
| More on this in the Black Book graphic
| shttps://news.ycombinator.com/item?id=35738709 .
| Programming on Pentium is towards the end.
| _the_inflator wrote:
| Pentium was very significant in comparison to predecessors.
| In the beginning Intel shipped a Pentium 66 and it smoked the
| 486 DX 100 easily.
|
| We kind of marveled back then because MHz meant speed.
| vikingerik wrote:
| Part of that was the bus and memory speed as well. The 486
| bus ran at 33 MHz (the "DX4" is actually only clock-
| _tripled_ to 100), while the Pentium bus and memory ran at
| 66.
| _the_inflator wrote:
| Yes, I know. Setting the jumpers for the right bus speed
| for the multiplication was key. This was the time of the
| fine tuning and over clocking. Asus boards were the best
| for this job back then.
|
| Some Pentium ran at 60, not 66.
| hurryer wrote:
| Pentium was the first CPU which could run two integer
| operations per cycle.
| mobilio wrote:
| I remember that - U pipe and V pipe.
|
| And that's why it's first x86 that was superscalar.
| johnklos wrote:
| It wasn't the first CPU that was superscalar by far, but it
| was the first x86 CPU that was superscalar.
| pak9rabid wrote:
| Yep. The P5 arch (original Pentium) superscalar design,
| combined with its much faster FPU and separation of data and
| code caches meant it could run circles around a 486-based
| CPU, even if it was running up to twice the speed of a 486
| contender.
| mrlonglong wrote:
| I had a dual Pentium Pro 166Mhz w/512kb caches running on a
| Tyan mobo. That thing was fast under Linux.
|
| EDIT: Present day, rocking a thread ripper with 48 logical
| cores. Still running Linux.
| glimshe wrote:
| I got a math coprocessor relatively early for my 386SX20 - I
| wanted to use 3D Studio, the killer app for math processors
| back in the day! The vast majority of games simply used integer
| math and didn't require, or could take an advantage from a
| coprocessor, but I have no idea what was going on in the
| article. In the early 90s, the only games I can remember that
| could optionally leverage a coprocessor were the Falcon 3.0
| family of simulators.
| Loic wrote:
| 20+ floppy disks to get 3D Studio and of course you always
| had a bad one and not the first.
| tacone wrote:
| Reminds me of Monkey Island 2 asking to insert floppy 3bis.
| Good times :)
| sillywalk wrote:
| I can still imagine the floppy drive making the "chug-chug-
| chug" sound when you knew that the disk was bad.
| tecleandor wrote:
| Ah, I also had a 386SX, and some games (not a lot, maybe
| three or four) never run properly on my machine. :(
|
| Edit: I just remembered one of them was "Eye of the Beholder
| III"
| danparsonson wrote:
| > Edit: I just remembered one of them was "Eye of the
| Beholder III"
|
| If it's any consolation, you didn't miss much - III was a
| wet rag compared to the majesty of the first two games!
| marhee wrote:
| I remember "Dune 2" (1992) could use a co-processor? Not
| sure, we never had a machine with a co-processor but a friend
| had and he said that at start-up the game said something like
| "Co-processor found - let's use it!" and then game could run
| faster I believe (not sure).
|
| Edit- Dune 2, not Dune 2000
| wigster wrote:
| i remember a friend of mine had falcon for the amiga 500. i
| don't think he EVER managed to take off without some "cheat"
| being activated.
|
| a rather difficult game.
|
| f16 however was a joy. happy days
| rwmj wrote:
| For me the killer app was POVRAY. Ran so much faster with a
| 387 (I seem to recall something like 100x faster but it was a
| long long time ago).
| weinzierl wrote:
| You lucky. I always dreamt of one, that and a TARGA
| graphics card. The last one not only for the looks but
| speed as well. Converting a *.TGA to a indexed color took a
| considerable amount of time.
| russh wrote:
| I remember being tired all day long after waking up many
| time during the night to check the progress of my renders
| or to tweak it and restart. And then I got a math
| coprocessor so I could wake up more often in the night to
| check my renders.
| ggambetta wrote:
| My parents were architects and they used AutoCAD. A very early
| version, maybe 3? So our PC had a math coprocessor... on a
| 286!!! Yes, the 80287 was a thing.
| NikkiA wrote:
| In the 286 era there were even different types of co-
| processor, the Weitek implementation (2167) absolutely
| trounced the official 80287 (and it's second source versions)
| at CAD, that's most likely what your parents had.
| saltcured wrote:
| I searched the comments page to find you were the only one
| who mentioned them. I think we had a 20 MHz 286 with a
| Weitek coprocessor when I was a kid.
|
| It seems Weitek also had a coprocessor to go with 386.
| selcuka wrote:
| I had an 8086 PS/2 clone (Multitech, then rebranded
| themselves as Acer) with a coprocessor, so yeah, even 8087
| was a thing.
| benj111 wrote:
| I wondered if it was a hardware fault, and the fpu is allowing
| enough electrons to flow where they need to be.
|
| Although the infocom 'boot' step suggests a race condition
| somewhere? Or some register not being properly set by the os.
| wzdd wrote:
| Or installing the coprocessor reseated a slightly-loose cable
| or created a better connection on a broken trace. The "boot
| step" could simply result in the system being warmer, which
| would make marginal connections like this behave differently.
|
| To be sure, the author should remove and reinstall the
| coprocessor 10 times, testing after each. :)
| consp wrote:
| > I was actually hoping that by the end of the blog post, the
| mystery of why the game didn't run would be cleared up, but
| sadly it wasn't.
|
| My best guess would be something of the following: The software
| tries to determine if the CPU has a 80(2/3)87 device some way.
| Thinks it does have it and then tries a FPU instruction to get
| the error signal firing and getting the eventual INT02 to blow
| up in it's face. But I'm not limited by any actual knowledge
| here so this might just as well be something completely
| different.
| bcoates wrote:
| My guess is that the Infocom game was setting up some sort of
| FP emulation TSR and not cleaning it up, and BattleTech was
| coincidentally using it. Or whatever the equivalent of a
| windows 3.x VxD is for OS/2, if that exists. Or just
| otherwise messing with the interrupt tables involved in the
| arcane x87 protocol in a way that un-breaks things.
|
| Also it looks like there may be some issues with FP/FP
| emulation on the OS/2 DOS extender host:
| https://www.os2museum.com/wp/floating-point-exceptions-
| and-d...
| consp wrote:
| That sounds quite more plausible than my idea. FP emulation
| is always _interesting_ if performed by multiple programs
| /companies messing with each other's implementation. Lots
| of fun with layers of interrupts, real/virtual/protected
| mode switches and all the other magic the original 87 was
| not designed for.
| mst wrote:
| "I'm not limited by any actual knowledge here" is an
| excellent way of putting it and I shall endeavour to remember
| it next time I'm in such a situation.
|
| Poor though my memory is, it happens often enough that I have
| a decent chance.
| scruffyherder wrote:
| I just got a newer cpu today I just wanted to write something
| out as I wasn't expecting this kind of response.
|
| There is no problem with the drive on dos, windows or os/2 1.2
| so it's something about it being an early 2.0 beta and probably
| an older 386 cpu.
| Narishma wrote:
| You didn't actually miss much because even with an FPU, Quake
| wasn't really playable on a 486. It was optimized for the
| Pentium.
| Projectiboga wrote:
| Might have a been copy protection code requiring the
| coprocessor?
| jandrese wrote:
| The suggestion in the article was simply that his 386 was a
| crappy early one that may also be slightly defective seems
| plausible. IIRC the 387 was a full 386 plus the floating point
| logic, and when you installed it the coprocessor took over most
| of the processing and the 386 was reduced to being a data
| broker.
| _ihaque wrote:
| I believe the 387 was an actual coprocessor; the _487_ may be
| what you're thinking of -- the 487SX contained a whole 486DX
| inside and just disabled the host processor [1].
|
| [1] https://en.wikipedia.org/wiki/X87#80487
| sshagent wrote:
| I still go back and play crescent hawks inception every few
| years. Love the game
| scruffyherder wrote:
| I should do a tutorial on stealing the urban mech, and saving
| the chameleon!!
|
| It's so much better with those 2 mechs
| ekianjo wrote:
| I had Battletech on the Amiga (showcased in the video) and it ran
| much faster even though the Amiga only has a 7Mhz CPU...
| simonh wrote:
| That was probably down to having a Blitter, rather than
| mathematical performance. This was a memory copy function in
| one of the support chips (Agnes), that massiveky speeded up
| things like sprite and window movement and line drawing.
| galangalalgol wrote:
| Did the a1000 have hard floating point? I know it had a great
| f18 flight sim that seems like it would have been difficult
| with integer math, but people do amazing things with integer
| math.
| kstrauser wrote:
| No, it didn't. My first Amiga with an FPU was a 2000 with
| an A2630 accelerator card.
| wmil wrote:
| The early VGA chipsets were very slow. They also didn't have
| any of the sprite & tile features that Amigas had.
|
| On a generic 286 you could swap out the stock ISA VGA video
| card for a Diamond SpeedStar and the improvement was crazy.
| LargoLasskhyfv wrote:
| That was still true with VLB(VESA Local Bus) and later
| revisions of the Tseng ET4000 chipset. Which was what made
| the SpeedStars fly. (At 50Mhz! Harr!)
| bombcar wrote:
| carmack and friends getting sprites to work on DOS machines
| was a technical feat. I think they used it for commander
| keen.
| 0x0 wrote:
| Strange error, why does it say "illegal instruction at ffffffff"
| but then the dump shows CS:EIP as 71a3:000056e5? Shouldn't the
| EIP part be :ffffffff or what am I missing?
| bcoates wrote:
| Yeah. Looks like the processor is in virtual x86 mode from the
| dump, maybe that causes weirdness in the OS/2 BSOD?
| Probiotic6081 wrote:
| hjjjjjj
| CapitalistCartr wrote:
| AutoCAD on a 386. With 8 meg of ram. No coprocessor, no AutoCAD.
| At least none of his trying to figure it out; it was cut & dried.
| achairapart wrote:
| AutoCAD for DOS shipped at some point with a cool NASA Space
| Shuttle demo, I remember seeing it render (can't remember if on
| a 286 or 386) without a co-processor and it took several
| minutes, as each line slowly rendered on screen.
|
| The same demo with the same machine now equipped with a co-
| processor, it took just a few seconds.
|
| As a kid, I knew nothing about FPU nor math co-processors but
| that incredible speed bump had a long lasting impression on me.
| Animats wrote:
| AutoCAD was supposed to require a math co-processor, but
| there were software co-processor emulators available which
| could, slowly, do floating point. That's probably what you
| saw.
|
| AutoCAD was 64-bit floating point (and sometimes 80-bit
| internally). Trying to do 80-bit floating point computations
| on a 16-bit CPU was painfully slow. Previous low-end CAD
| systems were 32-bit, and large drawings would have errors.
| That's why the Golden Gate Bridge drawing was a common
| AutoCAD demo. Zoomed out, you could see the whole bridge, and
| you could zoom in on the details. Big selling point.
|
| (I did some of the early AutoCAD ports. Not all DOS machines
| were fully compatible with the IBM PC. There were many 80286
| machines which were _mostly_ -compatible. Each needed its own
| software. Every display, mouse, and plotter needed its own
| driver. Autodesk had a big room in Sausalito with one each of
| everything they supported. For a while, it looked like the
| Texas Instruments TI-Pro was going to win, because it had a
| color display good enough for text. But it was an awful
| computer. No memory parity and bad parts. I had to compile
| everything twice and compare the results.)
| andyferris wrote:
| Oh man I used to love BattleTech on the '286! (Yes we had a
| coprocessor, doubt it mattered).
|
| I kinda wondered why no one made RPG games in the BattleTech
| universe? The MechWarrior series was fine, but there's so much
| plot and intrigue that could be explored in this universe, and
| just _existing_ as a human around all these big machines could be
| pretty intense.
| andyferris wrote:
| Another fun fact - I cut my teeth as a little kid hacking my
| BattleTech (Cresent Hawk Inception) save games in XTree-Gold. I
| can still remember the ASCII symbols and the rough layout of
| the save files. I'd max out my teams stats and skills, stick
| extra weapons on our mechs (they even programmed in powerful
| ones that weren't actually in the game) and mark the map as
| explored. EDIT: I even got so much money it would accidentally
| wrap around when you got some interest from the bank or
| whatever (it was some small signed integer type) and then you
| couldn't spend anything, lol.
| kebman wrote:
| This sure brought me back. <3
| h2odragon wrote:
| I'd suspect PS/2 compatibility problems, or "old machine"
| problems like dust in the empty socket that no longer makes
| contact when the socket has been filled with the FPU chip.
|
| PS/2 systems weren't fully "PC compatible", there was lots of
| stuff they would have trouble with. They had different port
| ranges and the BIOS had some infelicities as i recall.
| scruffyherder wrote:
| I used a lot of compressed air on the socket and it made no
| difference.
|
| Old DOS 5 ran fine along with OS/2 1.21. The upgrade to 6.123
| went fine, it's just something else weird .
|
| Sadly I don't know if any other 386 fans to give this a shot
| freedomben wrote:
| This is tangential to the article and somewhat meta, but as I
| remember old video game cover art and ads (and seeing the
| pictures in the article), it occurred to me that we're finally at
| the point where (sometimes) the actual game looks as good as the
| cover art. That's a pretty remarkable achievement!
| patwolf wrote:
| I had the Maxis game El-fish, and the part of the game where
| you'd breed fish was almost unplayable on a 486SX because the SX
| lacked a math coprocessor. I wanted a math coprocessor, but as a
| kid in pre-internet times, I had no clue how to get one.
|
| Maybe I'll try playing in dosbox and see what I was missing out
| on.
| h2odragon wrote:
| Technically, you _had_ one on the 486SX, it was just disabled.
| Probably*
|
| As I recall the "co-processor" slot on those boards was another
| CPU slot, with an extra pin; and when filled it took over and
| disabled the original CPU.
|
| Edit: later 486SX may not have had FPU:
| https://retrocomputing.stackexchange.com/questions/12109/wer...
| achairapart wrote:
| I read many times that 486SXs were rebranded 486DXs with a
| defective co-processor unit, don't really know if it was
| rumors or just plain fiction.
| Sohcahtoa82 wrote:
| Seems perfectly plausible. CPU binning has been being done
| for years. Made an 8-core chip, but one core is faulty?
| Disable some cores and sell it as a 6- or 4-core chip. Chip
| won't run at the frequency expected? Sell it as a lower-
| spec CPU.
|
| https://en.wikipedia.org/wiki/Product_binning#Semiconductor
| _...
| acdha wrote:
| There is some discussion here:
|
| http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/
|
| My guess is that if there's any truth to it that was early
| on before the process was fine-tuned. It's hard to believe
| Intel would have tolerated a process producing that many
| errors since they could use the same die space to make more
| smaller chips.
| MBCook wrote:
| I loved that game.
|
| But you should have tried breeding on a 33 MHz _386_ SX. I
| think I had to let it run overnight.
|
| My next computer was a Pentium 133. The difference in fish
| breeding was mind blowing.
| zitsarethecure wrote:
| I remember the day I got my AMD 287 co-processor for my old
| Samsung 286. IIRC I ordered it from an ad I saw in Compute!
| magazine. At the time I had this book about writing fractals in C
| and I went back and recompiled all my code to use the co-
| processor instead of the emulation library that came with Turbo
| C, what a revelation. These days I only buy CPU's with math
| coprocessors.
| yjftsjthsd-h wrote:
| > These days I only buy CPU's with math coprocessors.
|
| ...is there any other kind anymore? Unless you work with
| microcontrollers, at least.
| foxyv wrote:
| That's a bit of a joke. It's like saying, "I only buy cars
| with an electric starter now!"
| yjftsjthsd-h wrote:
| Okay, thanks, I wondered if that was the case but I wasn't
| sure I was reading it right
| rbanffy wrote:
| I could never find x86 AIX anywhere. Does it work well with
| emulators?
| uptown wrote:
| Good memories. I had a Quantex 386 DX 40 with a math coprocessor.
| I used to churn out 3D Studio images one rendered block at a time
| over hours and hours and hours.
| lacrimacida wrote:
| And I remember downloading 3D rendered images from BBSes back
| when I couldn't produce them myself, was a kid at the time and
| 3D Studio was way above my abilities or computer power, had an
| XT then an 286 AT. Good times
| johnklos wrote:
| While playing around with modern NetBSD on a system with just 10
| megabytes of memory, I ended up getting and adding an m68881 just
| so that I could remove the floating point emulation code from the
| kernel to save a few kilobytes.
|
| OTOH, who doesn't like to toy around with the power to do 100,000
| floating point operations a second? ;)
|
| I do hope the author figures out the cause. The issue is an
| interesting one.
| 1970-01-01 wrote:
| The best 386 was the 486DX because it actually ran everything the
| 386 was supposed to run :)
|
| https://en.wikipedia.org/wiki/I486#Improvements
| neilv wrote:
| At the time, you could also get a math coprocessor for the Apple
| Macintosh:
|
| https://ncsa30.ncsa.illinois.edu/wp-content/uploads/2016/02/...
| johnklos wrote:
| The person in that photo has a very Moss-esque esthetic ;)
|
| The m68881 and m68882 are very good FPUs, and m68882s have
| continued to be made all the way through at least 2012,
| apparently. I recently bought one that was made in 2012 with
| Motorola, not Freescale, markings.
| gopher_space wrote:
| I remember running a software fpu on a Mac, I think to play a
| neat little game called Avara.
| mrighele wrote:
| My father wanted a computer for doing CAD, so of course he needed
| a 387 beside the 386.
|
| From what I remember, unlike the 386, for which both Intel and
| AMD models were available, the 387 was produced only by Intel,
| which meant that the cheaper and more performant 40MHz AMD
| processor had not a corresponding FPU, so if you needed floating
| point operations you had to spend more money for a slower CPU.
|
| What he ended up doing instead, was to get a relative to assemble
| him a PC with a 40MHz AMD 386 and a 20MHz Intel 387. Surprisingly
| it did work, as long as one would remember to press the "Turbo"
| button to slow the 386 to 20MHz before using the CAD software
| otherwise it would crash.
|
| The rest of the software would happily work at 40MHz
| Narishma wrote:
| IIRC you could have a 386 with a 287 co-processor.
| oaktowner wrote:
| OMG I had forgotten all about the "Turbo" button. Great story,
| and thanks for the trip down memory lane.
| enobrev wrote:
| I remember them well enough. But this is the first time I've
| ever heard of an actual use for it.
| plasticchris wrote:
| It was useful for some old games where the frame rate was
| tied to the cpu frequency.
| ChrisClark wrote:
| That's interesting. I specifically remember buying a math
| coprocessor for my AMD 386DX-40. My motherboard definitely had
| the slot for a dedicated co-processor though, maybe that was
| the difference.
| NiloCK wrote:
| Low value comment, but I'm astounded some 30 years later to
| learn there's such a thing as a 387 processor.
|
| ... one more!
| vondur wrote:
| I remember my first Mac lacked a math coprocessor. It was the
| Motorola LC68040, and it came with Quadra 604. I seem to remember
| it making Excel slow at doing some calculations. My next Mac was
| a PowerPC, I don't remember any of those lacking math
| coprocessors.
| krylon wrote:
| I think PowerPC had the FPU builtin from the beginning.
| HankB99 wrote:
| > Well it's been no secret, but OS/2 6.123 on my PS/2 model 80,
| is insanely unstable running simple MS-DOS based games (large
| EXE's)
|
| Lost me here. I developed several systems based on OS/2 (both 16
| and 32 bit) and don't recall this kind of stability issue.
| Different use case, I guess. I was using IBM's C/C++ tool chain
| and did some scripting in REXX, no big DOS games.
| Narishma wrote:
| The 6.123 version they're using is a pre-release version,
| either a beta or an alpha. It's not surprising that it isn't
| stable.
| neilv wrote:
| It's not surprising that the PS/2 model 80 would have MS-DOS
| games compatibility problems, even if running PC-DOS or MS-DOS
| rather than OS/2.
|
| The Model 80 was one of the first-gen PS/2 systems (which tried
| to replace the original IBM PC's fairly open industry standard
| architecture with things like MCA).
|
| IIRC the Model 80 was also IBM's first '386 PC, though IBM had
| been beaten to the '386 PC (first by Compaq and Advanced Logic
| Research, IIRC).
|
| Also, for a long time, MS-DOS games didn't necessarily work out
| of the box even on more conventional PCs, and you might have to
| mess with drivers, IRQs, etc.
___________________________________________________________________
(page generated 2023-11-13 23:00 UTC)