Hacker News Reader

Comment by jakedata | Hacker News Reader

This was all happening at the start of my career in computer stuff. I say computer stuff because it was a jumble of all the different things one needed to do in an early startup environment.

It was really exciting not knowing which way things would end up going, I was working on 68k, PowerPC Macs along with x86 Windows 3.1 and NT 3.1 (installed from 5 1/4 floppies!) and super early Linux.

We truly didn't know if Apple was going to survive the Gilbert Amelio era and decided to port everything to Windows. We never even tried to support Netware and it remains a somewhat shameful gap in my skillset.

In my basement at W’land dead computers wait dreaming, yet they shall rise and my kingdom shall cover the Workbench.

View on HN

Super early linux (and MacBSD) on Macs in that era was pretty interesting. Usually there was an Mac application you would run, the computer would snow crash, and suddenly dmesg would start over-writing the screen. I have no idea how that worked, exactly, I assume it was effectively overwriting the running operating system in memory and then just jumping to the kernel. It wasn't until the PowerPC era that things got easier with OpenFirmware.

(author) Pretty much that, since Mac OS didn't have much concept of memory protection. MkLinux on NuBus Power Macs had to do the same thing, and even current NetBSD/mac68k still does. The PDMLoader in this article works on the same notion as well.

I imagine both the Toolbox ROM and the memory-mapped IO would remain in memory, right?

I remember reading the source code to the Penguin bootloader [1] and was amused that it actually called some Toolbox shutdown routines before jumping to the kernel...

[1] https://sourceforge.net/projects/linux-mac68k/files/Penguin%...

Even in the OpenFirmware PowerPC era, BootX was a reasonably popular classic MacOS app that worked the same way for booting into Linux (and confusingly, was also the name of a Mac OS X bootloader component). I think the BeOS loader also worked the same way.

The BeOS loader was a little trickier: that one actually managed to enter supervisor mode, which shouldn't have been possible, and was why BeOS wasn't supported on Mac OS 9 (only 8.6 and earlier).

The main reason for OpenFirmware being added (was not in the 6100, 7100, or 8100 PPCs)was because Apple was supporting the Mac Clone business back then.

I was at Apple back then, on the project this post is about, and remember being in OpenFirmware meetings with John Rubinstein who at the time was with FirePower. As noted in the article the Netware startup code had a hacked OF interpreter to boot the NW volume to do mappings that was not used on real OF machines. Because it was just a development hack that’s why some things, like being hardcoded for 24Meg RAM, were implemented. Once we got real OF prototypes those limits were gone.

The planned NW port was intended to work on any PPC OF hardware although Apple was only going to supporting native drivers for Apple stuff.

Reply on news.ycombinator.com