4 ms·

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, an

by 65a 3y ago

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.

classichasclass 3y ago
(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.
- nxobject 3y ago
  I imagine both the Toolbox ROM and the memory-mapped IO would remain in memory, right?
nxobject 3y ago
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%20Booter/Penguin-19/ https://sourceforge.net/projects/linux-mac68k/files/Penguin%...
mrpippy 3y ago
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.
- classichasclass 3y ago
  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).
knuckleheadsmif 3y ago
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.

by 65a 3y ago

classichasclass 3y ago

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

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

nxobject 3y ago

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%20Booter/Penguin-19/ https://sourceforge.net/projects/linux-mac68k/files/Penguin%...

mrpippy 3y ago

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.

classichasclass 3y ago
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).

knuckleheadsmif 3y ago

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.