[HN Gopher] Non-PC compatible x86 computers (2007)
___________________________________________________________________
Non-PC compatible x86 computers (2007)
Author : lproven
Score : 93 points
Date : 2024-01-09 16:49 UTC (6 hours ago)
(HTM) web link (lproven.livejournal.com)
(TXT) w3m dump (lproven.livejournal.com)
| rbanffy wrote:
| Is that information available in other articles?
| lproven wrote:
| I think I salvaged the content but not the references.
|
| All the computers are a matter of historical record, for
| instance.
| rbanffy wrote:
| I was wondering whether the information was distributed into
| other articles. If all the mentioned computers had their own
| articles, this one can be turned into a list.
| rwmj wrote:
| I'm going to guess this article was deleted because of the no
| original research rule
| (https://en.wikipedia.org/wiki/Wikipedia:No_original_research).
| Much as I hate Wikipedia deletionism/deletionists, this is
| usually a good reason not to keep articles.
| aftbit wrote:
| But now that he has published this as a blog post, could I
| rewrite it, cite his blog post and whatever sources he cited,
| and repost to wikipedia?
| grotorea wrote:
| Very likely to run afoul of both notability (one source is
| generally not enough) and reliable source (A blog post? From
| who?)
| Zenst wrote:
| Probably, even cite this post on HN as well and go for the
| double - reference it and guarantee be some YT vids as well
| that go into this era of history.
| lproven wrote:
| I think you can see a contemporary comment to that effect on
| the blog post. :-)
|
| I think I _wrote_ it in 2006 and it was deleted in 2007. The
| spur to write it was the release of the first Intel-based
| Macs, which was 2006.
| MrBuddyCasino wrote:
| There are rumours that low-tier newspapers do this for
| interested parties if you give them some cash.
| qingcharles wrote:
| Not even low-tier in 2024. Money is scarce. I can think of
| some very big newspapers that will include articles for
| cash these days. You can find contacts to get this done for
| you in certain forums :)
| pdpi wrote:
| Wikipedia prefers secondary sources to primary sources (as
| befits an encyclopaedia), and the blog post is a primary
| source for most of its content, so it would still be frowned
| upon.
| andrewla wrote:
| This would be a secondary source -- the primary source
| would be the manufacturers themselves. Secondary doesn't
| mean that there is no original research; in fact it's the
| opposite. Primary contains facts but no analysis or
| synthesis, secondary references facts established elsewhere
| but adds context.
| lamontcg wrote:
| Yeah and it reads like a blog post and not encyclopedic. Stuff
| like this sentence:
|
| > Aside from its low hardware specification, perhaps the
| biggest perceived "design flaw" of the IBM PC was the what is
| nowadays called Upper Memory Area [...]
|
| IDK what the correct wikipedia response to that would be but
| probably citation required and NPOV. It could be made more
| neutral by rephrasing just to "The IBM PC architecture located
| I/O pages at the top of memory, limiting available RAM to 640
| KiB. Alternatives such as the Victor located I/O pages at the
| start of memory allowing for 800-900 KiB of RAM". Let the
| reader come to the conclusion that they did this to try to
| improve the architecture, and don't assert that those
| architecture choices were qualitatively better, don't assert
| any opinions.
|
| It just sounds like the author is pleading a bit for the reader
| to see that other alternatives made qualitatively better
| choices.
| brokensegue wrote:
| It was deleted for being an "Unencyclopedic essay" which seems
| right.
| https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...
| bryanlarsen wrote:
| Missing https://en.wikipedia.org/wiki/PC-98
| lproven wrote:
| [Author/submitter here]
|
| True. I didn't know anything very solid about them at the time
| -- and not much now, TBPH.
| ikejix wrote:
| And his big brother APC
| https://en.wikipedia.org/wiki/APC_series
|
| NEC version of Alto: PC-100
| https://en.wikipedia.org/wiki/NEC_PC-100
|
| And their competitor FM-Towns
| https://en.wikipedia.org/wiki/FM_Towns
|
| These are used x86 CPU.
| tzs wrote:
| Although PC-98 was not PC-compatible, Microsoft did support
| it in DOS and Windows. Programs that just went through DOS or
| Windows and didn't make lower level BIOS calls directly or
| try to manipulate hardware directly would frequently just
| work out of the box on PC-98.
|
| The biggest difference between PC-98 and PC compatibles the
| DOS/Windows didn't hide that I remember, and that I remember
| being the biggest source of DOS/Windows programs failing even
| if they weren't doing low level calls was drive letter
| assignment.
|
| On PC-98 A: was the drive you booted from. If your system had
| a floppy drive and a hard drive, and you booted from hard
| drive then A: would be your hard drive. B: would be your
| floppy.
|
| In a PC-compatible A: would be the floppy and C: would be the
| hard disk regardless of which of the two you booted from.
|
| Quite a few programs turned out to have "C: is the first hard
| drive" hard coded in.
| Longlius wrote:
| There's a great channel on Youtube called Basement Bros that
| goes over a lot of the games available at the time for the
| PC-98 (and other outmoded Japanese home computer platforms)
| and also touches on how these machines were used day-to-day.
| Definitely worth a look, especially if you have any interest
| in the history of Japanese game development as a lot of very
| high-profile people got their start writing games and
| applications for the PC-88, PC-98, MSX, etc.
| soliton4 wrote:
| i was expecting to find the nokia 9000 on this list. does this
| mean it was actually pc compatible?
| cdcarter wrote:
| According to https://en.wikipedia.org/wiki/AMD_Elan the SC4xx
| series _did_ have "PC/AT peripheral controllers".
| legitster wrote:
| While a useful document, it's really not a Wikipedia article.
| It's making an argument, has a thesis statement, doesn't
| reference anything, and doesn't have a neutral point of view.
|
| https://en.wikipedia.org/wiki/Wikipedia:Five_pillars
| Macha wrote:
| For recent examples, there's the PS4 and PS5. (I think the Xbox
| is a little more PC compatible?)
| wmf wrote:
| Interestingly, there are PC motherboards using PS5/Xbox SoCs
| that can run Windows so there must be decent PC compatibility
| in the SoC even if the consoles don't use it.
| foobiekr wrote:
| The Zenith Z100 series, Dec Rainbow, and Epson QX-10+ would have
| been interesting to include. There was a very, very rich set of
| non-IBMPC MSDOS machines in the period. IIRC MS-DOS early on
| included tools written in a variant of Forth so that portability
| was easy and memory use was tight.
| derefr wrote:
| How about the opposite: PC-compatible non-x86 computers?
|
| Like how the Transmeta Crusoe was an x86-compatible CPU... but
| moreso.
|
| The Crusoe was a thing marketed as a "CPU", that was actually
| internally an SoC (with the CPU inside it being non-x86.) This
| SoC had its own internal RAM and storage, and booted itself into
| internal software that then emulated an x86 CPU. All of the "CPU"
| data pins on the Crusoe SoC, routed to the virtual CPU inputs and
| outputs of this software. So, as far as other devices in the
| system were concerned, they were speaking to an x86 CPU.
|
| Did anyone ever try taking this concept further? Maybe in the
| context of an industrial embedded computer?
|
| I could imagine someone taking e.g. a modern ARM SoC with onboard
| RAM + eMMC; setting it up to boot into e.g. Bochs to emulate a
| virtual x86 (CPU + BIOS + other memory-mapped ROMs + platform
| controller hub + IO controllers + timer chips + TPM + etc -- all
| the stuff on an x86 motherboard) -- and then just setting up the
| SoC's GPIO pins to directly expose all the virtual buses of that
| virtual motherboard. You could then take such a chip, and design
| a physical "motherboard" for it to sit in, that's just a bunch of
| ports (e.g. PS2) and slots (e.g. ISA or _maybe_ very slow PCI)
| routing directly to the SoC 's GPIO pins.
|
| This would be a very effective strategy, I think, for producing
| low-cost host platforms for the many industrial-automation ISA
| cards that still exist. So I have a feeling some OEM has at least
| _tried_ to do this.
|
| Probably there wouldn't be enough GPIO pins for most busses --
| x86 CPUs have _tons_ of pins compared to almost any other
| architecture. So I wouldn 't consider it cheating to feed
| parallel busses out serially at higher clock rates than those
| busses natively run at, and then to require the use of an
| external ser/des chip or two to flatten the signals back out. As
| long as it's the SoC itself speaking the protocol and the chip is
| "dumb", I think that'd still count.
|
| Also keep in mind that unlike with the Crusoe, an "x86-on-ARM
| SoC" _wouldn 't_ need to have GPIO fast and wide enough to talk
| to external DRAM -- as any memory could be internal to the SoC
| without breaking the contract. So the main constraint
| bottlenecking the Crusoe's CPU performance, wouldn't apply here.
| This thing _could_ actually perform decently well -- possibly
| well enough to run hard-realtime industrial control software
| coded in the 1990s, and to speak to ISA cards built in the 1990s.
| Which is all it would need to be able to do, for the obvious use-
| case.
| bitwize wrote:
| People are already doing this. The PiStorm is a daughtercard
| that takes a Raspberry Pi running a 68000 emulator and exposes
| the pin-level interface of the 68000 to the host system. You
| can drop one into an Amiga's CPU socket and have an instant
| performance boost, plus the PiStorm is running additional
| software that lets you access the Pi's file system and
| operating system from the Amiga side. Compatibility for old
| Macs and Atari STs is coming soon as I understand it.
|
| The things Amigaheads will do to keep their old hardware
| running and useful in the current era are... kind of insane.
| derefr wrote:
| What you're describing here is still _CPU_ emulation (same as
| the Crusoe), not _system_ emulation.
|
| The Amiga equivalent for what I'm hypothesizing exists here,
| would be something that allows you to throw out the entire
| guts of your Amiga and replace it all with a freshly-printed
| PCB that has all the same ports/socket, but just one (modern,
| easy-to-source) chip on it, that internally emulates not only
| the 68000 but also all the other chips on the Amiga
| motherboard. And then anything you plugged into the original
| Amiga, would plug into this replacement board and work the
| same.
| cjdell wrote:
| Would that not just be something like a Raspberry Pi
| Compute Module running an emulator full screen and a custom
| IO breakout host board?
| derefr wrote:
| In most designs I've seen for projects like this, the
| "custom IO breakout host board" isn't really _just_ a
| breakout board -- it has a lot of bus controller chips of
| its own, because most modern bus protocols are just too
| fast /expensive to be run over GPIO pins. These extra
| chips usually raise the BOM past the point where it's
| worth it to build such a system; as at that point it's
| cheaper to just source old x86 parts (controller chips,
| _sometimes_ CPU as well) from e-waste.
|
| You want as much of that "motherboard logic" to be
| handled internal to the SoC as possible. Ideally, the
| board should only have the one SoC chip on it, plus
| jellybean parts and passives, plus ports and slots.
|
| Also, let's lean on your example of video for a moment:
| "running an emulator full screen" isn't nearly the same
| thing as emulating the host busses -- in that it results
| in the host _describing_ that screen down its own SoC
| pins using something like HDMI. Whereas we don 't even
| necessarily _want_ a precomposed description of the
| screen on a signal line.
|
| Remember, we're emulating the CPU _and motherboard_ (and
| RAM, just because it 's impractical not to) inside the
| SoC -- but video support isn't actually an inherent part
| of an x86 motherboard. OEMs might integrate support for
| it onto a motherboard -- but that "support" is just an
| embedded PCI-bus device, not some separate VGA bus.
|
| Perhaps the system this board would revitalize, does
| something special with the _communicated changes to the
| video data_ , such that pre-composed VGA (let alone HDMI)
| wouldn't solve the problem. For example, what if the
| system uses a custom PCI video card, that takes its VRAM
| and renders it out each frame, by compositing it together
| with another input video signal (ala the "video toasters"
| of the era)?
|
| The only way to make that kind of thing work, is to
| emulate the PCI bus such that you can just plug the
| custom video card into one of the board's PCI sockets,
| and the emulated system will pick it up and use it.
| weinzierl wrote:
| Back in the day there were so called _" sidecars"_ for the
| Amiga. They had an x86, probably 80268, and were used to run
| PC software on the Amiga.
| nathan_douglas wrote:
| Sun had a similar thing!
|
| >According to Sun documentation the "... coprocessor card
| is not just PC-compatible, it is an actual PC that is
| constructed from real PC components and follows the de
| facto and emerging PC hardware design standards."
|
| https://en.wikipedia.org/wiki/SunPCi
| sillywalk wrote:
| IBM had(has?) something like this for their
| AS/400/iSeries.
|
| The Integrated File Server, then Integrated Xseries
| Adapter
|
| A card with a mini X86 Server inside, running Netware,
| OS/2 or Windows NT, that could use the AS/400's storage
| and peripherals.
|
| https://try-
| as400.pocnet.net/wiki/The_Integrated_PC_Servers
| tssva wrote:
| For a few years my work computer was a Sun Ultra 5 with a
| SunPCi card in it to handle email and office automation
| tasks. Both Solaris and Windows ran extremely slow on the
| system. It was truly a horrible thing.
| trelane wrote:
| I was a student Unix systems administrator back then. We
| had ultrasparc workstations, with a SunPCi card. I
| believe a number of us hooked up a monitor to the VGA
| connector on it, and used x2vnc to have a continuous
| virtual screen.
|
| https://fredrik.hubbe.net/x2vnc.html
| yjftsjthsd-h wrote:
| I've also been interested in a different kind of "PC-compatible
| non-x86", as in building a standardized architecture with all
| the normal pieces and just swapping out the CPU. It is 100%
| possible to make a machine with an arch64 CPU that boots using
| UEFI, handles device enumeration like a PC, has the usual buses
| and everything, lives in an ATX case, and in every way it looks
| and acts like a regular PC that just happens to have a
| different CPU.
| derefr wrote:
| I think the x86 "standardized architecture" is an example of
| Conway's law: it's a natural outgrowth of the way the x86
| hardware ecosystem evolved, with CPU, motherboard, and "card"
| manufacturers all being different companies that need formal
| standards to enable post-production integration (first by
| dedicated system builders setting DIP switches; then later at
| runtime with "plug and play"); _and_ with each party being
| incentivized to swap out partners / "commoditize their
| complement", and therefore wanting _constrained_ standards
| that ensure that they can design /code once to the standard's
| spec, and then switch suppliers without re-work.
|
| Other architectures that came into existence more recently --
| ARM mainly, but possibly RISC-V is going this way as well --
| are mainly employed to produce integrated devices in a more
| supply-chain-oriented way, with vendors producing and
| licensing _designs_ for "IP cores", and then device
| integrators combining these "IP cores" to fab SoCs.
|
| Conway's Law (and game theory) predict that such an
| arrangement would have no need for API standards. It's pretty
| hard to force an ecosystem to do something, when they have no
| natural incentive to do it.
| AnthonyMouse wrote:
| > It's pretty hard to force an ecosystem to do something,
| when they have no natural incentive to do it.
|
| You don't need an _ecosystem_ to do it, you only need one
| manufacturer, because the competing ecosystem already
| exists.
|
| Suppose someone produced an ARM or RISC-V system board in
| an ATX form factor with BIOS or UEFI and standard PCIe and
| memory slots etc. That's all you need -- then you use the
| same chassis, power supply, memory, expansion cards, etc.
| as any commodity PC without having to establish a new
| ecosystem for any of those things.
| derefr wrote:
| The problem isn't with the hardware compatibility for the
| external components, but with _software_ compatibility
| for the _internal_ components.
|
| "Adhering to x86 standards", would imply that the
| _software_ of such a device, must be able to do _unified
| management_ of hardware components -- both external _and
| internal_ -- through x86 facilities like ACPI. As, even
| if you 've got a system built out of (some)
| x86-compatible components, if you can't make use of
| software -- like drivers and OS subsystems -- _designed
| to assume the x86 system architecture_ on it, then what
| 's the point?
|
| So, for example, the SoC's GPU IP-core.
|
| Until about eight years ago, SoC-internal GPUs were just
| something directly memory- and IO-mapped at addresses
| hardcoded into proprietary device-specific drivers given
| by the IO-core developer to be (arbitrarily modified and
| then) compiled by the integrator. And even today, with
| DeviceTree, the DeviceTree descriptor for each of these
| devices is still something handed over out-of-band along
| with the core, and burned into the device's NVRAM or OS
| base-image by the integrator.
|
| But now, in getting that same GPU to support "the x86
| system-level architecture", the GPU would instead have to
| be "registered" somewhere inside the SoC in order for the
| SoC CPU to _probe_ and _discover_ it as a _PCIe device_
| -- with an ACPI DDST available within a UEFI-discoverble
| boot-ROM address mapping, that can be used to power-
| manage it _correctly_ (including complex things like the
| CPU being able to put the GPU _or its individual cores_
| into particular sleep-states through ACPI); with a PCIe
| HW device ID, that binds it to _generic_ drivers when
| available, rather than allowing for device-specific
| driver customization; etc. And all of the ensuing device
| initialization that the driver does, would have to occur
| _through_ ACPI and PCIe. Even though the core is internal
| to the SoC!
|
| Support for complex ACPI hooks, and a driver impl that's
| flexible enough to be runitme-configured to serve various
| devices' needs without integration-time customization (so
| that it can be upstreamed into OSes), are both things
| that the _IP-core vendor_ would have to implement.
| Currently, they are _not_ implementing those things --
| and mostly wouldn 't even know how. Being an IP core
| vendor -- where you're running a job-shop producing
| designs to spec for specific downstream integration
| projects -- isn't at-all the same job as being a
| peripheral card vendor _in an ecosystem_ , where you
| actually have to deal with all these concerns. The IP-
| core vendors would have to _learn_ how to do these
| things.
|
| And if you _don 't_ do this -- don't require this kind of
| software-visible x86-platform-ization for the internal
| IP-core hardware -- then what you end up with is a hybrid
| system that needs its OS to manage _both_ external PCie
| ACPI devices with generic drivers, _and_ internal
| DeviceTree devices with device-specific drivers --
| potentially also virtualizing one as the other whenever
| needed (by e.g. making up PCIe device IDs for the
| DeviceTree devices). And not even Linux knows how to deal
| with that[0].
|
| [0] If you're curious --
| https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-
| usi.... As stated, ARM BSA/BBR devices are expected and
| required to use _solely_ ACPI-registered device
| descriptions; such systems _don 't use DeviceTree at
| all_. This severely restricts ARM SBA/BBR OEMs' choices
| of IP-core vendors, as those vendors, mostly know nothing
| about how to produce cores compliant with ACPI, nor
| drivers generic enough to be signed, sealed, and used in
| ACPI environments -- let alone upstreamed. _This_ is what
| I mean by "an ecosystem problem"! And it's precisely why
| consumer SBCs -- that include all the nice-to-have
| features like _a GPU_ -- aren 't already SBR compliant!
| cpgxiii wrote:
| This is basically what the Arm SBSA does (UEFI + ACPI) and
| essentially how all arm64 (and arm32) devices that support
| Windows work. SBSA doesn't solve the dismal lack of drivers
| for hardware in consumer devices, though, so just because
| there are arm64 devices that can be booted with UEFI+ACPI
| doesn't mean they "just work" like we expect amd64 machines
| to.
| yjftsjthsd-h wrote:
| Yeah, I was actually thinking of SystemReady when I wrote
| my comment, and I have some vague understanding that
| Microsoft is all-in on it because ex. even their phones
| used UEFI, which is kind of beautiful. So the pieces are
| there, but sadly not nearly-universal like with x86 PCs:\
|
| Separately, I will grant that drivers are their own
| sticking point, but I would like for them to be
| approximately the _only_ sticking point. And even on x86
| drivers are a problem; Linux generally has good mainline
| coverage of _most_ networking cards, even wifi is good
| these days, but fingerprint readers have always been hit-
| or-miss. I just wish we could get to the point where once
| the drivers are upstreamed everything does Just Work and we
| can be free of "well this distro has a Raspberry Pi image
| but if you want to try an Orange Pi you need to find an OS
| that supports that _exact board_... "
| solardev wrote:
| Wouldn't it be simpler to do all this in software? What's the
| advantage of doing it in hardware like this?
| derefr wrote:
| That you can plug legacy x86 _extension hardware_ into the
| board, and have it find a bug-for-bug-compatible x86 system
| to talk to on the other end.
|
| A major use-case being embedded systems -- e.g. industrial
| control systems. These systems use a combination of 1. custom
| hardware -- usually in the form of peripheral cards -- built
| to speak old legacy x86-only bus protocols like ISA; and 2.
| old custom software, designed to run on an x86 CPU (usually
| in DOS), and to speak directly to that hardware over that
| bus.
|
| You can't just find some USB adapter for the old hardware's
| bus, because the software won't take it. And you can't just
| replace the old software, because the new software (whether a
| newer version of the old software, or software from another
| vendor) won't control the old card; and the card speaks an
| even _lower_ -level (probably analogue!) protocol specific to
| the industrial system.
|
| Often, on these old systems, the custom peripheral card is
| still working due to it being solid-state (and thank god for
| that; the card's vendor is probably long-gone!) but the old
| x86 box the card lived in for the last 40 years is dying of
| various old-computer maladies -- or just can't be made to fit
| into a new form-factor forced by a newer generation of the
| industrial system being controlled.
|
| In such a case, you ideally want to find a _new_ embedded
| host system, made of _new_ parts that will last you the next
| 40 years, but which can nevertheless still talk in very
| specific, custom, low-level ways to your existing peripheral
| card. And you also want that new embedded host system to be
| as cheap as possible -- because your factory-or-whatever,
| might have 400 of these embedded systems all over the place.
|
| ---
|
| Though, that being said, here's a completely different use-
| case.
|
| Consider "retro consoles" with cartridge slots, like the
| Retron 5. A lot of people don't like these, because they
| don't really do what it seems like they _should_ do. If an
| Electrical Engineer sees a "retro console" with e.g. a SNES
| cartridge port, then they'd assume that the console talks
| _to_ SNES cartridges over all the pins on the cartridge-
| system bus, just like a SNES does, to perform its functions
| -- that each synchronous virtual bus-read of the virtual CPU,
| would translate to a _real_ bus-read to the bus that routes
| up to "cartridge address-space"; where anything in the
| cartridge could then service that bus-read. And that SNES
| cartridges with custom chips in them, that override
| functionalities of the console on a per-bus-read basis, would
| therefore "just work" the same way they do on a real SNES.
|
| But our hypothetical EE will soon be disappointed to learn
| that these "retro consoles" _mostly_ + don't work this way at
| all. They only implement enough of the cartridge-system bus
| to do a one-time rip of cartridge's ROM banks on boot,
| loading them as a ROM image into system memory; and from then
| on all emulation occurs in-system, without the cartridge
| being involved at all. if the cartridge requires a co-
| processor, well, you might get the _effect_ of using it
| because the emulator deduced the _need_ for it from analyzing
| the ROM image, and so turned on an emulation of that co-
| processor. But you 'll never get such a system to make use of
| any cartridge component that didn't have support for it
| explicitly implemented into the retro console's emulator at
| design time.
|
| Ever seen this video
| (https://www.youtube.com/watch?v=ar9WRwCiSr0) about "reverse
| emulating" the NES? This custom NES cartridge with an RPi in
| it, can only possibly work on a "real NES." You can't put
| that cartridge into a Retron 5 and have it work.
|
| But this cartridge _would_ work on a board that is _bus-
| compatible_ with a NES. For the purposes of the trick, such a
| board would _be_ a "real NES."
|
| + There are FPGA retro-consoles that _do_ work this way! (The
| MiSTer, the Analogue Pocket, etc.) The MiSTer is very much a
| (hardware-accelerated) bus-compatible emulator. My only
| problem with it is that its own multi-platform flexibility
| means that it 's extremely high-BOM -- rather the opposite of
| the point here, which is to use emulation to _decrease_ BOM.
| johnklos wrote:
| There were lots of computers in the '80s which claimed official
| MS-DOS compatibility through emulation or added hardware. There
| were the Solution and Conqueror emulators for the Sinclair QL,
| there was Amiga Transformer from Commodore for the Amiga, there
| were ST Outlook and pc-ditto for the Atari ST.
|
| Not long afterwards, hardware made MS-DOS compatibility much
| better because the speed of MS-DOS could easily be as fast as
| or faster than real IBM hardware. There were many options
| including the Sidecar, BridgeBoards, KCS PowerPC, and more on
| Amigas. Later, there were DOS compatibility cards for Macs.
|
| Often these options had advantages over having a separate DOS
| compatible computer, like the ability to still run the native
| system at the same time, and often to share files / drives and
| other resources. It was an interesting time, for sure.
| Pxtl wrote:
| I mean MS is selling Arm based Windows machines now and I
| assume they're going to have to offer some kind of
| compatibility framework for legacy software.
| VSpike wrote:
| I had a couple of Sirius (AKA Victor) machines that were cast
| offs from my father's office given to me to play with. The first
| one was twin floppy, and the second had a 5MB hard drive. When I
| got the second one I think the first one got binned. When the
| second one broke, I bust it up to use the PSU and HDD on another
| computer. Of course, I really wish now that I'd kept at least one
| of them, but you never know at the time what would have value in
| the future and what is just junk.
| h2odragon wrote:
| My first exposure to "real" computers was with Victor machines.
| I may well have one in a pile somewhere still. I worked for a
| shop that was a Victor dealer, they had the fabled "PC
| compatible floppy drive" in a machine there. Later I was one of
| the few people with a PC that could read Victor disks; Copy2PC
| card For Tha Win there.
|
| They did "high memory" and iirc had slightly higher resolution
| text modes, which made them wonderful for spreadsheets.
|
| http://www.oldcomputers.net/victor9000.html
| starkparker wrote:
| When jumping in to suggest how this violated Wikipedia
| guidelines, note that this predates WP's current Policies and
| guidelines page (1, 2010) and the COPO essay describing core
| content policies (2, Nov. 2007).
|
| The Five Pillars page has changed quite a bit since 2007.[3] My
| favorite change, and only slightly tangential to the topic, is
| replacing this from 2007:
|
| > [[Wikipedia:Be bold|Be '''bold''' in editing, moving, and
| modifying articles]], because the joy of editing is that,
| although it should be aimed for, [[Wikipedia:Editing
| policy|perfection is not required]]. And do not worry about
| messing up. All prior versions of articles are kept, so there is
| no way that you can accidentally damage Wikipedia or
| irretrievably destroy content. But remember -- whatever you write
| here will be preserved for posterity.
|
| with this in the current policy:
|
| > [[Wikipedia:Be bold|Be bold]], but not
| [[Wikipedia:Reckless|reckless]], in updating articles. And
| [[Wikipedia:Editing policy|do not agonize over making mistakes]]:
| they can be corrected easily because [[Help:Page history|(almost)
| every past version of each article is saved]].
|
| An unintentionally accurate transition in how it felt to
| participate then and now, subtly excising any mentions of the joy
| of publicly but safely messing up and replacing them with
| assurances that you and your contributions can simply be erased
| from history if you make any mistakes.
|
| 1:
| https://en.wikipedia.org/w/index.php?title=Wikipedia:Policie...
|
| 2:
| https://en.wikipedia.org/w/index.php?title=Wikipedia:Core_co...
|
| 3:
| https://en.wikipedia.org/w/index.php?title=Wikipedia:Five_pi...
| terr-dav wrote:
| https://web.archive.org/web/20240109170221/https://lproven.l...
| tzs wrote:
| > Intel's 80386 processor was the first to include memory
| management hardware and thus be capable of running a full UNIX
| operating system
|
| That's not correct. The 80286 had sufficient memory management
| hardware for full Unix. What it did not have was sufficient
| memory management hardware for reasonable demand paging, but it
| was fine for swapping systems.
|
| AT&T USG has a port of System V Release 2 for 80286, for example.
| There was also Xenix, which has enough licensed code in it from
| AT&T that I'd count it as a Unix.
|
| There was also System V Release 3 fro 80286, but I don't think
| that was ever released. When AT&T was developing SVR3 for their
| own 3B line of processors they wanted to also port it to Intel
| processors. They hired Interactive Systems Corporation (ISC) to
| do that, with the contract calling for porting to both 80286 and
| 80386.
|
| I worked at ISC at the time and was on the 80286 port team. We
| did get it working, but where having problems getting the
| scheduler to behave reasonably under heavy load.
|
| Somewhere in the middle of trying to figure out what the heck was
| going on with the scheduler, we and AT&T realized (1) 80386 was
| so much better than 80286 that a lot of 80286 Unix users would
| upgrade to 80386 systems, and (2) those that are happy with the
| 80286 Unix systems and not planning on leaving 80286 probably
| would not find upgrading from SVR2 to SVR3 to be worth the
| effort. It wasn't all that clear that there was much of a market
| for 80286 SVR3.
|
| The 80286 port was then dropped. I was moved to work on the 80386
| port and also to a newly formed team to add support for running
| 80286 SVR2 binaries on 80386 SVR3. That was a fun project. Kind
| of like Wine, but easier because (1) it was just going from SVR2
| Unix to SVR3 Unix instead of Windows to Unix, and (2) we had full
| source code to SVR2 and SCR3 unlike the Wine developers who don't
| have Windows source.
| AshamedCaptain wrote:
| How do you define "Full UNIX"? Technically, even the 8086 can
| run Unix (or at least Unix clones like Coherent or even Xenix),
| just sans protected mode.
| glhaynes wrote:
| _The 80286 had sufficient memory management hardware for full
| Unix. What it did not have was sufficient memory management
| hardware for reasonable demand paging, but it was fine for
| swapping systems._
|
| Wasn't 16-bit OS/2 demand paged on the 286?
| AshamedCaptain wrote:
| Not "paging" per se (since the 286 doesn't have that, by
| definition), but demand loading/unloading of code is possible
| on a 8086, and even the original Windows does it (see https:/
| /devblogs.microsoft.com/oldnewthing/20110316-00/?p=11... ).
| glhaynes wrote:
| Whoa, OK, that is wild. What a mess!
| ShadowBanThis01 wrote:
| IBM-compatibles. They're still PCs.
| kube-system wrote:
| In this context it is referring to a specific product called
| "Personal Computer" made by IBM.
|
| Just like when someone says they bought a record on compact
| disc, they are referring to Red Book Compact Disc Digital Audio
| Standard. They're not referring to any other discs that are
| small.
| bryanlarsen wrote:
| A wild inclusion would be the IBM PCjr, which wasn't quite PC
| compatible. IBM didn't sell many, but Tandy sold a ton of PCjr
| clones, the Tandy 1000 et al.
| the_af wrote:
| The 8 Bit Guy makes a good case that the Tandy 1000 was the
| best "DOS machine" ever, even though it wasn't quite PC
| compatible.
|
| Makes me wish I had one back in the day. My first PC was an XT
| clone, and I never owned a Tandy.
| EvanAnderson wrote:
| I believe some of the early CTOS machines were x86 based but not
| PC compatible.
|
| https://en.wikipedia.org/wiki/Convergent_Technologies_Operat...
| Thoreandan wrote:
| Livingston Enterprises products (Portmaster and IRX routers)
| running ComOS were x86
| EvanAnderson wrote:
| Oh, good point. I didn't even think about embedded devices. The
| Cisco PIX firewalls were originally PCs w/ Intel motherboards
| (SE440BX, I believe) before becoming embedded x86 designs. I
| don't know how far the x86 legacy continued into the ASA and
| Firepower follow-up devices.
| johnklos wrote:
| It's a horrible title. "PC" means personal computer. It may be a
| bit pedantic, sure, but if you're going to write an article that
| talks about technical things, it really smarts to read such a
| glaringly non-technical title.
| the_af wrote:
| I don't know.
|
| Back in the old days, everyone understood what "[IBM] PC
| compatible" meant. PC meant something specific, not just a
| generic "personal computer", see
| https://en.wikipedia.org/wiki/IBM_PC_compatible.
| actionfromafar wrote:
| Back in the even older days, PC meant "Personal Computer" but
| quite soon after that it meant "IBM PC" (or compatible).
| kube-system wrote:
| "PC compatible" was a common shorthand reference to "IBM PC
| compatible" which was referring to a specific architecture
| compatible with IBM PC software, and later, that platform's
| descendants. There were many personal computers at the time but
| colloquially, the IBM PC was _the_ PC.
| kens wrote:
| Prior to the IBM PC, a personal computer was called a "personal
| computer", not a "PC". I assumed that IBM came up with the "PC"
| name, but after a few minutes of research, it seems that IBM
| called their system the "IBM Personal Computer" in the original
| ads and documentation, rather than the "PC". As far as I can
| tell, PC Magazine created the name "PC". At first, the magazine
| referred to the IBM "PC" (with quotation marks around PC),
| which suggests that this wasn't standard usage. I'm a bit
| surprised by the idea that the "PC" name was invented by the
| magazine, and I'm not 100% sure of this, but maybe someone can
| confirm or deny. It wouldn't be the first time a magazine has
| created the terminology; "electronics" apparently comes from
| the magazine, not vice versa.
| the-golden-one wrote:
| A number of arcade machines are x86 based, with non-pc-standard
| hardware, such as Z80 co-processors, etc..
|
| For example - Seibu SPI
| https://github.com/mamedev/mame/blob/master/src/mame/seibu/s...
| Doctor_Fegg wrote:
| RM Nimbus PC186. MS-DOS based but not PC-compatible, and used the
| rare 80186 processor. Popular in UK education for a while.
|
| https://en.m.wikipedia.org/wiki/RM_Nimbus
|
| The Wikipedia article on the 80186 lists a bunch of forgotten,
| often not PC-compatible, machines using that CPU:
|
| https://en.m.wikipedia.org/wiki/Intel_80186
| qingcharles wrote:
| MISSING: https://en.wikipedia.org/wiki/RM_Nimbus
|
| (very popular in British schools in the 80s and 90s and ran a lot
| of DOS apps)
|
| Glad to see Sirius Victor on there. They were very popular in the
| UK before IBM ate their lunch.
| nxobject wrote:
| Another fun one: the original OLPC XO-1 (2007?) had an AMD Geode,
| but ran on Open Firmware and had ad-hoc controllers and drivers
| for things that would have gone through ACPI, etc. Microsoft
| claimed they had Windows XP booting on one, but I've yet to see
| how that would have worked.
___________________________________________________________________
(page generated 2024-01-09 23:00 UTC)