https://retrocomputing.stackexchange.com/questions/10931/wha...
[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 ...
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.
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.
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.
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.
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/Ca...)
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=24...
There was a company that re-implemented the macos toolbox on various Unixes. I hope somebody on HN worked there and can fill in more details.
Tldr; from [0]
The company was orignally Quorum Software Systems, Inc. which transformed into -> Latitude Group in 1994, and which got bought by Metrowerks in 1996-7?.
The original product was called Equal, and allowed Microsoft Word 5.1a and Excel 4.0 (the macos versions) to run on UNIX, with native [Motif?] look and feel and good performance without source code.
they later made a library called 'Latitude' so macos App developers could easily port their apps to Unix, which was how the Adobe Apps - Photoshop / Illustrator etc. got made available for Unix. .. and Latitude also apparently implemented a lot of QuickDraw.
"At the heart of Latitude is our own Portable Toolbox Implementation Layer. This layer is completely platform independent. It presents the Mac Toolbox API to the application, answers these calls through a trap table mechanism, and relies on other toolbox calls within the layer whenever possible. When a native system facility is needed, such as the display of a window or control, or some graphical rendering, this layer calls out to one of Latitude's platform dependent modules through an internal, well defined API. The toolbox layer doesn't know what kind of system lies underneath, only that calling this function will display a window or that function will draw a line, etc.
.. Because we've mapped native system facilities to Mac calls, the running application is an equal citizen on the desktop. The application's windows, menus, and control items are native system objects. Cutting and pasting between apps is facilitated by the native system's clipboard mechanism. Fonts come from the system font server -- including the default system font, which means the dialogs come up in something other than Chicago! Application windows are native windows -- not some rendering of a window inside of another. The performance hit is minimal. Latitude is merely mapping the Mac calls to the native system. There is very little processing going on in between. "
[0] http://preserve.mactech.com/articles/mactech/Vol.13/13.06/Ju...
Yes. Both the 6809 based design and the first 68k one targeted 64k. See https://folklore.org/Five_Different_Macs.html
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.
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.