The collected works of pruten

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.

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.

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.

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