20

These are all legendary 16/32-bit machines that were introduced in 1984 or later that are running the 68000:

  • Apple Macintosh
  • Atari ST
  • Commodore Amiga
  • Sharp X68000
  • Sinclair QL (Well, maybe we can excuse that one; it actually used a 68008 with 8-bit bus.)

But the 68010 was already available, in every single case: it launched in 1982. Why not use the new “fully debugged,” slightly faster, Popek-and-Goldberg compliant version of the architecture, instead of one which couldn’t even fully recover from a bus fault?

I can make some guesses. Price? Availability? Compatibility fears? They didn't know it existed?

4
  • 7
    Correction: The Sinclair QL used a Motorola 68008, which was a member of the 68k series with an 8-bit external data bus. Jun 24 at 2:45
  • @user3570736 that’s why I allowed it to be excused Jun 24 at 19:38
  • another machine which used the 68008 was the swedish firm Luxor in their ABC 1600 computer. A very expensive kit with only an 68008 while SUN already was using the 68010 in it's 2 machine. Jun 28 at 18:31
  • But the QL shouldn't be in the list at all. It's not a 16-bit memory machine so it's a zero candidate for a 68010. Adding an 'excused' note doesn't help that...should be deleted from the list.
    – TonyM
    Jun 28 at 22:17

6 Answers 6

30

Available isn't the same as in volume production, where big enough computer manufacturers could negotiate a better price in higher volumes. Both the Macintosh and the Amiga projects started out with aggressively low price and cost targets (although neither came close to meeting those early targets), and only choose the 68k because the price could be negotiated low in consumer volumes.

Also, the Macintosh 68k design was started years before the Amiga's, and the early Mac prototypes didn't generate a bus fault or have an OS that required recovering from one. So no reason to pay more for the 68010 features, which were put in for workstation and minicomputer manufacturers who were working with significantly (maybe 10X) higher price/cost targets. So the '010 could be priced high for those customers as a form of market segmentation (taught in B school as a strategy to raise profits). Thus forced to be uninteresting to the high volume consumer computer vendors.

3
  • I think the first price rumored for the Amiga was $1000 with 128KB, and it shipped for $1295 with 256KB - so way closer to the target price than the first Macintosh with its $2495 retail price.
    – Brian H
    Jun 25 at 0:36
  • The original price targets for both the Mac and the Amiga at project start were below half the actual introductory retail prices.
    – hotpaw2
    Jun 25 at 2:46
  • I've seen old rumors (1983-84) about a $999 Mac. I haven't ever seen rumors of a $649 Amiga from 1984.
    – Brian H
    Jun 25 at 13:29
23

While "why hasn't X been used" questions are inherently weak, one may still consider some points:

  • While introduced in 1982 the 68010 wasn't available before mid 1983. Too late for any of those machines.
  • The 68010 was not intended as a replacement for the 68000 (*1), but to appeal to a high(er)-end market (*2).
  • Thus the price for the 68010 was considerably higher than the 68000.
  • It didn't offer any feature these machines needed:
    • Virtual memory support was not planned.
    • Moreso, virtual memory support is useless on floppy based systems.
    • Recovering from a bus fault is not necessary without virtual memory requirement.
    • A tight supervisor mode (Popek-and-Goldberg) is of no advantage without address protection like that provided with an MMU (*3.
  • Making any of these features useful would require additional hardware, most notably a 68451 MMU with a price tag higher than the 68000.
    • Not to mention that a single 68451 is very limited, some systems used up to TWELVE of them for a single 68010.

Last, but for sure not least:

  • The speed-up was rather meagre. 10% is way below noticeable for anything but extreme tasks.

Bottom line: The 68010 had no advantage for these systems, but the quite relevant disadvantage of a higher price. Plus not being available at the time the Mac or Amiga was designed (*4).


*1 - Though it was, hardware-wise, a pin-compatible drop in for the 68000.

*2 - The 1985 data sheet calls them (010/012) "16-/32-BIT VIRTUAL MEMORY MICROPROCESSORS".

*3 - That is beside the fact that the requirements are for full virtualization - that is the ability to run several arbitrary OS in parallel - not just virtual memory. Something even farther out of scope to any of the machines in question and at the time.

*4 - For the QL, even the 68000 was out of scope as that machine was all about price and the basic 68000 was considered to expensive, thus the 68008 was chosen.

Fun fact: the 68451 can be also made to work with the 8 bit data bus of the 68008 as shown in figure 4-2 of the 68541 datasheet:

enter image description here

7
  • I am not familiar with the 68451, but its "limit" of 96 segments should be fine, assuming there are no major howlers in its design. Treat it as merely a TLB and have the kernel walk page tables and update mappings when there's a page fault. This is how paging is done on MIPS and (some?) SPARC. TLBs tend to be quite small and 96 appears to be fairly generous for the time.
    – pndc
    Jun 24 at 8:15
  • 1
    @pndc Not sure where you got the 96 from, my 1981 data book and 1983 data sheet each say 32. Also, the 68451 isn't much more than a TLB, albeit a complicated one, as it has to support 16 function states with dedicated address spaces for each. But most important, the capabilities of the MMU are only a secondary point. Overarching here is that the function of the MMU was not needed for the systems in question. No matter if elegant or not, fast or not or whatsoever.
    – Raffzahn
    Jun 24 at 9:16
  • 1
    Wikipedia claims "It supported the mapping of up to 96 memory segments". Now I've pulled the datasheet, it seems that Wikipedia is wrong and you are right.
    – pndc
    Jun 24 at 17:08
  • @pndc Ups, linked to that but didn't note the number. Corrected the Wiki entry (and added the data sheet). Thanks.
    – Raffzahn
    Jun 24 at 20:30
  • 1
    @BobJarvis-СлаваУкраїні So? What she describes are Overlays. Overlays do not need virtual memory nor are they related to virtual memory.
    – Raffzahn
    Jun 25 at 23:35
12

AmigaOS never was intended to use virtual memory, basically it can only work when all processes are in the same memory space. Hence the features of 68010 you've listed were completely useless to Amiga. The only real gain of 68010 was somewhat faster tight loop execution since it has opcode cache for 3 words. Probably this boost did not worth increased price.

1
  • 5
    an interesting feature is VBR relocation that allows the use of software debuggers like HRTMon. But not much more I'm afraid. Plus the fact that upgrading increases speed and sometimes breaks games because of that. Jun 24 at 7:44
9

Having worked in the R&D section on product development, I can tell you that design of products is not instant. Sometimes, it can take a couple of years. If a chip was released to a manufacturer under an NDA, a few years prior to its launch, it would take a manufacturer some time to develop the product, set up the QA tests, production lines, create advertisements, documentation etc. None of this stuff is instant.

Once this has been set up, you can't just change chips. They may be electrically or mechanically different or have less instructions.

I remember a case where the newer systems overheated because the we got a new "compatible" substitute chip. Pinouts and size were compatible but the manufacturer had changed the position of the cooling hole for the battery. The "quick" fix was simple - just drill another hole where the new cooling hole was. Working out whether it would affect any other circuit on this multi-layer board took a few days. It was another 2 months before the new PCB went into production.

8
  • 2
    The 68010 is a true drop in replacement for the 68000. Except for one changed instruction in user mode, which should not matter in any of thenamed machines . But yeah, in a somewhat professional company it would have been an uphill battle to change the CPU at a later stage.
    – Raffzahn
    Jun 24 at 9:22
  • 5
    @Raffzahn - the process to prove that it is a true drop in replacement is probably not easy. Until you have access to volume manufacturing you never really know if everything will just work, particularly if you are near some cliff on your design.
    – Jon Custer
    Jun 24 at 13:44
  • 5
    @Raffzahn - I have been bit, though. Chip maker planned that the new chip would be produced on their next generation process. Fab was not ready in time, they had to use the current process to start, so the chips were more expensive and higher power (thus ran hotter) than originally spec'd out. Ooops...
    – Jon Custer
    Jun 24 at 14:18
  • 5
    @Raffzahn: The 68010 substantially reworks trap handling logic to accommodate mid-instruction bus faults. According to the sources I read at the time, properly handling all of the scenarios where a bus fault could occur was a major engineering effort, and I don't think it's fair to call it a "bug fix". The reason the chip wasn't a marketing success is that it offers little advantage over the 68000 except in the niche case of workstations which needed virtual memory, but for which a 68000 would otherwise offer adequate performance.
    – supercat
    Jun 24 at 17:38
  • 3
    @Raffzahn: The sources at the time talked about the chip's failure to be deliverable when expected because of difficulty handling all of the relevant situations where instructions could get interrupted at awkward times. System-level code compatibility with the 68000 would have been a non-issue because the only 68000 systems that were using paged virtual memory had to use an entirely separate processor to handle page faults, and a 68010 obviously wasn't going to be compatible with that.
    – supercat
    Jun 24 at 19:38
9

The main thing which was absent in the 68000 but added in the 68010 was the ability to have an instruction execute until it attempts to access a protected region of memory, trigger a page fault, have a page-fault handler swap in the memory as required, and then have execution resume in the middle of the original instruction. Such scenarios would not have been generally supportable in a single-CPU 68000-based system(*) because some of the 68000's instructions may perform multiple memory operations in ways that are not interruptable. Suppose, for example. that A0 is $20002, and code performs ADD.L R0,(--@A0) when the page at $1FFFE is fully read/writable, but the page at address $20000 is a copy-and-write page which is marked read-only. If an attempt is made to perform the instruction in such circumstances on the 68000, it would perform 16-bit reads from addresses $1FFFE and $20000, then write $1FFFE, and then trigger a page fault while trying to write $20000.

Once that occurred, it would be necessary for the operating system to somehow copy the data from the page to a new fresh page, mark the new page as read-write, and map it to address $20000 where the old page was, and somehow have the final write from the earlier instruction be performed onto the new page. Note that re-executing the instruction would not work because it has already modified the high-order (lower-address) word of the value, and repeating the instruction would erroneously modify the high-order word again.

There are two approaches that can be used to handle this in a single-CPU system:

  1. Have a processor signal to the MMU what areas of memory are going to be written before the committing to accessing them, so that if a page fault is going to happen it will occur before memory has been modified. Doing this would also require that the processor be capable of unwinding modifications to any affected address registers (like the pre-decremented A0 in the above example), but this approach is used by many systems today.

  2. Have the processor's bus fault handler store on the stack information about current instruction progress, in such a fashion that when the trap handler resumes, the processor can finish off whatever parts of the instruction hadn't yet been executed successfully. I think this is what the 68010 did.

Making #2 work in all situations for all of the instructions in the 68000's arsenal involves adding a lot of complexity, which pushed up the amount of circuitry in--and thus cost of--the 68010. If one needs a single-CPU system that can efficiently handle virtual memory a complex instruction set and without an on-chip data cache, such complexity may be unavoidable(**), since having to interrogate external memory about whether it can be written prior to accessing it would slow things down.

(*) Some machines by Apollo (their DN416/DN100 workstations) used two 68000 processors, only one of which could be running at a time. One of the processors would run "ordinary" code, but if a bus fault happened it wouldn't be interrupted. Instead, it would be frozen while the other 68000 would start code execution, use some circuitry on the motherboard to find out what kind of access the first CPU was doing, swap memory pages as required, and then allow the first CPU to resume operation. Having the first CPU exist during page fault handling solely for the purpose of maintaining its state, and having the second CPU exist solely for purposes where the first CPU had to be kept frozen, may seem wasteful, but it was the most practical way of doing what needed to be done.

(**) If the above example were being done on a system with a 32-bit bus and a cache, the system would probably read words at $1FFFC and $20000 before writing anything, and the MMU could have informed the CPU during each read whether the associated memory is writable. Thus, the CPU would know--before starting the write operation--that it would fail. Alternatively, some architectures deliberately avoid instructions that combine multiple operations in ways that would not allow for re-execution. On something like an ARM, if one uses an STRMIA instruction to store 13 multiple words of data and a fault occurs while writing the tenth word, registers will be rewound to the state prior to instruction execution. Re-executing the instruction would cause the first nine words to get written again, but that would generally be harmless since--unlike the example with the ADD instruction--the STRMIA instruction would be unaffected by the earlier contents of the memory in question.

3
  • 2
    interesting, but I fail to see how it answers the original "why wasn't it used" question Jun 24 at 17:31
  • 3
    @Jean-FrançoisFabre: Nearly all of the extra complexity in the 68010, compared to the 68000, exists to support a feature which is essential for some specialized kinds of systems, but would offer little or no benefit to anything else. A workstation like a Dec Alto which was designed before the 68010 was available needed to use two 68000 chips and a whole lot of support circuitry to accommodate what a 68010 could do on its own, so even if the chip cost twice as much as a 68000 it would be worth it for that application (since it would literally replace two 68000 chips). In most systems...
    – supercat
    Jun 24 at 17:44
  • 2
    ...that could get by with a single 68000, however, the ability to handle and recover from mid instruction traps would have added no benefit whatsoever. To use an analogy, the situation would be analogous to a company introducing a DVD player and then later introducing a player that could also play RealAudio files that were stored on CD. Such a player might be incredibly useful for someone with a collection of music encoded in the RealAudio format, but the extra cost and complexity would offer no benefit to anyone else.
    – supercat
    Jun 24 at 18:10
7

I can make some guesses. Price? Availability? Compatibility fears? They didn't know it existed?

In the case of the Atari ST, price was everything, so even a marginal increase in cost between the 68000 and the 68010 was enough to disqualify the latter. Plus, Atari was porting an existing operating system (first CP/M 68K, then GEMDOS) that itself targeted the MC68000. (GEM & GEMDOS could have been ported to the 68010 easily enough, though.)

Dadhacker had a good insider's account on the development of the Atari ST: "The Atari ST (part 1)," "The Atari ST, Part 2," and (relevant to this discussion) "How the Atari ST almost had Real Unix," which was thwarted due to the 68000's inability to restart an instruction after a fault and lack of a proper MMU (although the author speculates on a "very simple, very hippy 70s" approach to software-based memory management).

Dadhacker also mentions Atari first considered using the National Semiconductor 32000, but found the chips "buggy and quite slow." While I don't find an explicit mention, that tells me they were studying other contenders, and most certainly would have known of the MC68010.

3

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.