Live data from Hacker News

Exploring the Macintosh ROM (2019)

macgui.com

31–38 of 38 posts

Re: Exploring the Macintosh ROM (2019)

#31
post #30
post #28

Earlier quoted context omitted.

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 proba…

Interesting; I was not aware CGA was also 1981. With that in mind, it's indeed weird that they shipped MDA the way it was.

>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.

Re: Exploring the Macintosh ROM (2019)

#32
post #24

Earlier quoted context omitted.

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.

Mac OS put code into segments that could be moved around, Atari ST TOS didn't do this.

> Mac OS put code into segments that could be moved around

Huh? CODE segments were never relocatable at runtime. That'd be absurd.

Re: Exploring the Macintosh ROM (2019)

#33
post #5

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 f…

> [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.

Re: Exploring the Macintosh ROM (2019)

#34
post #24

Earlier quoted context omitted.

Mac OS put code into segments that could be moved around, Atari ST TOS didn't do this.

> Mac OS put code into segments that could be moved around Huh? CODE segments were never relocatable at runtime. That'd be absurd.

from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/ma...:

"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."

Re: Exploring the Macintosh ROM (2019)

#35
post #24

Earlier quoted context omitted.

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.

Mac OS put code into segments that could be moved around, Atari ST TOS didn't do this.

They were never moved around, but could be unloaded manually and read back from (floppy) disk at another memory location.

Re: Exploring the Macintosh ROM (2019)

#36

Earlier quoted context omitted.

> Mac OS put code into segments that could be moved around Huh? CODE segments were never relocatable at runtime. That'd be absurd.

from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/ma... : "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.…

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.

Re: Exploring the Macintosh ROM (2019)

#37

Earlier quoted context omitted.

from Apple Macintosh Segment Manager docs - https://developer.apple.com/library/archive/documentation/ma... : "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.…

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 t…

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.

Re: Exploring the Macintosh ROM (2019)

#38
post #8
post #6

Earlier quoted context omitted.

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.

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). IM…

> 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).

Post reply on HN