Macintosh Plus Booting Minix 1.5

[@thirstyCactus]

Cool! If you use a camera with adjustable shutter speed, that would prevent CRT rolling.

[@Thiesi]

2:30 - Someone carrying out a ZModem transfer is not something I expected seeing in 2024.

[@MotownBatman]

Thats Awesome! Cant say I have ever seen anyone Boot this on a Mac before.

[@darkwinter6028]

Huh… interesting. It’s (obviously) co-existing with the native Mac OS & Toolbox.

[@thirstyCactus]

I believe the windowing system and widget set exist in BIOS. So MacOS is not necessarily running.

[@darkwinter6028]

@@thirstyCactus The classic Mac doesn’t work anything like a PC - there’s no BIOS per se, what there is is a set of software modules (usually called ‘managers’ - so, the Window Manager, the Serial Manager, etc) with the majority of them being resident in ROM, but some of them (or portions of them) are loaded into RAM at boot. These ROM based modules can also be patched at boot, so things as small as a single function can be updated by new code. Collectively, these are referred to as the Toolbox. There’s also a module referred to as the OS which handles low-level device drivers. All of this is interdependent on each other - in order for one section to be running, it generally means other sections are running also. So, basically, if you’re seeing the GUI on screen, then the Toolbox is running, and if there’s any disk or serial IO occurring then the low-level OS is running also. FWIW, this ROM based approach is how they got a whole GUI & OS running on a machine with only 128k of RAM and still had enough left over for running an application.

[@zanekaminski]

​@@darkwinter6028 The Mac Toolbox with the managers is the BIOS. It's just more elaborate and the terminology is different. In x86 PC world, the BIOS was originally not just a bootloader and settings utility but it had the drivers for working with the hardware. Apps running bare-metal on the PC would call BIOS routines via the x86's INT syscall/software interrupt mechanism to read/write the disk, put stuff on the screen, etc. The Mac is similar where the A-line trap instructions would invoke toolbox calls. Except instead of just reading the disk and doing simple screen output like on the IBM ROM BIOS, there were higher-level concepts such as resources, windows, the mouse pointer, etc. I see those as the Mac developers' concept of the "hardware drivers" for a GUI machine. Nowadays on a modern x86 PC it sounds archaic to have stuff like the window manager in ROM since every OS does it differently, plus any good OS (Windows, Linux, etc) does not use the BIOS routines even for disk I/O after the initial parts of boot. But the IBM BIOS had a few pretty sophisticated "OS-type" features, such as the clock interrupt, printing, display including fixed-width "fonts" (the INT 1Fh character table), and even the INT 18h "execute BASIC" call. So I would say that the Mac's architecture was a kind of unusual intermediate step between an OS and userspace fully in RAM and the bare-metal IBM PC app style where a program calls the BIOS for all I/O. If you think about the transition between the single-app Mac execution model and MultiFinder/System 7, it's basically the same as the "coexistence" between Minix and the Toolbox stuff you referred to. Before MultiFinder, only one app ran at once. With MultiFinder or System 7, you had cooperative multitasking and the way the system worked was fairly different than was anticipated in the Toolbox ROM. Interestingly though, many of the things in the ROM such as the memory manager ended up sort of applied twice over when running MultiFinder or System 7, once at the system level and once at the app level. For example, the memory manager handles allocation of each application zone within the overall system RAM, but then after a context switch into an app, the global variables are changed so that the memory manager is used to allocate storage from the application heap zone that was previously allocated by the memory manager in the "OS" context. So my point is that if you know how to use the managers, you can sort of reuse them in contexts not originally considered as long as you set up the global variables correctly. I suspect it would be possible, for example, to have a totally different, even preemptively multitasked OS that still calls into ROM to draw the GUI on the screen using the window manager, menu manager, etc. Is this how A/UX does it? I wouldn't be surprised if it reused the ROM routines like that, but I also wouldn't be surprised if it just had its own version in RAM.

[@alpcns]

I can only imagine how much work it must be to port this operating system to the Mac. Very well done, sir

[@jefftranter]

I didn't port it - this was an official release of Minix for the Mac.

[@alpcns]

@@jefftranter That's interesting - thank you. You always have interesting videos.