I do not know if I am the only one but I can not connect to the site. The DNS resolves but I get the feeling this is "their way" of dealing GDPR? That or it actively blocks me because I have Linux in my user-agent? It's fishy.
This site's focus is on the very earliest Macs, especially the original 128K model in early 1984.
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
Correct me if I'm wrong, but IIRC AmigaOS is the whole operating system, while AmigaDOS is the part of that OS that handles disk I/O, plus the CLI, etc. Yeah, a naming mess.
> IMHO exec.library is great, but dos.library was a huge mistake.
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).
THere's another consequence of choosing DTP (and office suites as a positive consequence) over video production as a target market: at the launch of the product line, Steve Jobs chose the tradeoff of a high-resolution, square-pixel display, but only in B&W, over colour output formats that could only do high resolution with interlacing.
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.)
>THere's another consequence of choosing DTP (and office suites as a positive consequence) over video production as a target market: at the launch of the product line, Steve Jobs chose the tradeoff of a high-resolution, square-pixel display, but only in B&W, over colour output formats that could only do high resolution with interlacing.
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.
The Amiga and Atari ST were home computers not workstations, their UI had to be usable on the crappy TV sets most households would have owned back then. When you account for that obvious difference, their UX was broadly on par and even sometimes superior to the early Macintosh, especially wrt. multimedia.
> The Amiga and Atari ST were home computers not workstations, their UI had to be usable on the crappy TV sets most households would have owned back then.
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.
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.
> “In the home computer market, the PET line was soon outsold by machines that supported high-resolution color graphics and sound”)
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.
Oh, sure. But there's nothing exotic about Hercules (thus the endless clones of it) that prevented IBM from implementing something like it in 1981 except a) cost and b) possibly some vague worry that graphics/color = games = non-serious computer.
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.
Motorola 68000 CPU had no MMU so OS and applications ran in the same address space so anyone could do anything and a lose pointer could crash the whole box at anytime. This is true for all early Mac, Amiga and Atari. 68020 CPU was the same. There was an MMU only from the 68030 but still many OS didn't take advantage of it upon release.
"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."
That bit of the documentation was... misguided. Relocating code segments was incompatible with many popular C runtimes (typically because CREL/DREL relocations were applied to the segment at load time, and there was no way to rerun that after a segment was moved), and was dangerous even if that wasn't the case (because stray references to the old location would often persist, e.g. as function pointers).
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.
Not misguided when the Macintosh was initially introduced with 128K of RAM. All the articles I've read about Apple Mac software development state that 68K assembly language and Pascal were used for software development.
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.
AmigaOS was pretty competitive for the time in 1985. Like you mentioned, pre-emptive multitasking, but also nice intertask (=process) communication, layers & windowing library, a good graphics library, a good set of GUI gadgets (=widgets), etc.
Anything you'd need to create great apps by 1985 standards.
> [1] Yes, yes, Europeans, I know that Amiga and ST were much more successful across the Atlantic.
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.
When I was at Apple (started in '87, about the time the Macintosh II shipped), many of the groups in the systems software and support orgs (development tools, networking, etc.) had a table where there were binders of ROM assembly listings, maybe 2-3 linear feet of paper bound in a metal rack. They were a big help with particularly tricky crashes, or for figuring out ROM bugs, or just learning about the system.
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.")
Managing a common large body of assembler like that, in hardcopy, seems to be a lost art... it reminds me of how the same amount of assembler needed to be managed in hardcopy for the Apollo DSKY/AGC, complete with paper changelogs, line number conventions, etc. [1] But a lot of the bookkeeping there looks like was needed as well to keep track of changes to punchcard decks.
if you want to mess with Mac ROMs now, I think Ghidra is a nicer experience than most of the vintage tools, and you can use QEMU with GDB (at least for the Q800 ROM).
I used MacNosy extensively in the Mac 68k era. Though I haven’t used Ghidra, reading about it reminded me of the fun (and frustration) I had with MacNosy.
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.
37 comments
[ 3.1 ms ] story [ 80.7 ms ] threadhttps://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
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.
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.")
[1] https://www.youtube.com/watch?v=-y37tXoBDx0
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.