[ramijames]

If I remember correctly, there's an interesting historical reason for this: a lot of the original functionality that we'd today consider "part of the OS" was actually in ROM on hardware in really old Macs. Mouse functionality, basic windowing, etc. This meant that to get A/UX running you first had to bootstrap into a light version of Mac OS and then boot into A/UX.

[somat]

It is sort of the same for DOS. When you start digging around in the source you realize it is only really half an operating system and a surprising amount is done in the BIOS.

[a96]

Yes, and it really was just a Disk Operating System.

[FireBeyond]

Yeah, that was similar to Amiga and the Kickstart concept, initially on floppy, then as a separate ROM module. Going from AmigaOS 1.3 to 2.0 with the applicable Kickstart ROM gave you a whole new UI layer.

[a96]

Yes. It was a pretty big chunk, too. Floppies were around 880k and base model RAM sizes were 512k to few MB. Having better part of a meg of libraries in ROM really helps fit more stuff in. And it was possible to load RAM patches or shadow things IIRC.

https://www.amigaforever.com/kb/15-127

[FireBeyond]

RAM: and RAD: the RAM drive and the Recoverable RAM Drive - because putting things in memory that can survive a reboot isn't just for virii!

[ramijames]

I miss the Amiga.

[Taniwha]

Not really (I wrote the mouse/display drivers and kernel event queue driver for A/UX 1.x) - A/UX has it's own kernel ADB (and mouse/kbd on top of that) and display drivers, it will happily boot from hard drive, and throw up a non-mac terminal on a Mac display card without executing anything from the Mac ROMs.

The later MacOS running on A/UX ran in a single A/UX (system V) process

[ramijames]

So what am I remembering that A/UX needed to boot from ROM?

[Taniwha]

I'm pretty sure the ROMs loaded a boot sector booter and jumped into that, it's been a long time but I'm pretty sure that's what we handed over to Apple

[ramijames]

I guess that makes sense. Thanks for the answer and the trip down memory lane.

[Taniwha]

It's possible that later A/UXs required booting MacOS - but when we started we got 1/2 the initial prototype production run of Mac 2s (no cases, bugs in pals, probably no standard ROMs yet)

Our standard agreement for porting Unix to new hardware (we did something like 150 different boxes, not just macs) required a minimal ROM monitor that could download code from a serial port (we could provide source), we'd take it from there, write S/A code to store data on the harddrive, download a file system, start downloading kernels into ram debugging the disk and serial drivers until we got a shell prompt ... then moving development onto the box

[yjftsjthsd-h]

The Toolbox ROMs, right? I can see the utility of using that (I mean, beyond that you might need to use it to boot), but why couldn't A/UX call those APIs itself? I can easily see where bootstrapping through Mac OS would be easier, but I can't immediately see why it would be particularly necessary.

[kjs3]

It's been a long time, but I'm pretty sure A/UX didn't use any of the toolbox roms and had it's own drivers (we had the source). A/UX booted from a MacOS partition because the Mac bootloader only understood booting MacOS (and it wasn't writeable with new boot code), so you booted to MacOS, then started SASH, which loaded Unix.

[classichasclass]

That's exactly the reason. NetBSD uses its own booter for the same purpose, for example.