The big change is the new 68881 maths FPU emulation. Â It’s completely new code in this version. Â As the author, Pruten mentions:
it should be the “most accurate” 68881 emulator (with regard to chip behavior) ever written, as far as I can tell. I can’t find another open source emulator that even attempts to emulate FPU exceptions, probably because Motorora’s documentation is terrible. Rife with typos and errors, and lacking descriptions for lots of edge cases. It’s also a superset of IEEE 754, so it’s tricky to get softfloat, a strict IEEE 754 implementation, to implement all the weird extra behaviors in the 68881.
On the flipside however:
It will also be much slower than the old version, since the new FPU uses integer-based softfloat. The transcendental instructions will be emulated by running whatever the best natively available function is, and then blindly copying the result to the dest FPU register. Since the FPU is the last big piece of shoebill that requires x86, this should allow it to compile on other architectures, like maybe PPC
I’ve only recently rebuilt the emulator with only the addition of the SLiRP code that I’ve been able to debug from Cockatrice IIIÂ (who said that I was wasting my time? Â At a minimum I ‘fixed’ up SLiRP to make it more stable), and kicked out a Win32 build (source/binary).
I’ve just had it running doing a simple shell script after disabling the UI. Â So far it’s 15 hours of uptime…
Â 8:43am up 15:02, 3 users, load average: 0.00 0.01 0.01
Which is nice.
I should add, to disable the UI in A/UX it’s best to edit the inittab and change
co::respawn:/etc/getty console co_9600
And now you’ll get a “text” login.
I guess the real test will be to see if it makes it through the night.
And yes it did!
5:40pm up 1 day, 2 users, load average: 0.00 0.00 0.00
I’ll let it run a little longer but this is like a new record. Â Although at the same time, I’m not hammering the poor thing.
# netstat -ni
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ae0 1500 10.0.2 10.0.2.15 4232 0 3551 0 0
lo0 1536 127 127.0.0.1 157 0 157 0 0
I have tried to run the “new” built shoebill binary, unfortunately it always says “sdl.dll” not found.
I’ve tried also running the older shoebill binary with other ROMs, e.g. with a ROM of a Mac IIci … the prebuild images (thx for it, makes it much easier) are starting to run A/UX, but then it stops (after showing up some commands, it goes black and stays black).
Also, using a german PC (of course with german Windows and a german keyboard) will result in missing but important chars like ‘/’ …
Anyway, keep on posting about A/UX, *very* interesting.
Trying to run “Apple HD SC Setup” result also in a crash, see
You can’t “install” A/UX in a normal manner. Although if you want the “thrill” of running the apple partitioning tool it’ll run on Cockatrice. The CLI partitioning tool runs under A/UX….
Since Shoebill can’t run MacOS it’ll just load the kernel from disk (it can read UFS) and boot into that. I guess I can go over an “install” but it’s more of a copying media onto a disk image. Also the SDL stuff is very common and found libsdl.org
After getting sdl.dll, I was able to use your new compiled version.
It’s much more stable and the double click works (with the older version, double click on the drive / on an object did not start any action).
You wrote, running Mac OS is not supported while using A/UX ?
When using the precomposed A/UX 2.0/3.01 image, I was able to start the TextEditor from the mac/bin folder – this is not a MacOS program ?
It seems that HD SC Setup fails because of one API/BIOS call, not of something else…
Booting native MacOS isn’t supported, is what I should say Shoebill can ONLY run A/UX.
Also my build has SLiRP so you can kind of connect to the internet. Or you can at least telnet into yourself port 42323 on the local machine is redirected into 10.0.2.15 (typical SLiRP config 10.0.2.15/255.255.255.0 with a default route of 10.0.2.2 and DNS of 10.0.2.3).
I guess I should do a re-write of all the piecemeal of how to get ShoeBill up and running.