NextSTEP for an old Quadra/Centris

[somorastik]

Hi I have a couple old macs at home and Im figureing a use for them. I thought of usig them as some kind of unix server, or some light control in room (still have to figure out the structure of apple serial ports).

I thought of nextstep running on an old mac.

Is it even possible?

Is the operting system possible to obtain?

Thanks!

Keep on rollin in the 68k free world

 

[QuadSix50]

As far as I know, this isn't possible. However, you can see about installing NetBSD on there or even GNU/Linux (specifically Debian/m68k).

 

[MrMacPlus]

Depending on the model I would use A/UX.

 

[II2II]

Go with what QuadSix50 said: NetBSD, OpenBSD, or Linux. There are good reasons for that, but I think that the main one that you're going to run into are a limited number of daemons for the older operating systems.

I also wouldn't waste your time trying to get NextSTEP running on a Mac. It would be a difficult multistep process that you would have to do entirely manually, probably develop your own tools, and it is still bound to end in failure. It would go something like this: you would need a bootloader, to get the kernel into memory. If you're lucky, all you need to do is figure out which memory address is has to be loaded into memory at and where the entry point is. Then you jump to that address. I'm almost willing to bet that it won't be that easy though, since the firmware usually does a bit of work before handing control over to a kernel. I have no idea what that would entail. Even if you successfully get the kernel loaded, you have a problem. You're running 100% blind. Even if the Next hardware used the exact same keyboard, display, and serial controllers as a Mac, chances are that they would be found at different addresses. But chances are they won't use the same controllers. After all, all of that is the hardware designers discretion. Even if you could swing all of that, you would still need some way to get a filesystem into place, with all of the files installed in their proper location. For that you would probably have to develop your own tools. But that probably wouldn't even matter anyway, since there is about a zero percent chance of the SCSI controller working without serious patching to the kernel.

To give you a rough idea of how hard this would be, consider this: a friend of mine, a NeXT nut with his own NeXT workstation, tried to load the Intel version on an Intel system. It failed because it didn't recognise the SCSI controller. And the Intel version wasn't designed specifically for NeXT hardware.

I mean, it can probably be done. But in order to get it done you would have to be a genius on an order that would make someone with the combined intelligences of Torvalds and Stallman look like a dimwit; as well as enough patience and stamina to make Ghandi look rash and undetermined. But yeah, I'm sure it can be done. }

 

[porter]

Depending on the model I would use A/UX.

For historical interest A/UX is okay, but it is poor in terms of hardware support, thread support, shared library support etc. It is most definitely not a modern UNIX.

Personally I like NetBSD on m68k.

Apart from the Macintosh GUI the only things A/UX does that NetBSD can't are floppy and LocalTalk support.

 

[QuadSix50]

Although, if you DID want a NeXTSTEP-looking interface, there's always Window Maker. But be aware that X Windows would probably run slower than a rotting dog covered in tar.

 

[porter]

Although, if you DID want a NeXTSTEP-looking interface, there's always Window Maker. But be aware that X Windows would probably run slower than a rotting dog covered in tar.

Of course a way to improve the speed of X on a resource challenged machine is to use a remote X terminal.

 

[paws]

Although, if you DID want a NeXTSTEP-looking interface, there's always Window Maker. But be aware that X Windows would probably run slower than a rotting dog covered in tar.

My (limited) experience with NetBSD on my Quadra 700 tells me that the limiting factor is the hard drive. Untarring is slow. Moving files is slow. X isn't that bad though. Moving windows about and such is actually OK. It's not going to run Firefox, of course, but a text editor and an xterm or two will be fine.

 

[ChristTrekker]

My (limited) experience with NetBSD on my Quadra 700 tells me that the limiting factor is the hard drive. Untarring is slow. Moving files is slow. X isn't that bad though. Moving windows about and such is actually OK. It's not going to run Firefox, of course, but a text editor and an xterm or two will be fine.

My experience with NetBSD is that disk speed isn't so bad, unless it's an AV model, in which case the speed is abysmal.

I agree that X isn't so bad, with a light WM (I'm fond of Blackbox) and basic apps.

 

[ChristTrekker]

For historical interest A/UX is okay, but it is poor in terms of hardware support, thread support, shared library support etc. It is most definitely not a modern UNIX.
Personally I like NetBSD on m68k.

Agreed. I love A/UX (probably one of the few ppl on the planet working on writing/porting code for it) but I completely recognize that it's just a hobby for my amusement, not a serious endeavor. But OTOH, isn't doing anything with a 68k Mac a hobbiest activity these days? So, use A/UX if you want, but be aware that in many ways it will be deficient to NetBSD.

 

[QuadSix50]

My (limited) experience with NetBSD on my Quadra 700 tells me that the limiting factor is the hard drive. Untarring is slow. Moving files is slow. X isn't that bad though. Moving windows about and such is actually OK. It's not going to run Firefox, of course, but a text editor and an xterm or two will be fine.

My experience with NetBSD is that disk speed isn't so bad, unless it's an AV model, in which case the speed is abysmal.

I agree that X isn't so bad, with a light WM (I'm fond of Blackbox) and basic apps.

This is good to know as I've never actually gotten far enough to run X on 68K Unix. I've heard others say that it's unusably slow so I kind of took it at face value. :I

 

[II2II]

Hum, I wonder if that explains my experiences with NetBSD. I was perfectly happy with NetBSD on my SE/30 and Q950. But when I tried in on a Q660AV, I found it mind-bogglingly slow. Until now, I always assumed that it was due to the X server trying to deal with a higher resolution display at a much greater colour depth (I used the X server on the SE/30, but only used serial consoles on the Q950). Or maybe I was just using a slightly newer version of NetBSD (I moved from 1.3 to 1.4 at some point). But if there is poorly supported hardware in there, that may be a better explaination.

 

[ChristTrekker]

But if there is poorly supported hardware in there, that may be a better explaination.

Yup, there's something about SCSI on the AVs that isn't supported well. I have no idea what about it is different, but that's the way it is. Unfortunately for me, I learned this after I'd tracked down and installed on an 840.

The good news is that this does still see some development. There were patches posted within the last year that may provide a foundation for solving this problem. My take on it is that the smart driver ppl know what the problem is, it's just a question of getting in there and actually doing it, which would take a bit of tinkering.