> It could also have been the case that Microsoft did not have an operating system or BASIC ported to the Motorola 68000 architecture.
The late 70s / early 80s incarnation of Microsoft was happy to port their software to just about anything, so long as there was a customer willing to pay for it. If IBM had asked Microsoft for a 68K OS instead of an x86 one, Bill Gates would have found a way to provide. He bought PC/MS-DOS from another company, he probably could have found someone selling a 68K OS instead. Or Tim Paterson surely could have ported it to 68K if asked.
I think choosing the 8088 over 68K was all about hardware costs, not software-both the cost of the CPU, and the cost of compatible peripheral chips.
I don't have a source handy, but I remember reading it was because the 68k was too late to production; it was scheduled to be ready on time, but the Intel parts were already available, and IBM didn't want the risk
An alternate timeline where 68k was the dominant OS architecture?
Man what a fun thought experiment. Reminds me of Palm OS and their OS5 68k emulator on top of arm.
My own thought experiment - what if “old IBM” had intervened in the product and tried to make it more “IBM”. Well, if they’d done that too much - e.g. a corporate edict that it had to use EBCDIC instead of ASCII - that probably would have killed it commercially. But what if “old IBM” had just demanded ASCII-EBCDIC conversion in the BIOS? With a “code page” field in each directory entry, which could be used to mark files as ASCII or EBCDIC (0=binary), with the BIOS ASCII-EBCDIC conversion service invoked to make EBCDIC files appear as ASCII to applications? That might have made the product more “interesting”, without adding so much complexity as would kill it. z/OS Unix has code page tagging in the filesystem; apparently IBM tried to get it added to DOS during DOS 4 development, but it got pulled before release (although that was not for EBCDIC, just for tagging which ASCII code page a file was)
Maybe even demand some optional record-oriented support in the filesystem (e.g RECFM=F80). That would have been less alien to Microsoft than you’d think, because Microsoft BASIC always supported record-based file access.
IBM, of course, did use (re-microcoded) 68000’s in a PC product - the XT/370. With a modified 8087 on a couple of cards these were used to emulate an S/370.
A detailed description (with pictures) can be seen on page 278 and following ones of BYTE Magazine, February 1984 issue. The computer was branded as "IBM Instruments"
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.
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 ...
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.
(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.
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 (?) -
"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 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)
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.
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.
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.
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.
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.
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.
Oh man, 15 registers, each 32 bits wide, with indirect addressing modes... it would have been glorious! No more weird need to cram things into just the right registers to do a string operation.
Not as nice as a PDP-11 processor, but damned close!
Don't try just accessing a byte though, even though there are instructions for it it'll trap. I can't remember if working byte addressing got added in the 68010 or 68020.
You could definitely access bytes? You couldn't do word or long accesses on odd addresses however. The 68000 doesn't have a pin for bit 0 of the address. (Byte accesses presumably fetch the word of interest and discard the 8 unwanted bits.)
It was glorious! It was the most fun I've ever had with assembly language (though the fact that hand-written assembly still mattered back then probably had a lot to do with that, too).
Yes, and that "Only 24 bits of the 32 bit word are used" thing came back to bite Apple hard when the "32 bits for real" 68020 came out and the funny tricks they were pulling with the top 8 bits confused the processor.
The register partitioning (eight "data" registers d0-d7 and eight "address" registers a0-a7, with a7 being the stack pointer) was probably the biggest wart.
I like to see it the other way around: the partitioning was a smart way of doubling the number of registers that could be expressed in a fixed-length 16-bit instruction word.
There are many computational instructions that don't make much sense on addresses, especially if you have rich address modes to begin with. And if you'd need to, there was the "movea" instruction for copying between the register files.
Indirect addressing, including memory indirect addressing, which takes a base address (register), an index (register), a size (immediate), two offsets (immediate), and an address stored in memory somewhere.
You could, in one single instruction,
struct B {
int x, y, z;
};
struct A {
int a, b, c;
struct B *ptr;
};
void func(struct A *array, int i) {
array[i].ptr->z = 3;
}
and IIRC there was also the "LEA" instruction ("Load Effective Address") which stored the computed memory address instead of fetching/storing to that address. And I believe some compilers would (ab)use that to do math as well (though this was complicated by the aX/dX register split)
The addressing modes do exist on 68020+ (https://www.nxp.com/files-static/archives/doc/ref_manual/M68... section 2.2), but I don't think any compiler will generate them (even with -mcpu=68020) as I think they're not actually faster than doing it the normal way (even if that costs a register), maybe slower, but I'd have to check the cycle counts.
EDIT: Yeah, so if I'm not misreading MC68020UM the memory indirect mode is slower
Ya 68k assembly was the simplest assembly language I ever used, far simpler than either x86 or z80. I embedded it in asm {} blocks in C++ back in the Mac LC days for innermost loops, and the great thing was that the compiler would even let you reference variables like "register int x;" declared outside the block, instead of having to keep track of r0-r31 (if I remember correctly). One of the only problems is that it's a very RISC-like instruction set, so is missing much of the high/low byte handling of x86, as well as fancier combined MOV/math/loop instructions with side effects that could be taken advantage of for games. Which in practice meant that the same code ran perhaps 2-4 times slower on Mac than PC.
Unfortunately Apple crippled the memory bus on most of its products so as not to compete with its more expensive models like the Mac IIfx. So by the time the 486 DX4 came out, there was simply nothing comparable on the Mac side, and then the Pentium was the final nail in the coffin and Apple had to transition to PowerPC. But modern processors are so microcode-heavy, with advanced pipelining, branch prediction and instruction interleaving, that they can't be programmed by humans anymore, at least not anywhere near the level of optimizing compilers. GPUs also killed the golden age of innermost loop optimization in the late 1990s.
If I could have one wish, it would be to revert all processor "progress" since the 68040 or possibly PowerPC 601 around 1995, and make something like RISC-V with under 1 million transistors, little or no cache, and 68k assembly or simpler. Then arrange them on a 2D grid. The 50 billion transistors of an Nvidia RTX 4080 would make for 50,000 cores, and even if we lose 1-2 orders of magnitude for interconnect, that's still 500 cores. I'd put at least a 16 GB memory directly above that, connected by vias, with a content-addressable caching scheme for in-memory processing. A scalable chip like that would give us 3 orders of magnitude more performance than we have today, and pull away at perhaps 100x improvement each decade. Maybe Apple's M1 will eventually do that stuff, but right now it's too mired in domain-specific hardware for video and AI. I view that with the same skepticism as DSLs and mourn the loss of symmetric multiprocessing. But I digress!
I've worked on .. several? high core count 2d array machines, and they tend not to be to useful for general code because of limited memory bandwidth. some pipelines and embarrassingly parallel things work really well. generally machines with higher dimensional interconnect tend to be more useful
I agree we shouldn't have completely abandoned these machines in the 90s. the massive resurgence we see of vector and simd today proves that there was substantial value - and maybe the software story would be a lot better if we hadn't have taken a 20 year piss break.
It's true, I can't help but imagine what we could do if we just down-clocked CPU in at the same maximum speed as the bus&RAM and went stupid-wide instead of stupid-complicated. Forget about smartly filling our L1 caches, super clever branch prediction, NUMA, very wide register sets, etc. and just go "embarassingly parallel" as you say, and with the right programming paradigm perhaps the tradeoffs would work out in either $$ or MIPS.
Though of course I know it's been done and either failed technically, or failed in the market, several times. E.g. fairly recently the Parallela Epiphany stuff (https://parallella.org/2016/10/05/epiphany-v-a-1024-core-64-...) which sounded super-gee-whiz-bang-neat but went nowhere.
But maybe the application domains and compilers just weren't there for it yet.
I like what e.g. Parallax has done with their Propeller 2, in the microcontroller domain. 8 cores round-robining on a shared memory, but with their own smaller localized workspace RAM, and a pile of I/O. No need for interrupts to manage concurrency, just assign a core to it. https://www.parallax.com/propeller-2/
Embarrassingly parallel problems are relatively rare. Even GPU cores are quite big and they’re explicitly dedicated to mostly embarrassing parallelism.
The complexity is sadly mostly inherent in the problems being solved.
one place where more software/language/architecture work is really needed to make this work well is architectures which aren't cache coherent (either by simply not having any caches like the MTA or the CM, by having software controlled caches, by strongly delineating local and global memory, or some other approach).
I've been sitting here in my spare time writing / yak shaving an adaptive radix tree implementation I wrote... to try to keep various things in L1 cache and, well, y'know, it'd be nice in a way to just sometimes... have this all be explicit and not automatic? To be able to put the machine into a mode where I could have the various levels of memory declared by the hardware have separate manual methods for accessing each, e.g. to be able to load L1 myself, etc. The CPU & board could tell me the size and cost of each level, and I could write a software model to move things around myself. Fantasy.
There is a whole class of communication optimal algorithms. And cache oblivious ones. You really shouldn’t have to do what you’re doing, and progress is being made.
I know, right? Just think about what could have been if IBM had selected the 68K. An assembly language that was actually pretty pleasant to program in. Motorola would probably be the Intel of now. Intel would maybe still be making memory (so kind of like Micron and probably similar in size).
I keep reading here great things about the 68k. What made Motorola diverge from it and invest in a whole new arch (88k) rather than keep pushing the 68k line? Intel succeeded in evolving x86 despite it being an originally subpar design, surely the 68k could have been taken further more easily?
At some point (maybe the 68040?), the 68K line started to decline in popularity and there was a significant contingent of the industry that was convinced that RISC was the future (not that they were really wrong). The big Unix system companies were mostly doing their own RISC designs and Motorola figured that they had a significant market in the second-tier players like Data General that weren't going to do their own RISC designs.
Intel did try to do RISC unsuccessfully with the i860--which also had some sort of VLIW mode, which makes their later Itanium even harder to understand.
Lower sales. Bad management. And there was a consensus at that point that CISC was a dead-end and RISC was the future. Also, they did in fact take the 68k further (ColdFire) but too late, long after they had pushed their serious customers to PowerPC.
Intel was making enough coin from x86 that they were reluctant to EOL it in favour of something RISC. Not that they didn't try. Multiple times (Itanium being the worst, though much later). But each time their replacement failed to ignite, and Intel pulled back from the brink and they pushed something that was a noticeable incremental improvement while keeping backward compatibility.
And with the Pentium & the ISAs that followed they just seemed to pull a rabbit from a hat. They made the x86 CISC architecture scale in a way that pundits at least? didn't seem to think was possible.
Motorola didn't invest in time in doing for 68k what Intel did for x86 with the Pentium. And they screwed over their customers as a result. They basically told everyone (Apple, NeXT, various workstation makers, etc.) to go to 88k. 88k was an architectural failure. So then they did PowerPC along with IBM and others. And people who used 68k previously either went PowerPC (Apple) or rolled their own RISC (Sun with SPARC, HP with PA-RISC, etc.) or just left the market entirely (Apple, Commodore).
ColdFire is roughly to the 68k what Pentium II or so was to the x86 line. It's actually quite nice. They dropped a couple things from 68k but it's about 90% compatible, and can do a very effective software emulation to make itself 100%. But it got pushed basically only as a microcontroller or specialist (routers, ethernet switches, etc.) architecture. You can still buy them from NXP I believe.
These days I don't like big-endian. And the separate address vs data registers seems weird now. But the 68k instruction set was overally very nice. I do imagine sometimes an alternate timeline where Motorola had rolled ColdFire out sooner as an MPU line for consumer stuff and Apple, etc. had used that instead of going PowerPC. I wonder what a 64-bit 68k would have looked like.
IMHO Apple wasted a whole pile of engineering years getting MacOS classic to port over natively to PowerPC. It was extremely unstable and large parts were emulated 68k code for years. It might have saved them some unprofitable years, who knows? They seem to have finally learned the lesson and they own their own CPU now.
> And with the Pentium & the ISAs that followed they just seemed to pull a rabbit from a hat. They made the x86 CISC architecture scale in a way that pundits at least? didn't seem to think was possible.
The Pentium was not great, not terrible. IIRC 2 ways superscalar in-order, quite faster than the 486 (also because of caches, better memory, faster and wider FSB, way better latencies for tons of instructions) but it would not have been enough if Intel had tried to just make it evolve slowly.
Of course at the time and taking price and competition into account, it was quite good to make faster PCs. But by itself it only showed a limited capability for scaling x86.
The Pentium Pro was the uarch that showed that scaling was possible. Even if they have been deeply refined across the years and generations (putting NetBurst appart, of course), most of the technics it introduced in the x86 world are still a foundation of how the current generation x86 cores work. The rabbit that came out of the hat was the result of quite a number of years of work, most of it parallel to the P5 dev. The Pentium II consolidated that with better support for consumer software of the time (with still copious amount of 16-bit code), and, logically, marketing for consumer hardware (with manufacturing progress and tricks allowing a price not too high).
> The Pentium was not great, not terrible. IIRC 2 ways superscalar in-order,
Eh, I don't agree. Look at the other superscalar microprocessors available around the same time:
* POWER (1990)
* Alpha 21064 (1992)
* PA-RISC 7100 (1992)
* Pentium (1993)
* POWER2 (1993)
* MIPS R8000 (1994)
* PA-RISC 7200 (1995)
* UltraSparc (1995)
* Alpha 21164 (1995)
So, first of all, all of these are in-order processors. Out of order execution didn't come until later ('95 for PA-8000, '96 for R10k and Pentium Pro and '98 for Alpha 21264 and Power3).
Second, all of the RISC superscalar processors prior to the Pentium are also (technically) dual issue.
But Pentium did something unique: It can issue two integer instructions in the same cycle. Before that, all the others could issue only one instruction of a given type (load/store, int, and fp) per cycle. In other words, while they may be "dual issue", your instruction stream needs a mix of those types to get any benefit from multi-issue on those early implementations.
In terms of having 2x execution units of the same type: POWER2 got there later in 1993, but was not a single-chip processor, followed by R8000 (also multi-chip), PA-7200 and 21164.
That's why Pentium had pretty good integer benchmarks, even while it was getting crushed on floating point compared to RISC.
> PA-RISC, etc.) or just left the market entirely (Apple, Commodore).
Worth noting that had Commodore's astonishingly out of touch and schizophrenic corporate management not driven the company into the grave, the Amiga engineering team had already settled on PA-RISC as their next generation architecture as well, and I believe even had reached prototype stage on the vapors of cash renained in their final months of existence.
Commodore's management sucked, but it doesn't matter. The mid-90s made it pretty much impossible for anything that wasn't a commodity PC clone to survive. Apple only barely made it, and really only rescued themselves by making brightly coloured plastic wrappings around what was basically a typical commodity PC but with a different CPU/OS (PowerPC with IDE drives and PCI bus).
The 90s was the era of Dell JIT delivery and grey-box clones. The margins fell out of the whole market. There was no room for the likes of an Atari or Commodore.
Apple only turned things around for themselves in the next millennium by becoming a luxury brand maker of consumer appliances, and "computers" as we know them have become a much smaller market than handheld devices.
Maybe the "Amiga" brand could have continued as a high end graphics card line for PCs. (But it's not like there was any special sauce left in Commodore eng talent that could have made anything competitive). But Commodore as a maker of home computers or workstations? Nothing could have saved them.
Reluctantly agree. The total product is what matters in the marketplace, and the silicon itself, and arguably even the OS, together are relatively minor factors.
Sometimes I wonder if there was a point in time - where real history switches to a fantasy history - in which a non-pc clone paradigm ends up winning that war. If so what was the earliest point this could have happened, and would it even matter since market forces would ultimately pull any alternate success in the direction of an informally standards-federated clone paradigm anyway.
> Intel was making enough coin from x86 that they were reluctant to EOL it in favour of something RISC. Not that they didn't try. Multiple times (Itanium being the worst, though much later).
It seems as if VLIW with a sufficiently smart compiler to handle the instruction packing was the "fetch" Intel kept trying to make happen, but it wasn't going to happen (people kept stumbling on the "sufficiently smart compiler" bit). First with the iAPX 432, then the i860, then Itanium.
Bill Gates confirmed this in an interview published in PC Magazine in 1997 [1]: ..."Once we convinced IBM to go 16-bit (and we looked at 68000 which unfortunately wasn't debugged at the time so decided to go 8086)"...
All the bus/memory timings are the same with this guy's hack. So it's not a big surprise that 10 print "hello world!" :print "!" : goto 10 doesn't have any perceived performance difference. Maybe if you made a purely arithmetic benchmark in assembly that could be done all within a few registers, like Fibonacci, you might see some difference.
Not sure about the authors performance claims. He doesn't indicate how fast his emulated 68000 is in terms of MIPS or equivalent MHz. It's also constrained by the 8bit bus which might have been wider if IBM had chosen that chip. Certainly would have been wider by the 286 equivalent generation.
IBM also had experience of the 8085 and 8086 from their System/23 and Displaywriter systems which meant there was previous experience with Intel microprocessors in IBM at that time. I also read somewhere (but do not have a source to hand) that IBM had a significant investment in Intel at that point in time.
Take an Atari ST and you can see what a m68k PC could have been. Its operating system GEMDOS was a derivative of CP/M with comparable features of MS_DOS. The syscall even use the same numbers (trap #1 calls to GEMDOS map 1:1 on int 21H MS-DOS calls).
This said, several hardware PC-emulators on the Atari did exactly the thing that article describes. PC-Speed added a NEC V30 that was soldered on the 68000 and could takeover the bus and the emulation only consisted on simulating the peripherals. It worked like a charm and thanks to the generous memory of the ST could even do some things better than real PC's (for example the 640K limit was in reality a 736K limit). Later versions used 286 and even 386sx cpu's.
GEMDOS was written from scratch (by Digital Research) and doesn't share any code or data structures with CP/M. Many of the BIOS and system calls were the same, but GEMDOS had recursive directories, etc.
Hah, funny, I just posted effectively the same comment elsewhere in this thread.
Though as sibling comment correctly points out (and he'd know more than most, BTW) GEMDOS is more a CP/M-alike than a CP/M itself. There's really no or very little code shared in common with CP/M68k (both are under GPL now so you can go and look). I think the only thing shared between the two is the program loader source, and I might even be wrong about that.
But yes I feel like this machine in this article should boot to a COMMAND.COM running on GEMDOS. Or at least CP/M68k. The source is available to make that happen fairly easily.
I always thought that if the same amount of engineering and investment that went into overcoming the 8088 architecture instead was redirected into a more sane CPU architecture, development of the PC industry would have been accelerated by about a decade.
I'm talking products like QEMM, Sidekick (and the whole "terminate and stay resident" industry), expanded vs. extended memory, and other massive engineering efforts by major software (Lotus, Ventura Publisher, etc.). Time spent overcoming the limitations of the 640K barrier, segmented memory, and similar design challenges could have been spent in more productive ways, as could be seen in the development of other ecosystems on a comparative shoestring budget.
Granted I was an Amiga aficionado back in the late '80s/early 90's, so I'm comparing things like the ATI VGA Wonder (1988) to the Video Toaster (1990), or early efforts at GUIs (like GEM) to the multitasking OS of Amiga. But still, I think the point stands.
This was a simple and fun read while waiting for my coffee to be done.
I also wonder how the world would look if IBM partnered with Apple rather than Microsoft.
On an 8 bit bus the 68k is almost useless. I am currently working on a project that involves that and looking at the logic analyzer trace is just tear-inducing. 68k has a terrible IPC to start with, and sticking it on a narrow bus cuts it by more than half. You’d be lucky to squeeze 0.8MIPS out of a 16MHz 68k on a 8 wide bus. Mainly the cause is the fact that the smallest possible instruction is 2 bytes. And it will take at least 4 cycles to fetch it (68k will execute a compete nCS cycle PER BYTE - no bursts to be found here).
> It could also have been the case that Microsoft did not have an operating system or BASIC ported to the Motorola 68000 architecture.
That would be a big thing. 8088 assembly language is source-code compatible with 8080 assembly language. I believe IBM was eyeing the ability to run CP/M and derivatives like CP/M-86. IBM/MS DOS is basically a CP/M-like, derived from this:
"[86-DOS's] application programming interface was very similar to that of CP/M. The system was licensed and then purchased by Microsoft and developed further as MS-DOS and PC DOS."
This is an awesome post, but I don't think it proves that it wouldn't have mattered. The biggest win with 68k over 8088 is the flat address space and the innovations that would have been easier with a larger address space. The PC was super constrained from a software perspective because of segment registers and the memory model.
98 comments
[ 2.4 ms ] story [ 144 ms ] threadThe late 70s / early 80s incarnation of Microsoft was happy to port their software to just about anything, so long as there was a customer willing to pay for it. If IBM had asked Microsoft for a 68K OS instead of an x86 one, Bill Gates would have found a way to provide. He bought PC/MS-DOS from another company, he probably could have found someone selling a 68K OS instead. Or Tim Paterson surely could have ported it to 68K if asked.
I think choosing the 8088 over 68K was all about hardware costs, not software-both the cost of the CPU, and the cost of compatible peripheral chips.
Maybe even demand some optional record-oriented support in the filesystem (e.g RECFM=F80). That would have been less alien to Microsoft than you’d think, because Microsoft BASIC always supported record-based file access.
particularly this, i think, and also availability.
https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compati...
[1] https://en.wikipedia.org/wiki/IBM_System_9000
A detailed description (with pictures) can be seen on page 278 and following ones of BYTE Magazine, February 1984 issue. The computer was branded as "IBM Instruments"
https://archive.org/details/byte-magazine-1984-02/mode/2up?v...
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.
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.
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.
It would be interesting to port TOS (or more likely EmuTOS) to this 68k IBM PC and kind of go full circle.
(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.)
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
From: https://news.ycombinator.com/item?id=34762508
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)
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.
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.
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.
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.
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.
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.
[0] https://en.wikipedia.org/wiki/IBM_Displaywriter_System
Not as nice as a PDP-11 processor, but damned close!
I also wouldn't hold my breath while waiting for the 68000 to do anything... all the instructions are enormous, and they take ages to execute.
Edit: well, 24-bit physically, but flat linear address space and an instruction set that permitted 32-bit addressing.
There are many computational instructions that don't make much sense on addresses, especially if you have rich address modes to begin with. And if you'd need to, there was the "movea" instruction for copying between the register files.
You could, in one single instruction,
Unless I am remembering how it works incorrectly.This is a little closer: https://godbolt.org/z/5K4MEYe31
and IIRC there was also the "LEA" instruction ("Load Effective Address") which stored the computed memory address instead of fetching/storing to that address. And I believe some compilers would (ab)use that to do math as well (though this was complicated by the aX/dX register split)
EDIT: Yeah, so if I'm not misreading MC68020UM the memory indirect mode is slower
vs.Unfortunately Apple crippled the memory bus on most of its products so as not to compete with its more expensive models like the Mac IIfx. So by the time the 486 DX4 came out, there was simply nothing comparable on the Mac side, and then the Pentium was the final nail in the coffin and Apple had to transition to PowerPC. But modern processors are so microcode-heavy, with advanced pipelining, branch prediction and instruction interleaving, that they can't be programmed by humans anymore, at least not anywhere near the level of optimizing compilers. GPUs also killed the golden age of innermost loop optimization in the late 1990s.
If I could have one wish, it would be to revert all processor "progress" since the 68040 or possibly PowerPC 601 around 1995, and make something like RISC-V with under 1 million transistors, little or no cache, and 68k assembly or simpler. Then arrange them on a 2D grid. The 50 billion transistors of an Nvidia RTX 4080 would make for 50,000 cores, and even if we lose 1-2 orders of magnitude for interconnect, that's still 500 cores. I'd put at least a 16 GB memory directly above that, connected by vias, with a content-addressable caching scheme for in-memory processing. A scalable chip like that would give us 3 orders of magnitude more performance than we have today, and pull away at perhaps 100x improvement each decade. Maybe Apple's M1 will eventually do that stuff, but right now it's too mired in domain-specific hardware for video and AI. I view that with the same skepticism as DSLs and mourn the loss of symmetric multiprocessing. But I digress!
I agree we shouldn't have completely abandoned these machines in the 90s. the massive resurgence we see of vector and simd today proves that there was substantial value - and maybe the software story would be a lot better if we hadn't have taken a 20 year piss break.
Though of course I know it's been done and either failed technically, or failed in the market, several times. E.g. fairly recently the Parallela Epiphany stuff (https://parallella.org/2016/10/05/epiphany-v-a-1024-core-64-...) which sounded super-gee-whiz-bang-neat but went nowhere.
But maybe the application domains and compilers just weren't there for it yet.
I like what e.g. Parallax has done with their Propeller 2, in the microcontroller domain. 8 cores round-robining on a shared memory, but with their own smaller localized workspace RAM, and a pile of I/O. No need for interrupts to manage concurrency, just assign a core to it. https://www.parallax.com/propeller-2/
The complexity is sadly mostly inherent in the problems being solved.
Intel did try to do RISC unsuccessfully with the i860--which also had some sort of VLIW mode, which makes their later Itanium even harder to understand.
Intel was making enough coin from x86 that they were reluctant to EOL it in favour of something RISC. Not that they didn't try. Multiple times (Itanium being the worst, though much later). But each time their replacement failed to ignite, and Intel pulled back from the brink and they pushed something that was a noticeable incremental improvement while keeping backward compatibility.
And with the Pentium & the ISAs that followed they just seemed to pull a rabbit from a hat. They made the x86 CISC architecture scale in a way that pundits at least? didn't seem to think was possible.
Motorola didn't invest in time in doing for 68k what Intel did for x86 with the Pentium. And they screwed over their customers as a result. They basically told everyone (Apple, NeXT, various workstation makers, etc.) to go to 88k. 88k was an architectural failure. So then they did PowerPC along with IBM and others. And people who used 68k previously either went PowerPC (Apple) or rolled their own RISC (Sun with SPARC, HP with PA-RISC, etc.) or just left the market entirely (Apple, Commodore).
ColdFire is roughly to the 68k what Pentium II or so was to the x86 line. It's actually quite nice. They dropped a couple things from 68k but it's about 90% compatible, and can do a very effective software emulation to make itself 100%. But it got pushed basically only as a microcontroller or specialist (routers, ethernet switches, etc.) architecture. You can still buy them from NXP I believe.
These days I don't like big-endian. And the separate address vs data registers seems weird now. But the 68k instruction set was overally very nice. I do imagine sometimes an alternate timeline where Motorola had rolled ColdFire out sooner as an MPU line for consumer stuff and Apple, etc. had used that instead of going PowerPC. I wonder what a 64-bit 68k would have looked like.
IMHO Apple wasted a whole pile of engineering years getting MacOS classic to port over natively to PowerPC. It was extremely unstable and large parts were emulated 68k code for years. It might have saved them some unprofitable years, who knows? They seem to have finally learned the lesson and they own their own CPU now.
The Pentium was not great, not terrible. IIRC 2 ways superscalar in-order, quite faster than the 486 (also because of caches, better memory, faster and wider FSB, way better latencies for tons of instructions) but it would not have been enough if Intel had tried to just make it evolve slowly.
Of course at the time and taking price and competition into account, it was quite good to make faster PCs. But by itself it only showed a limited capability for scaling x86.
The Pentium Pro was the uarch that showed that scaling was possible. Even if they have been deeply refined across the years and generations (putting NetBurst appart, of course), most of the technics it introduced in the x86 world are still a foundation of how the current generation x86 cores work. The rabbit that came out of the hat was the result of quite a number of years of work, most of it parallel to the P5 dev. The Pentium II consolidated that with better support for consumer software of the time (with still copious amount of 16-bit code), and, logically, marketing for consumer hardware (with manufacturing progress and tricks allowing a price not too high).
Eh, I don't agree. Look at the other superscalar microprocessors available around the same time:
* POWER (1990)
* Alpha 21064 (1992)
* PA-RISC 7100 (1992)
* Pentium (1993)
* POWER2 (1993)
* MIPS R8000 (1994)
* PA-RISC 7200 (1995)
* UltraSparc (1995)
* Alpha 21164 (1995)
So, first of all, all of these are in-order processors. Out of order execution didn't come until later ('95 for PA-8000, '96 for R10k and Pentium Pro and '98 for Alpha 21264 and Power3).
Second, all of the RISC superscalar processors prior to the Pentium are also (technically) dual issue.
But Pentium did something unique: It can issue two integer instructions in the same cycle. Before that, all the others could issue only one instruction of a given type (load/store, int, and fp) per cycle. In other words, while they may be "dual issue", your instruction stream needs a mix of those types to get any benefit from multi-issue on those early implementations.
In terms of having 2x execution units of the same type: POWER2 got there later in 1993, but was not a single-chip processor, followed by R8000 (also multi-chip), PA-7200 and 21164.
That's why Pentium had pretty good integer benchmarks, even while it was getting crushed on floating point compared to RISC.
Worth noting that had Commodore's astonishingly out of touch and schizophrenic corporate management not driven the company into the grave, the Amiga engineering team had already settled on PA-RISC as their next generation architecture as well, and I believe even had reached prototype stage on the vapors of cash renained in their final months of existence.
The 90s was the era of Dell JIT delivery and grey-box clones. The margins fell out of the whole market. There was no room for the likes of an Atari or Commodore.
Apple only turned things around for themselves in the next millennium by becoming a luxury brand maker of consumer appliances, and "computers" as we know them have become a much smaller market than handheld devices.
Maybe the "Amiga" brand could have continued as a high end graphics card line for PCs. (But it's not like there was any special sauce left in Commodore eng talent that could have made anything competitive). But Commodore as a maker of home computers or workstations? Nothing could have saved them.
Sometimes I wonder if there was a point in time - where real history switches to a fantasy history - in which a non-pc clone paradigm ends up winning that war. If so what was the earliest point this could have happened, and would it even matter since market forces would ultimately pull any alternate success in the direction of an informally standards-federated clone paradigm anyway.
It seems as if VLIW with a sufficiently smart compiler to handle the instruction packing was the "fetch" Intel kept trying to make happen, but it wasn't going to happen (people kept stumbling on the "sufficiently smart compiler" bit). First with the iAPX 432, then the i860, then Itanium.
[1] https://web.archive.org/web/20010823113747/https://www.pcmag...
The first answer on this forum post has what is probably the correct explanation for why the 8088 was chosen:
It was available, had a second source, and was not owned by a competitor.
https://retrocomputing.stackexchange.com/questions/16912/did...
Although ease-of-translation from 8080-based CP/M code was a benefit of choosing the 8086, this was just a nice-to-have, not a deciding factor.
Here an (emulated) MC68000 is pressed into serving an 8bit bus.
The 68k (using its native 16bit bus) is faster (even if not by much) than a 8086.
This said, several hardware PC-emulators on the Atari did exactly the thing that article describes. PC-Speed added a NEC V30 that was soldered on the 68000 and could takeover the bus and the emulation only consisted on simulating the peripherals. It worked like a charm and thanks to the generous memory of the ST could even do some things better than real PC's (for example the 640K limit was in reality a 736K limit). Later versions used 286 and even 386sx cpu's.
Though as sibling comment correctly points out (and he'd know more than most, BTW) GEMDOS is more a CP/M-alike than a CP/M itself. There's really no or very little code shared in common with CP/M68k (both are under GPL now so you can go and look). I think the only thing shared between the two is the program loader source, and I might even be wrong about that.
But yes I feel like this machine in this article should boot to a COMMAND.COM running on GEMDOS. Or at least CP/M68k. The source is available to make that happen fairly easily.
I'm talking products like QEMM, Sidekick (and the whole "terminate and stay resident" industry), expanded vs. extended memory, and other massive engineering efforts by major software (Lotus, Ventura Publisher, etc.). Time spent overcoming the limitations of the 640K barrier, segmented memory, and similar design challenges could have been spent in more productive ways, as could be seen in the development of other ecosystems on a comparative shoestring budget.
Granted I was an Amiga aficionado back in the late '80s/early 90's, so I'm comparing things like the ATI VGA Wonder (1988) to the Video Toaster (1990), or early efforts at GUIs (like GEM) to the multitasking OS of Amiga. But still, I think the point stands.
This was a simple and fun read while waiting for my coffee to be done. I also wonder how the world would look if IBM partnered with Apple rather than Microsoft.
Possibly underwhelming, if Taligent was any indication.
https://en.wikipedia.org/wiki/Taligent
https://emutos.sourceforge.io/
That would be a big thing. 8088 assembly language is source-code compatible with 8080 assembly language. I believe IBM was eyeing the ability to run CP/M and derivatives like CP/M-86. IBM/MS DOS is basically a CP/M-like, derived from this:
https://en.wikipedia.org/wiki/86-DOS
"[86-DOS's] application programming interface was very similar to that of CP/M. The system was licensed and then purchased by Microsoft and developed further as MS-DOS and PC DOS."