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.

It's extremely buggy right now, very incomplete, and a little difficult to setup since you'll need to extract the A/UX kernel from your boot image (/unix).Pro tip: (if you have an A/UX installation CD, you can boot directly from that.)

I'll work on getting up documentation in the near future. In the mean time, if anyone is so inclined and adventurous, you can try to get it running with a Macintosh II ROM, an A/UX installation CD image (v1 or v2), and the kernel from that CD.

Yeah, Shoebill emulates the Mac II's MC68851 PMMU coprocessor and NCR5380 SCSI controller.I just started implementing hardware and instructions as necessary to get A/UX further along in the boot process, so I don't know exactly why other emulators can't boot A/UX.

Wow... if you're emulating the MMU... well, let's just say there are quite a number of emulators that could really use that code. If I can find the time, this might even get me interested in porting that code over to BII and MESS!

Please consider adding the MMU code to the MESS project as well; it would be good to have it documented there.

I'm trying to abstain from peeking at how other Mac emulators are implemented, so can't speak to exactly how difficult it would be. But decoupling the MMU from Shoebill would be a little tricky, since it's baked into the memory access primitives. The important chunk is this, for traversing page tables and doing the virtual address translation. The handful of PMMU instructions that A/UX actually uses are implemented in core/mc68851.c.

IIRC, there's an MMU patch for UAE floating around out there, so that'd be an easier way to add MMU support to Basilisk II.

MESS has rudimentary MMU; but not an MMU that will run A/UX -- so you've obviously implemented a few things that aren't documented there. But if you're doing memory access shortcuts and not implementing the entire PMMU set, I'm not sure how useful merging will be. Definitely more work than I was originally thinking.

Sorry I don't have better ideas for extracting the unix kernel from an A/UX install CD. I'm hesitant to post them online myself, even though Apple probably already did that back when they used to release A/UX minor version updates online. (If anyone has the A/UX 2.0.1 update, btw, I'd be very interested.)

Any chance you could compile it against the 10.6 SDK? Supposedly 1 in 5 Mac users still uses 10.6, and a large number of them appear to frequent these forums Testing against 10.9 would probably still be fine, but at least it would be more likely to work under 10.6. Testing via VM would be fairly easy in VirtualBox if you can get your hands on a 10.6 DVD.

I hacked together a universal build for 10.8, v0.0.1a. You can get it on the release page. I'll try to make future releases 10.8/universal compatible. Unfortunately, I don't have a convenient way to make 10.7 or earlier builds.

huntgr,

I'm generally booting from the install CDs directly. The disk images are presented to A/UX as real SCSI disks, so they do need partition maps. A/UX won't recognize a raw HFS volume on a disk image unless it's encapsulated in a partition. It seems that System 6 under A/UX 2.0.0 isn't capable of recognizing and formatting an unpartitioned disk, so I've been using System 7 under Basillisk II to partition my disk images.

I think there are CLI partitioning tools in A/UX 2.0.0, but I'm not sure what they are or how to use them.

You can install Xcode 3.2 on 10.9 (using some tricks), which allows you to build for 10.4-10.6. There are several guides for how to do this floating around, I think I used this one: http://lapcatsoftware.com/articles/xcod ... nlion.html . I recommend installing it in a custom prefix like /Xcode3 , so that it can't possibly interfere with your existing modern Xcode.

Another option is running 10.6 in a virtual machine, which is what I usually do.

What ROM are you using? IIci-and-newer ROMs paint the screen black (I think) because they have internal video chips that shoebill doesn't implement and that A/UX prefers to use. A/UX 2.0.0 and earlier don't support multiple monitors, so the second monitor is painted black. Shoebill should work with II/IIx/IIcx ROMs, (all of which are 256KB.)

It's interesting that the xunix will use the secondary screen, though.

There's currently no way to properly install A/UX. The only way for now is to create a new disk image, partition it (swap + svfs/ufs), and copy the contents of the CD to the new disk. Penelope used to have a procedure for doing this with A/UX 1.1.1 that should apply to 2.0.0 as well - but I've just been booting directly off the install CD.

If you do install A/UX onto another disk image, be sure to back it up! UFS/SVFS get corrupted really easily.

Thanks for working on this pruten! Never thought I'd see the day I could run a emulated A/UX. And this is on top of UAE being able to run AMIX.

There's a A/UX 0.7 archive on macintoshgarden that I've long been curious about. It's a tar archive of an installation so presumably it would have to be unpacked onto a disk image to boot. Have you any idea how I could go about doing this? Or would Shoebill be able to run it?

Shoebill 0.0.1 *currently* can't run it, because it expects there to be a Macintosh II video card (toby frame buffer) attached. I have a partly-emulated toby frame buffer card (core/toby_frame_buffer.c), but you can't currently access it via the GUI. I'll see what I can do for the next release