5 ms·

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).

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.

cmrdporcupine 3y ago
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.
- jdswain 3y ago
  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.
tom_ 3y ago
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.)
- mikepavone 3y ago
  > 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
  - ebruchez 3y ago
    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.
jagrsw 3y ago
> 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 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."
- pinewurst 3y ago
  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.
  - cjsplat 3y ago
    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)
    - snvzz 3y ago
      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.
pinewurst 3y ago
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.
- ghaff 3y ago
  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.
  - pinewurst 3y ago
    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.
    - kjs3 3y ago
      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.
ghaff 3y ago
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 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.
- mordechai9000 3y ago
  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.
  - ghaff 3y ago
    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.
    - mordechai9000 3y ago
      Yes! Thank you, it used two 16 bit registers to represent a 20 bit address

cmrdporcupine 3y ago

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.

jdswain 3y ago
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.

tom_ 3y ago

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.)

mikepavone 3y ago
> 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
- ebruchez 3y ago
  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.

jagrsw 3y ago

> 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 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."

pinewurst 3y ago
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.
- cjsplat 3y ago
  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)
  - snvzz 3y ago
    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.

pinewurst 3y ago

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.

ghaff 3y ago
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.
- pinewurst 3y ago
  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.
  - kjs3 3y ago
    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.

ghaff 3y ago

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 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.

mordechai9000 3y ago
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.
- ghaff 3y ago
  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.
  - mordechai9000 3y ago
    Yes! Thank you, it used two 16 bit registers to represent a 20 bit address