-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
The TAM and OS X
- Thread starter quantumii
- Start date
If you're talking about BootX, then, no, it doesn't need its own partition. Instead, it runs as an extension under the classic Mac OS and offers an option to continue the MacOS boot or to boot under Linux.
It's not too hard to set up, basically you copy the kernel and ramdisk files for linux to a couple of folders to the Mac Os partition and point BootX at them. There are a couple of optional switches which may take some trial and error to get right, but nothing too complicated.
FWIW, last time I did this was when I installed Ubuntu 9.04 on a Wallstreet. The biggest problem I had was that I had put Mac OS on an HFS+ volume and had problems with copying the kernel and ramdisk from the installed system to it.
It's not too hard to set up, basically you copy the kernel and ramdisk files for linux to a couple of folders to the Mac Os partition and point BootX at them. There are a couple of optional switches which may take some trial and error to get right, but nothing too complicated.
FWIW, last time I did this was when I installed Ubuntu 9.04 on a Wallstreet. The biggest problem I had was that I had put Mac OS on an HFS+ volume and had problems with copying the kernel and ramdisk from the installed system to it.
The one hesitation I'd have personally, as I know next to nothing about the TAM, when it comes to trying to run Linux on it is whether or not its built-in LCD requires oddball video timing, and whether there might be bad consequences should Linux fail to recognize that fact and attempt to reset the video mode to "normal" 6500-plus-a-CRT timings.
I mention this because I happen to own a Dolch PAC portable of about the same vintage as a TAM, and its built-in 800x600 LCD display is linked to a video card with a custom BIOS that "knows" that the LCD's native timing is nothing like a CRT monitor. (The 800x600 mode, for instance, uses a 40 hz refresh rate.) Debian's X.org server surprisingly enough is able to pick up on this ancient machine's peculiarities and automatically do the right thing, but if the TAM depends on some oddball hackery tacked onto the motherboard's built-in video support that Linux can't detect it's possible it'll go all pear-shaped when you boot up. It's been a good half-decade since I last ran Linux on a Mac, but I remember X support being touchy, particularly on "oddball" machines.
(The original iMacs were another good example. Monitor auto-detection didn't work, so unless you put custom modelines into your X configuration file to force it to stick to the the oddball resolution/refresh rates the built-in monitor actually supported you'd get a black screen when the ATI driver would pick a "standard" multisync rate instead.)
I mention this because I happen to own a Dolch PAC portable of about the same vintage as a TAM, and its built-in 800x600 LCD display is linked to a video card with a custom BIOS that "knows" that the LCD's native timing is nothing like a CRT monitor. (The 800x600 mode, for instance, uses a 40 hz refresh rate.) Debian's X.org server surprisingly enough is able to pick up on this ancient machine's peculiarities and automatically do the right thing, but if the TAM depends on some oddball hackery tacked onto the motherboard's built-in video support that Linux can't detect it's possible it'll go all pear-shaped when you boot up. It's been a good half-decade since I last ran Linux on a Mac, but I remember X support being touchy, particularly on "oddball" machines.
(The original iMacs were another good example. Monitor auto-detection didn't work, so unless you put custom modelines into your X configuration file to force it to stick to the the oddball resolution/refresh rates the built-in monitor actually supported you'd get a black screen when the ATI driver would pick a "standard" multisync rate instead.)
As noted the TAM is a 6500/250 board with the analogue video output connected to a complex LCD controller board; this runs to the exact same display used in a Powerbook 3400. To be honest I've not heard of any video issues running alternate operating systems (eg. BeOS, Linux). The LCD controller board is probably the most custom part of a TAM; most other parts are basically pulled from another Mac of the same era, or thereabouts - it's not pretty inside, looking more like a prototype with ribbons all over the place.
I suspect a lot of work has gone into developing the LCD controller board part over everything else, to avoid obscure issues as to what you have described. The TAM I purchased in New York had a faulty one of these (OK video for a couple of minutes, then increasing corruption until white screen), and I tried everything to diagnose a fault. Sadly nothing came worked so I found a place in the Netherlands - luckily - which sold the part new.
I'm tempted to trial Ubuntu PPC 9.1 on my TAM soon, to give it more up-to-date software, if at all possible. Even BeOS. However, there really isn't much to be read about doing this, and I'm not too familiar with either OS. If any TAM owners here can shed light on what they've done and how it went, please respond
JB
I suspect a lot of work has gone into developing the LCD controller board part over everything else, to avoid obscure issues as to what you have described. The TAM I purchased in New York had a faulty one of these (OK video for a couple of minutes, then increasing corruption until white screen), and I tried everything to diagnose a fault. Sadly nothing came worked so I found a place in the Netherlands - luckily - which sold the part new.
I'm tempted to trial Ubuntu PPC 9.1 on my TAM soon, to give it more up-to-date software, if at all possible. Even BeOS. However, there really isn't much to be read about doing this, and I'm not too familiar with either OS. If any TAM owners here can shed light on what they've done and how it went, please respond
JB
Again, I don't really know if there's anything about the TAM's video in particular that's problematic, but it would be interesting to hear the experience of someone who's done it to see what they have to say... Particularly if they've done it "recently". The reason I say "recently" is there was a transition in the Mac linux-es around the 2002-2004 era in how they handled the video drivers. When first installed "real" Linux on a Mac (I'm not counting installing MkLinux on a 6100 in 1998), an 8500 with LinuxPPC 2000 in mid-2000, the Mac Linuxi usually used a generic "framebuffer" video driver that used whatever video mode you'd set the Mac to before starting the kernel with BootX. This was a "must" on the 7200-9600 systems that used proprietary Apple video chips since it was quite some time before the Linux people were able to reverse-engineer how to directly set video modes on them. You could also use this server on the systems that used ATI chips (5400-6500, iMacs, etc.) and it would work "fine", if a little slowly. However, later Mac Linuxi (Starting with Yellow Dog 2-3-ish?) started favoring sniffing the hardware and attempting to use the native Xfree86 driver if one existed, and that's where things got hairy. (Losing video on iMacs when X started if the installer failed to set up the modelines for you, etc.)
I don't have any Old World Macs anymore (haven't for *years*), so I don't know if the default behavior when installing Linux (with one of the few distributions that still support Old World, obviously) is to try to be "smart", or to default to the "safe" framebuffer server. The latter *should* work fine on a TAM, I'd just worry a little about the former. Apple's proprietary sense-line based monitor auto-detection is only dimly understood (if at all) by Linux, and if the TAM uses some "weird" extended code to identify its LCD board it could get weird.
If I had a TAM and a directive to install Linux on it I'd probably try plain Debian over Ubuntu, since Debian is far less aggressive about trying to be "smart". Just to play it safe.
I don't have any Old World Macs anymore (haven't for *years*), so I don't know if the default behavior when installing Linux (with one of the few distributions that still support Old World, obviously) is to try to be "smart", or to default to the "safe" framebuffer server. The latter *should* work fine on a TAM, I'd just worry a little about the former. Apple's proprietary sense-line based monitor auto-detection is only dimly understood (if at all) by Linux, and if the TAM uses some "weird" extended code to identify its LCD board it could get weird.
If I had a TAM and a directive to install Linux on it I'd probably try plain Debian over Ubuntu, since Debian is far less aggressive about trying to be "smart". Just to play it safe.
Similar threads
