[HN Gopher] Exploring the Macintosh ROM (2019)
___________________________________________________________________
Exploring the Macintosh ROM (2019)
Author : zdw
Score : 51 points
Date : 2023-11-06 14:30 UTC (1 days ago)
(HTM) web link (macgui.com)
(TXT) w3m dump (macgui.com)
| ivolimmen wrote:
| 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.
| 0xDEADFED5 wrote:
| I can't connect either, probably the HN Embrace of Doom?
|
| https://web.archive.org/web/20231106024332/https://macgui.co...
| dirtyhippiefree wrote:
| Doing a Google Advanced Search for the exact phrase "HN
| Embrace of Doom" shows *one* link...this post...
|
| Show HN a Googlewhack: Success
|
| Productive use of a term Google can't find: Thought
| experiment but nothing else
| swagempire wrote:
| Please me more expansive in your mind and support starting
| new trends...
| TMWNN wrote:
| 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
| blue1 wrote:
| 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.
| snvzz wrote:
| Yes, it refers[0] to dos.library and complementary software
| such as the shell, cli commands, scripts.
|
| 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...
| nxobject wrote:
| 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.)
| TMWNN wrote:
| >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.
| zozbot234 wrote:
| 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.
| Someone wrote:
| > 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.
|
| 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.
| TMWNN wrote:
| > "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.
| snvzz wrote:
| >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.
| TMWNN wrote:
| 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.
| rjsw wrote:
| The flat address space of the Atari ST made it a lot easier to
| port workstation software to it than the segmented memory
| management of Mac OS.
| vardump wrote:
| Mac OS and Atari ST had both Motorola 680x0 CPUs. So both had
| a flat address space.
| rjsw wrote:
| Only one of them ran an operating system that exposed it to
| applications.
| icedchai wrote:
| Also, we should mention that early Mac OS "borrowed" the
| top 8 bits of a 32-bit pointer for operating system use:
| https://lowendmac.com/2015/32-bit-addressing-on-older-
| macs/
| speed_spread wrote:
| 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.
| rjsw wrote:
| Mac OS put code into segments that could be moved around,
| Atari ST TOS didn't do this.
| snvzz wrote:
| 68000 had no MMU and didn't support one, due to inability
| to recover from bus error.
|
| 68010 supported an MMU, so did 68020.
|
| 68030 bundled a MMU (except EC variants).
| vardump wrote:
| 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.
| neonate wrote:
| https://web.archive.org/web/20231106024332/https://macgui.co...
| kabdib wrote:
| 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. ")
| nxobject wrote:
| 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.
|
| [1] https://www.youtube.com/watch?v=-y37tXoBDx0
| cy384 wrote:
| 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).
| msgilligan wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-07 23:01 UTC)