Hacker News Reader

Comment by klodolph | Hacker News Reader

According to history, there were three microprocessors in the running for the IBM PC. They were the Intel 8088, the Motorola 68000, and the Texas Instruments TMS99000.

If I remember correctly, the Intel had lots of 8088s available immediately (so IBM could do things like lifecycle testing), and Motorola did not have enough 68000s available yet. IBM was concerned about how much memory you would be able to use with future iterations of the 99000.

The 68000 series did see use in the Macintosh, Amiga, Sharp X68000, and it completely dominated the Unix workstation space in the late 1980s. There were a lot of companies who thought, “I’ll buy a Unix license, buy some M68000s, and sell workstations.” Most of these companies disappeared. Later Unix workstations used all sorts of architectures.

View on HN

Right, the 68k was the most logical step up from the early 8 bit processors in typical home computers (except for the TI99/4a which went in another direction). They were easy to design for, and easy to program (68k assembler is pretty elegant). The 68008 as mentioned was used in the Sinclair XL, with the 32 bit bus versions in the ST/Amiga/Mac. Initially limited to a 24 bit address bus, but when a machine was topping out at 1Mb, 16Mb seemed a long way away!

I think the MMU was introduced with the 68020, which then appeared in early Sun 3s, and HP9000s, prior to the RISC invasion. Those machines seemed super fast at the time.

As an Atari ST user, I was a big fan of the 68k back in the 80s but even I'd have to admit that the 808x architecture made the most sense for IBM to take given that it offered continuity with the CP/M S100-bus 8080/z80 machines that were fairly dominant in the nascent "business computing" market at that point.

Forking CP/M (cuz let's admit that's basically what PC-DOS was) and offering something similar-but-different to those systems was low-risk. And their original intent in fact was to in fact sell a full-on CP/M machine.

FWIW the Atari ST is what you get when you take a CP/M/PC-DOS-style OS and bolt it onto the 68k. Syscalls were basically 1:1 with MS-DOS, and even used an MS-DOS compatible filesystem. But big-endian. If you want to see what an IBM PC built around the 68k would have looked like, that's not far off.

So maybe being a bit pedantic here, but the Atari ST was originally going to use CP/M 68k, but part way through development they changed the base OS from that to what was more of a MS-DOS clone (which as others have said was also mainly a CP/M 80 clone). I think this was done to have better compatibility with the GEM layer, so the Atari ST OS, TOS, was more like MS-DOS than CP/M.

It would be interesting to port TOS (or more likely EmuTOS) to this 68k IBM PC and kind of go full circle.

The 68000 has a 16 bit data bus.

(I always assumed it's 16 bit internally as well? Longword unary register operations take slightly longer than their word equivalents, even though the instruction is the same size in both cases.)

> I always assumed it's 16 bit internally as well?

Correct, it's mostly 16-bit internally. Registers are 32-bit, but are split into 16-bit halves. The ALU is mostly 16-bit, but has a 32-bit shift register which is used for both shift/rotate operations and multiply/divide. There's a 32-bit adder in the "address unit" that's used for effective address calculations (including the LEA instruction), but it's much more limited than the ALU

The best part was that, no matter the size of internal or external buses, the programming model was 32-bit and extremely consistent. It was (and still is I suppose) so nice to write assembly code for it.

  > I think the MMU was introduced with the 68020

Apparently it was possible to use MMU even with 68000. A few months back someone on HN was describing on how they implemented it, even if 68000 wasn't designed for it (?) -

From: https://news.ycombinator.com/item?id=34762508

  "The Sun-1 workstation used a Motorola 68000 CPU at 10MHz. This was paired with an in-house designed MMU. It had 256K zero wait state memory with parity, and 32K EPROM memory."

The Sun-1 MMU was a base/bounds swapping MMU, not a VM paging MMU. The Sun-2 and Sun-3 had the full monty VM MMUs.

Nope.

The Sun-1 MMU was segment and page registers indexed hierarchically off the physical addresses.

It was a full page based system with segment and page level sharing and protection.

The 68000 didn't support restart from page faults, so the runtime model was indeed segment level swapping. (Note - not what Linux decided to call swapping)

68010 solved this, with a new stack frame format for page faults that had enough information to resume.

Most of these early m68k UNIX boxes used the 68010 for that reason.

Besides the tight loop optimization, the other 68010 changes, like move from SR being privileged (new from CCP unprivileged) are bugfixes.

Motorola sold an MMU that was paired with the 68020 - the 68851, but the likes of Sun kept using their own (which were simple to implement, a few fast SRAMs and a little TTL). The 68010 was the earliest family member that supported clean instruction restart on a page fault and had its own, infrequently used MMU - the 68451. Again most system vendors preferred to do their own. If you wanted "real" virtual memory on a 68000, you had to do kludges like running 2 68ks in parallel, switching on every page fault.

Motorola seemed to like their separate MMU chips. I don't remember the exact models but some of their (largely unsuccessful RISC) 88K processors had one too.

You didn't have an option with at least the initial 88k. They couldn't fit it all into one chip so you had to buy one 88100 and at least one 88200. The next gen 88110 was single chip.

You didn't have to have an 88200, particularly for embedded apps. The 88k based NCD X terminals don't have an 88200 for example.

I'd add that I never programmed for the 68K but the 8088/8086 segment register model was a real pain for low-level programming. (https://en.wikipedia.org/wiki/X86_memory_segmentation) They were also little endian which is arguably less intuitive when you're twiddling bytes at a low level.

They figured out how to use 16 bits of register space to represent a 12 bit memory address. I understand there were reasons for doing it this way, but it was painful.

20 bit but yes :-) It was doubtless a clever hack given the constraints they were operating under but still a pain for real mode assembly programming, especially if it was memory constrained. At one point I needed to separate out code from in-memory data store for a DOS file manager to support larger directory sizes and the segment register switching got really ugly.

Yes! Thank you, it used two 16 bit registers to represent a 20 bit address

As long as we're playing "what if," it's worth reflecting on all the hair-raising hacks and tricks Microsoft had to play to deal with the x86's quirks as they built Windows. XMS/EMS and DPMI were also incredibly painful engineering feats.

While the M68K had its own growing pains (as seen with the evolution of the Macintosh), none of them seemed nearly as onerous as what was done to squeeze a few more years out of MS-DOS compatibility.

? The early mac memory manager in macOS was idiosyncratic to put it lightly. By the time multifinder was integrated into macos, one might say that it was far worse than anything MS was dealing with. I mean at that point they were performing many of the functions we depend on MMU's for these days in software.

I guess in a way the complexity of the PC has more to do with the wide range of platforms, software stacks, etc that were being supported more than the architecture itself.

Don't forget that Intel had an incumbent advantage: the IBM Displaywriter used the 8086 processor [0]. IBM was already familiar with integrating Intel microprocessors into their equipment.

[0] https://en.wikipedia.org/wiki/IBM_Displaywriter_System

Also saw use in soda machines… SEGA genesis…

And Palm devices.

In the mid to late eighties, the MC68K was also often used in high end (small series) test&measurement equipment, e.g. HP3458A and Datron 1271/1281 DMM, HP166x{A,B,C} logic analyzers ...

IIRC, it was also frequently used for arcade games, and office printers, too.

The 68000 is one of the most successful embedded CPUs of all time and you could buy the CMOS varients, 68HC000 and 68SEC000, brand new from NXP until maybe two years ago ago, and derivatives of it (the Coldfire series) are still available - though most or all of them are "not recommended for new designs" now. I think at least some 68ks are still being made by Rochester Electronics, a company that specializes in keeping old chips in production.

I have seen 68000's and 68020's in everything from musical instruments to electronic measurement equipment to office equipment and networking hardware made into the late 90's at least. The Coldfire series has probably been all but killed off by small ARM chips for complete new product families now, but I'm almost certain you'd be able to find several of them if you went to your local appliance/electronics store today and started taking stuff apart.

Realistically in ~1980 or so the "weaknesses" of the x86 weren't so apparent. It was 1/2 way between the 8-biters (6502, 6800, etc) and the newer unproven designs. Back then even the expensive apple /// was limited to 128K of ram and bank switching was common so having the x86 segment+offset was a big improvement. And of course the 8086 was a more mature design, etc.

And frankly despite people wanting to rewrite history there was never a time when the 68000 was clearly a better processor. Yes years like 1985 when the amiga was released machines it showed up in looked light years ahead, but software compatibility/optimization/etc meant that within a year or so the PC was either on top or close to it again. It wasn't really until the early RISC machines started showing up that the PC was solidly eclipsed for more than a couple years straight.

And many of the technical things people complained about (segmentation, few registers) either were partially false by the time they were complaining about them (ex the 386 provided flat 32-bit addressing in 1985, and even windows/386 was only a year and a half later) or net really a consideration. Ex: pascal/c compilers hid register pressure and caches sped up stack spilling/etc.

> And frankly despite people wanting to rewrite history there was never a time when the 68000 was clearly a better processor.

I was amazed to see Domain OS SR9 running on 20 MHz 68020 CPU with 4 MB of RAM a multiuser, multitasking, (GUI), network distributted OS with diskless clients and file versioning.

Reply on news.ycombinator.com