Exploring the Macintosh ROM (2019)
macgui.com
macgui.com
This practice got more and more awkward as the number of Macintosh models ballooned, and was largely abandoned by the early 90s (too many machines, and groups got file servers and ethernet instead of floppy disks and localtalk).
It was fun just reading the code; it was really well-commented, and nearly every line had someone's initials on it (spot a bug? track down the responsible party and talk about a patch...)
Developing software without source control is difficult to imagine now. ("We do have source control, his name is Mike -- just give him a floppy disk with your changes and some instructions on how to integrate them.")
I've been reading and enjoying systemtalk.org's examination of each month's MacUser from this era. It's striking how much sheer support, in terms of new hardware and software, the Mac received right out of the gate despite being, well, almost completely useless given the limited RAM (the "Fat Mac" appeared very quickly for a reason), no Apple hard drive, and not even a second floppy drive available at launch; the endless disk-swapping was enough to cause insanity. Nonetheless, it was good enough to make the 128K Mac the first $2500 impulse buy. <https://www.newspapers.com/article/the-cincinnati-enquirer/3...> Although Amiga and Atari ST followed within 18 months later with far superior hardware, it's clear in retrospect (and, I suspect, to anyone at the time comparing Macworld/MacUser/MacWeek to the corresponding Amiga/ST publications) that Apple had completely sucked up the air in the "not PC" segment of the market.
Apple had the credibility to do so in the first place, of course, because of its success with the Apple II. In turn, Mac's share of the market was minuscule compared to what the IBM PC had built around itself since 1981, as any comparison of PC/PC World/InfoWorld to the above Mac publications would have shown. But it was enough to survive for the long term. Desktop publishing and "people who love windows and mice" were niche markets c. 1985-1990, but it is a niche, and a reasonably defendable one; Amiga's desktop video niche was correspondingly much smaller, and ST never found one at all outside maybe music.[1]
I wrote "superior hardware", not "superior hardware and software". Not enough attention has been given to just how good classic Mac OS was from the beginning. I would say je ne sais quoi, but that's not accurate because the care given to both the UI (in the form of the Toolbox burnt into the ROM discussed in this post) and underlying architecture is obvious as opposed to being indefinable/ineffable. Atari and Commodore both outsourced their OS development and it shows. Yes, Amiga has out-of-the-box true preemptive multitasking.[2] But what good is it if the OS doesn't have quality libraries, toolkits, and primitives? As baroque and obscure as Inside Macintosh was for the Mac developer c. 1985, at least he had it as a resource, and at least the OS is sophisticated enough to justify such a baroque and obscure tome in the first place. And Atari TOS? Don't make me laugh; that it was tolerable to so many in Europe just shows how low a bar the ZX Spectrum had set for the masses there.
[1] Yes, yes, Europeans, I know that Amiga and ST were much more successful across the Atlantic. That only meant that the PC takeover of the entire market skipped the first half of the DOS era in Europe, as opposed to not happening at all. (And yes, I know about the Amstrad clones.)
[2] I dare anyone, then or now, to a) succinctly and accurately explain the difference between AmigaOS and AmigaDOS, and b) explain why that should matter in the first place
exec.library is the kernel, which used to be called "ROM Kernel".
The ROM portion of the OS is called Kickstart.
The disk portion is called Workbench, but is also used to refer to workbench.library (mostly a file manager) today.
The whole system became AmigaOS at some point, probably around the 2.x release (1991).
IMHO exec.library is great, but dos.library was a huge mistake.
0. https://archive.org/details/amiga-rom-kernel-reference-manua...
I'm interested in your take on this point. I cut my m68k teeth on Amiga demo programming, but never delved into exec (apart from a very small amount of init).
For better or for worse, though, compact Macs never increased from the original 512x342; for the price, I think successor Amigas easily ate the Macintosh's lunch in terms of graphical capabilities.
(Disclaimer: I know much, much more about early Macintoshes than Amigas, since it's what I col]leect.)
This is a blessing in disguise (and part of what I was alluding to regarding the quality of Apple's toolkit for developers). That targeting, and the B/W limitation, forced Susan Kare and other Apple UI people to produce very high-quality icons and widgets that were and are suitable for professional use. Amiga's widgets, designed for a TV set, are garish, low-resolution, and pretty awful; the ST's are overall better (thanks to the GEM heritage) but still not as good as Apple's.
MacOS today looks more like System 1 than System 7 looks like either; that's how good Apple's UI design c. 1984 is.
It didn’t have to be; it was a design choice. It seems they found colour support and price more important than having a crisp display.
As examples why it is a choice:
- the TRS-80 (typically) came with its own monitor, for 64-character lines and ‘superior’ image quality (but do read https://en.wikipedia.org/wiki/TRS-80#Video_and_audio)
- the PET similarly was monochrome.
They’re both older, though, and they couldn’t compete against home computers that did colour (https://en.wikipedia.org/wiki/Commodore_PET#Graphics_display: “In the home computer market, the PET line was soon outsold by machines that supported high-resolution color graphics and sound”)
So, I think it was the right choice for that kind of product at that time.
PET and TRS-80's graphics are inferior to Apple II in their inability to do anything other than character-set graphics. Apple II in 1977 offered not just color, but bitmapped graphics.
Had IBM's MDA in 1981 offered Hercules-style bitmap graphics, it's possible that CGA might never have seen widespread use at all.
It'd have an associated increase in cost. You'd need to add some SRAM, even for tiled graphics.
For 40 years people have said that IBM made a mistake by only implementing the garish CGA 4-color palette on RGB monitors. But given that that was also done for a) and probably b), this discussion has made me think that perhaps non-graphics MDA might have been as big a mistake for IBM, maybe even more so if it could have been implemented for less cost than proper full-palette CGA on RGB.
With that in mind, it's indeed weird that they shipped MDA the way it was.
IBM seems to have thought that customers would either want super high-quality text, or lower-resolution graphics, and that the few who wanted both would buy both MDA and CGA adapters (which some people actually did). I'm pretty sure MDA was the first priority given that IBM didn't sell a CGA monitor at launch. (I'll get back to this.) And, in fact, MDA greatly outsold CGA at first.
The PC design team had many Apple II owners. The II's influence on the PC's design is obvious. Regarding video, IBM probably thought that those who wanted color would use a TV or composite monitor, on which CGA can do 16-color graphics. Those who wanted high-quality text of course would want to use a monitor, to which IBM catered with an IBM-branded monochrome model. From IBM's perspective, offering both options would be superior to the II, which in 1981 did not offer RGB output, only composite (and CGA is an improvement over Apple II's composite color video), and no Apple-branded 80-column output or way to use a monitor for MDA-like super high-quality text output.
IBM did not foresee that very few people would use TVs or composite monitors for CGA; had it done so it surely would have offered its own CGA monitor at launch. Most people instead bought a third-party RGB monitor, resulting in sharper text but the horrible 4-color palette.
Huh? CODE segments were never relocatable at runtime. That'd be absurd.
"Although needed code segments are loaded into memory automatically, it is your application’s responsibility to unload any segments that are not currently being used. The Segment Manager provides a single procedure, UnloadSeg, that you can call to unload a segment. To unload a segment is simply to unlock it. By unlocking unneeded segments, you allow them to be relocated or purged if necessary to accommodate a later memory-allocation request. Thus, using the Segment Manager to unload unneeded segments is one important aspect of an efficient memory-management policy."
Later on in the 68k Mac OS lifecycle, compilers figured out how to bypass the 32k segment limit, and would often compile the entire application to a single CODE resource, sometimes with auxiliary resources for embedded libraries. There was certainly no unloading those.
So the C compilers released later had bugs if they couldn't ignore/handle an UnloadSeg() call on one of their generated CODE segments.
By the time I got into Mac development, THINK C and MPW C didn't seem to have any problems with CODE segments.
68010 supported an MMU, so did 68020.
68030 bundled a MMU (except EC variants).
Anything you'd need to create great apps by 1985 standards.
Macs were rare in Europe during the 80s because they were hugely expensive there. The dollar was very strong during the mid 80s. GDP per capita in UK/France/Germany went from parity with the US at market exchange rates in 1980 to about half in 1985. They became much more common in the 90s.
A similar divergence happened in the early 2000s and then again for much of the past decade. It's why Android is much more popular in Europe now.
I have no doubt Ghidra has a superior overall user interface. But, as memory serves, Nosy had many features specifically for the classic MacOS and ROM that I assume Ghidra lacks.
https://web.archive.org/web/20231106024332/https://macgui.co...
Show HN a Googlewhack: Success
Productive use of a term Google can’t find: Thought experiment but nothing else