4 ms·

Yes. The idea wasn't to get away with not having an MMU, though - it was to get away with shipping the Mac with an ungodly low amount of RAM for a machine with

Yes. The idea wasn't to get away with not having an MMU, though - it was to get away with shipping the Mac with an ungodly low amount of RAM for a machine with a GUI. I believe the original idea was to ship with like 64k or something? Obviously, with the state of mobile hardware back then relocatable blocks were also similarly necessary in order to save RAM. For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking. The MMU is necessary to keep applications from writing other apps' heaps, not to do memory defragmentation. You can do some cool software-transparent defragmentation tricks with MMUs, but if you're deciding what the ABI looks like ahead of time, then you can just make everyone carry double-pointers to everything.

NegativeLatency 3y ago
I actually installed an aftermarket MMU in my Macintosh II, since it's required for A/UX. https://retrocomputing.stackexchange.com/questions/10931/what-was-the-design-of-the-macintosh-iis-mmu-replacement https://retrocomputing.stackexchange.com/questions/10931/wha... https://aux-penelope.com https://aux-penelope.com
spc476 3y ago
Well, there's also the fact that the MC68000 in the original Mac didn't have an MMU, and it was difficult to add an external MMU to a 68000 system [1]. You could use an MMU sanely starting with the MC68010, and it wasn't until I think the MC68030 that the CPU came with an integrated MMU. [1] Because exceptions on the 68000 didn't save enough information to restart the faulting instruction. You could get around this, but it involved using two 68000s as insane hack ...
- JNRowe 3y ago
  Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU. The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68k and coldfire this century, not any real data. ¹ https://en.wikipedia.org/wiki/Motorola_68030#Variants https://en.wikipedia.org/wiki/Motorola_68030#Variants
  - kjs3 3y ago
    And there's more mud to be found! The 'EC' version of the 68040 & 68060 was "no MMU, no FPU", and there was an 'LC' variant of the 68040 & 68060 that was "MMU, no FPU". There were huge numbers of embedded 68k family chips shipped, although I've never seen the actual numbers. Folks went from 68000 to 68ec020 to 68ec060 as a (sorta) easy upgrade path. They're still made if you count the 68sec000, and the 68300 line is the spiritual successor.
- kjs3 3y ago
  You could use an MMU sanely starting with the MC68010 Whether the Motorola MMU for the 68010 (the 68451) was sane or not is a matter of some debate. The 68451 was definitely slow and limited (segments, not pages); in the end, most vendors rolled their own MMU out of static RAM and PALs.
kalleboo 3y ago
> For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking Yeah, the way to port classic MacOS apps to native OS X apps was called Carbon, and it was basically 80% of the classic MacOS toolbox just ported to OS X, Handles and QuickDraw and all. Classic MacOS apps written to CarbonLib would "just run" natively in OS X (and the same binary in Classic MacOS). Carbon even kept working on Intel MacOS, but they finally killed it with the 32-bit deprecation a year or two before Apple Silicon was released. Apple could have worked in multitasking in classic MacOS if they really wanted to, but their management was totally dysfunctional in the 90's where there was no point seen in investing in boring old MacOS since there was always a revolution just around the corner in the form of Pink, Taligent, Copland etc, projects which due to the aforementioned management never went anywhere.
- Someone 3y ago
  > Apple could have worked in multitasking in classic MacOS if they really wanted to They did, and they couldn’t. Most users had some code running that patched system calls locally or globally or that peeked into various system data structures, and all applications assumed the system used cooperative multitasking. Going from there to a system with preemptive multitasking would mean breaking a lot of code, or a Herculean effort to (try to) hack around all issues that it caused with existing applications. I think that would have slowed down the system so much that it wasn’t worthwhile making the effort. Having said that, MacOS 9 had a preemptive multitasking kernel. It ran all ‘normal’ Mac applications cooperatively in a single address space, though. Applications could run ’tasks’ preemptively, but those tasks couldn’t do GUI stuff (https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/Multitasking_MultiproServ/01introduction/introduction.html https://developer.apple.com/library/archive/documentation/Ca...)
  - miki123211 3y ago
    Microsoft actually sort of did that with Windows 9x. There was a lot of Windows 3.1 and DOS software and drivers that they wanted to remain compatible, and those relied on DOS quirks. So, they had a copy (copies) of DOS always resident in RAM, mostly unused. All DOS syscalls (interrupts) were hooked so that they would call Windows instead. If a program added its own hooks, Windows would detect that and switch to 16-bit mode for the relevant operation. When the custom hook completed, it would call the next hook in the chain, which was the one that went back to Windows. Of course, this relied on Windows understanding DOS's internal data structures and keeping them in sync with what Windows was doing. A similar technique was used for drivers, if Windows found a driver it didn't understand, it would let that driver run in 16-bit mode. Raymond Chen (of Microsoft fame) explains this much better than I ever could https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063 https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...
Someone 3y ago
> I believe the original idea was to ship with like 64k or something? Yes. Both the 6809 based design and the first 68k one targeted 64k. See https://folklore.org/Five_Different_Macs.html https://folklore.org/Five_Different_Macs.html
kjs3 3y ago
I believe the original idea was to ship with like 64k or something? I believe the original original idea was 64K and a 6809 instead of the 68000. Quickly became clear that wasn't going to live up to expectations.

NegativeLatency 3y ago

I actually installed an aftermarket MMU in my Macintosh II, since it's required for A/UX. https://retrocomputing.stackexchange.com/questions/10931/what-was-the-design-of-the-macintosh-iis-mmu-replacement https://retrocomputing.stackexchange.com/questions/10931/wha... https://aux-penelope.com https://aux-penelope.com

spc476 3y ago

Well, there's also the fact that the MC68000 in the original Mac didn't have an MMU, and it was difficult to add an external MMU to a 68000 system [1]. You could use an MMU sanely starting with the MC68010, and it wasn't until I think the MC68030 that the CPU came with an integrated MMU. [1] Because exceptions on the 68000 didn't save enough information to restart the faulting instruction. You could get around this, but it involved using two 68000s as insane hack ...

JNRowe 3y ago
Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU. The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68k and coldfire this century, not any real data. ¹ https://en.wikipedia.org/wiki/Motorola_68030#Variants https://en.wikipedia.org/wiki/Motorola_68030#Variants
- kjs3 3y ago
  And there's more mud to be found! The 'EC' version of the 68040 & 68060 was "no MMU, no FPU", and there was an 'LC' variant of the 68040 & 68060 that was "MMU, no FPU". There were huge numbers of embedded 68k family chips shipped, although I've never seen the actual numbers. Folks went from 68000 to 68ec020 to 68ec060 as a (sorta) easy upgrade path. They're still made if you count the 68sec000, and the 68300 line is the spiritual successor.
kjs3 3y ago
You could use an MMU sanely starting with the MC68010 Whether the Motorola MMU for the 68010 (the 68451) was sane or not is a matter of some debate. The 68451 was definitely slow and limited (segments, not pages); in the end, most vendors rolled their own MMU out of static RAM and PALs.

kalleboo 3y ago

> For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking Yeah, the way to port classic MacOS apps to native OS X apps was called Carbon, and it was basically 80% of the classic MacOS toolbox just ported to OS X, Handles and QuickDraw and all. Classic MacOS apps written to CarbonLib would "just run" natively in OS X (and the same binary in Classic MacOS). Carbon even kept working on Intel MacOS, but they finally killed it with the 32-bit deprecation a year or two before Apple Silicon was released. Apple could have worked in multitasking in classic MacOS if they really wanted to, but their management was totally dysfunctional in the 90's where there was no point seen in investing in boring old MacOS since there was always a revolution just around the corner in the form of Pink, Taligent, Copland etc, projects which due to the aforementioned management never went anywhere.

Someone 3y ago
> Apple could have worked in multitasking in classic MacOS if they really wanted to They did, and they couldn’t. Most users had some code running that patched system calls locally or globally or that peeked into various system data structures, and all applications assumed the system used cooperative multitasking. Going from there to a system with preemptive multitasking would mean breaking a lot of code, or a Herculean effort to (try to) hack around all issues that it caused with existing applications. I think that would have slowed down the system so much that it wasn’t worthwhile making the effort. Having said that, MacOS 9 had a preemptive multitasking kernel. It ran all ‘normal’ Mac applications cooperatively in a single address space, though. Applications could run ’tasks’ preemptively, but those tasks couldn’t do GUI stuff (https://developer.apple.com/library/archive/documentation/Carbon/Conceptual/Multitasking_MultiproServ/01introduction/introduction.html https://developer.apple.com/library/archive/documentation/Ca...)
- miki123211 3y ago
  Microsoft actually sort of did that with Windows 9x. There was a lot of Windows 3.1 and DOS software and drivers that they wanted to remain compatible, and those relied on DOS quirks. So, they had a copy (copies) of DOS always resident in RAM, mostly unused. All DOS syscalls (interrupts) were hooked so that they would call Windows instead. If a program added its own hooks, Windows would detect that and switch to 16-bit mode for the relevant operation. When the custom hook completed, it would call the next hook in the chain, which was the one that went back to Windows. Of course, this relied on Windows understanding DOS's internal data structures and keeping them in sync with what Windows was doing. A similar technique was used for drivers, if Windows found a driver it didn't understand, it would let that driver run in 16-bit mode. Raymond Chen (of Microsoft fame) explains this much better than I ever could https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063 https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

Someone 3y ago

> I believe the original idea was to ship with like 64k or something? Yes. Both the 6809 based design and the first 68k one targeted 64k. See https://folklore.org/Five_Different_Macs.html https://folklore.org/Five_Different_Macs.html

kjs3 3y ago

I believe the original idea was to ship with like 64k or something? I believe the original original idea was 64K and a 6809 instead of the 68000. Quickly became clear that wasn't going to live up to expectations.