Apple

The emulator is for OS X, and is provided in source form ..

A Macintosh II emulator that runs A/UX (and A/UX only).

Shoebill is an all-new, BSD-licensed Macintosh II emulator designed from the ground up with the singular goal of running A/UX.

A/UX 1.x.x through 2.0.0 are supported currently, and 3.x.x support is in progress.

Shoebill requires a OS X, a Macintosh II or IIx ROM, a disk image with A/UX installed, and an A/UX kernel.

Shoebill currently Implements

[*]68020 CPU (mostly)
[*]68881 FPU (a little)
[*]68851 PMMU (just enough to boot A/UX)
[*]SCSI
[*]ADB
[*]A NuBus video card with 8-bit resolution


Does not implement (yet)

[*]Sound
[*]Floppy
[*]Serial ports
[*]Ethernet
[*]PRAM / VIA timers
[*]Support for multiple screens, or 16/24-bit resolutions


More information may be found on the project's wiki .

Very cool! Thanks for sharing this!

josehill wrote: Very cool! Thanks for sharing this!

Yes, it is pretty cool! I didn't think I'd ever run A/UX again, although it was cool for it's time, it's very much like a retro OS X.

1) No PowerPC port, no peace. (Guess what I'll be doing this weekend.)
2) It says 3.x support is in progress. That's not too helpful.

My 40MHz-clockchipped Q800 is smirking in the corner. (It runs 3.1.1.)

ClassicHasClass wrote: My 40MHz-clockchipped Q800 is smirking in the corner. (It runs 3.1.1.)

My old SE/30 really wants to run A/UX again, too. Just haven't gotten around to it.

Anyone know if A/UX supported the old Micron Xceed video cards? My SE/30 has a card in it that it didn't have when it last ran A/UX.

Well, I got the core to compile on the G5 and did some horrible hacking on the Cocoa code to make it at least start on 10.4, even if none of the dialog options work. I suspect there are some endian problems lurking to be found, but it does at least come up and try to check options (before, since I have no kernel file, it fails).

However, I don't have A/UX 2.0 disks here, just 3.1.1. If someone wants to play with this, PM me.

josehill wrote: My old SE/30 really wants to run A/UX again, too. Just haven't gotten around to it.

Anyone know if A/UX supported the old Micron Xceed video cards? My SE/30 has a card in it that it didn't have when it last ran A/UX.

You should just sell the Xceed to me!

ClassicHasClass wrote: Well, I got the core to compile on the G5 and did some horrible hacking on the Cocoa code to make it at least start on 10.4, even if none of the dialog options work. I suspect there are some endian problems lurking to be found, but it does at least come up and try to check options (before, since I have no kernel file, it fails).

However, I don't have A/UX 2.0 disks here, just 3.1.1. If someone wants to play with this, PM me.

Hey! I'm the author of Shoebill.

Shoebill on PPC definitely has endianness issues. The FPU especially expects Intel-style, little endian, IEEE 754 80-bit floats, and I'm not sure if IEEE 754 floating point math is even available on the G5 or other PPC chips. If you grab the latest commit on github, it no longer requires a extracted A/UX kernel - it can load it from the root image itself. (You'll still need a 1.x.x, 2.0.x, or 3.0.0 root image, though.) I'm impressed that you got it to basically compile and run on PPC 10.4! I'm totally cool with porting Shoebill to other platforms besides 10.8/10.9, I just don't have a machine to test it on, or any familiarity with GUIs besides modern Cocoa.

Hey, nice to see you here. The FPU emulation will be a problem; it's all regular 32/64-bit floats. I'll have to look at that.

I pulled source just on Friday. Does that include your root image commits?

ClassicHasClass wrote: Hey, nice to see you here. The FPU emulation will be a problem; it's all regular 32/64-bit floats. I'll have to look at that.

I pulled source just on Friday. Does that include your root image commits?

https://github.com/pruten/Shoebill/comm ... c922cbc2f6 got pushed on thursday or friday, so likely yes.
If most PPC architectures support 128-bit long doubles, those could be used as the internal registers, and then rounded down to 80-bits (albeit with *too much* precision). The FPU needs to be blown away and largely rewritten, anyways.

Well ... I could maybe get that to work with the AltiVec registers, which are 128-bit, but that would entirely exclude G3.

I see the problem, though, because now that I think about it the Apple 68K emulator on Power Macs doesn't even try to emulate the FPU -- it emulates a 68LC040 and uses the internal SANE routines to handle FP.

Looks like I need to repull in any case, since I must have grabbed the rev right before that push. I also see the be2native() function lurking at the bottom of coff.c I'll need to fix immediately ...

If anyone has a kernel file I can use to test, I'd appreciate it -- as I say, all I have is A/UX 3.1.1, though it is running on a real live Q800. I just want to make sure the initial emulation comes up even though it will immediately freak out, unless you know that an A/UX 3.1.1 kernel will at least start to some state.

... and, now that I've had a more indepth look at fpu.c, I'm an idiot. You're using long double, which presumably compiles to 80-bit FPU registers on x86. That should map to 128-bit software double-doubles on PowerPC, so I just need to change the mapping for the machine representation.

Mmm, double-doubles. I think I'll go to In-N-Out ...

ClassicHasClass wrote: ... and, now that I've had a more indepth look at fpu.c, I'm an idiot. You're using long double, which presumably compiles to 80-bit FPU registers on x86. That should map to 128-bit software double-doubles on PowerPC, so I just need to change the mapping for the machine representation.

Mmm, double-doubles. I think I'll go to In-N-Out ...

The trick is that the Motorola 68881 uses the same 80-bit explicit-mantissa-bit extended double format as Intel chips, although packed differently in memory. I poked around about PPC, and I think that some PPC architectures support 128-bit floats, but most 32-bit PPC chips don't. Compilers on 32-bit platforms cleverly implement long doubles with two 64-bit floats - but they aren't really IEEE 754 compatible. All that aside, if you manage to get Shoebill to boot on a PPC, I'd be super interested in seeing the changes you made

I don't have a 3.1.1 kernel to test with, but I've read that 3.1.1 doesn't work with non-32-bit-clean ROMs, like the Mac II's, and Shoebill can only boot with those ROMs. So it's possible that 3.1.1 will boot a little, but I'm only sure that 3.0.0 will boot to the Finder shell.

gcc's double-double on PowerPC will work on 32 and 64-bit PPC, so that should be fine. Conversion to and from PPC double-double to 80-bit long double should not be hard, and in your code should just involve changing fpu_bytes_to_long_double() and x87_to_motorola(), if I understand your program flow correctly.

I just uploaded v0.0.2 to the github, https://github.com/pruten/Shoebill/releases . (New features: 3.0.0 "support", native support for kernel loading, and some modest speed improvements.) If I had access to a G5, I might be able to make Shoebill big-endian friendly - but I'm not sure it's worthwhile/feasible to port it to 32 bit PPC platforms, since Shoebill makes extensive use of 64 bit ints internally. It runs significantly slower on x86, so I can't imagine it'd be usable on <=G4s...

One thought is that, if there's a platform-independant integer-based (preferably BSD-licensed) IEEE 754 math library somewhere, I could integrate that into Shoebill and have it be the basis of the FPU on non-Intel platforms. I expect it wouldn't slow things down very much, since 680x0 developers expected the FPU to be relatively much slower compared to the CPU. The problem with GCC's long doubles on 32 bit PPC chips is that they're not IEEE 754 compatible at all, so I can't just blindly memcpy those (long double)s into the emulated address space and expect things to work.

Another option is that we could go with regular 32 bit PPC FPU math, and just let the FPU have much less precision than it should have. But I'd really like to run Mathematica some day... that'd make a great screenshot

pruten wrote: One thought is that, if there's a platform-independant integer-based (preferably BSD-licensed) IEEE 754 math library somewhere, I could integrate that into Shoebill and have it be the basis of the FPU on non-Intel platforms.

Have you had a look at John Hauser's SoftFloat library? http://www.jhauser.us/arithmetic/SoftFloat.html

That's a good choice, actually.

I haven't had cycles to look at this recently (darn Master's degree) but I'm going to pull the new release when I get a spare minnit.

If anyone cares, there is some SDL additions to shoebill, and Ive got a working Windows version !

In further news, Shoebill now has Ethernet support! And I added SLiRP support for Win32.

Details are here ..

It works great!

Sweet!