I've been trying to keep the core cross-platform for unix-y systems, avoiding Apple-specific APIs. It used to have a bare-minimum GLUT interface with hard-coded parameters. Aside from that, I don't have much experience with windows or linux GUIs.

Making slow progress on v0.0.2 - here's what might be included- A bug fix for cmpa that lets A/UX 3.0.1 *boot*, although not start the Finder shell- Native support for APM/UFS/SVFS for loading the unix kernel directly from the root image- A new debugger (I ditched the old debugger when switching from GLUT to Cocoa)- The ability to restart/stop the emulator- Maybe support for full screen / multiple screens- Maybe support for PRAM - because it's really annoying how all the PRAM settings are scrambled on startup

I've been trying to keep the core cross-platform for unix-y systems, avoiding Apple-specific APIs. It used to have a bare-minimum GLUT interface with hard-coded parameters. Aside from that, I don't have much experience with windows or linux GUIs.

Making slow progress on v0.0.2 - here's what might be included- A bug fix for cmpa that lets A/UX 3.0.1 *boot*, although not start the Finder shell- Native support for APM/UFS/SVFS for loading the unix kernel directly from the root image- A new debugger (I ditched the old debugger when switching from GLUT to Cocoa)- The ability to restart/stop the emulator- Maybe support for full screen / multiple screens- Maybe support for PRAM - because it's really annoying how all the PRAM settings are scrambled on startup

I could release a bare-bones GLUT GUI as an example of how to write a GUI - and if anyone else is so motivated, perhaps they could write an SDL GUI. If anyone's interested in that, I can make an effort to finalize the core API.

I'm using the AUX 3.0 image: “AUX_3.0.1_Install.toast_image” with an MD5 of dd3edefa2095821878a8b6dee7dc7940 , and my Mac II FDHD rom has a MD5 of 2a8a4c7f2a38e0ab0771f59a9a0f1ee4.

I just built the latest sources from github (version 0.2!) which seem to have been updated yesterday. I got it to compile, but I'm having some weird stuff with 3.0.

First I found out that the UFS image on the 'install' disk is corrupt according the A/UX 2.0. I ran fsck -y /dev/rdsk/c1d0s0 and repaired it, copied over the /unix and extracted the image no problem. However when trying to boot, I'd get an exception in scsi.c. namely:

assert(fread(scsi.buf, len * 512, 1, dev->f) == 1);

Some more diving into the source, and I find it failing to assert during a read. Namely this:

scsi_buf_set: Responding to read at off=464 len=0

So I made a quick change, and if len=0 then do a read of 16... that made that part happy, but naturally another portion of the code also asserts that len>0 in scsi_dma_read ....

I'm using the AUX 3.0 image: “AUX_3.0.1_Install.toast_image” with an MD5 of dd3edefa2095821878a8b6dee7dc7940 , and my Mac II FDHD rom has a MD5 of 2a8a4c7f2a38e0ab0771f59a9a0f1ee4.

I just built the latest sources from github (version 0.2!) which seem to have been updated yesterday. I got it to compile, but I'm having some weird stuff with 3.0.

First I found out that the UFS image on the 'install' disk is corrupt according the A/UX 2.0. I ran fsck -y /dev/rdsk/c1d0s0 and repaired it, copied over the /unix and extracted the image no problem. However when trying to boot, I'd get an exception in scsi.c. namely:

assert(fread(scsi.buf, len * 512, 1, dev->f) == 1);

Some more diving into the source, and I find it failing to assert during a read. Namely this:

scsi_buf_set: Responding to read at off=464 len=0

So I made a quick change, and if len=0 then do a read of 16... that made that part happy, but naturally another portion of the code also asserts that len>0 in scsi_dma_read ....

Hey neozeed, thanks for experimenting! Glad to see that it'll build on other people's machines

So far I've been running 3.0.0 successfully. It's interesting to know that 3.0.1 is sending 0-length reads - unless there's another bug at fault, I'll have to refactor the scsi code a little to handle it. (Not sure how scsi phase transitions work for 0-length reads...)

Macguicity has a 3.0.0 image named AppleUNIX_3_Install.zip. The decompressed ISO has an MD5 of 76a62bde471b0a14b09f9bf39eb79755. 3.0.0's /unix's MD5 is 781d840c54be5e462224beda82a99d32.

And yeah, 2.0.0 and 3.0.0 disagree on how the "dirty" filesystem flag works. 2.0.0 thinks all 3.0.0 images are dirty. Fsck on 2.0.0 will reset the flag, and also I think you can just mount the filesystem readonly (-o ro), and it'll ignore the dirty flag.

(One other thing to note about 3.0.0 - when you start it up for the first time, after a few minutes, it will suddenly freeze. Just wait 5 minutes and it'll start running again, and the problem won't reoccur. Not sure what the problem is yet...)

Ah ok, I had 3.0.1 and you are using 3.0.0 ...! I found 3.0.0 and have it running!

One thing I noticed from your screencap is that you have 256MB of ram in the emulator, and watching mine boot up with that much there is a LOT of processes that freak out on boot with signal 11.. which from my old days of questionable machines is a memory error. I re-ran it with 32mb of ram, and it didn't have any complaints and booted up to logon in a few seconds, and gave me a desktop without any significant wait.

I tried to put some ISO's into the mix, but A/UX doesn't like them... well 2.0 & 3.0.0 don't I still haven't worked out how to start the UI on 1.1.1 ... I remember just being able to pop a CD into my quadra and it mount back in the day..

Now I just need to figure out how to partition a disk, and do a dump/restore onto a "proper" hard disk.. It's a shame the filesystems on A/UX are so fragile. I remember that being a major problem back in the day as well.

Yeah, 256MB seems to be the maximum A/UX 3.0.0 can handle. A/UX 2.0.0 seems to support all the way up to 1GB, the maximum supported by the 68k Mac architecture, albeit with lots of complaining.

I've mostly had luck so far with ISOs on 3.0.0. 2.0.0 takes exception to the partition scheme on a lot of CD images (I think). Which ISOs aren't mounting for you? I could take a look at them if they're publicly available. Might be related to different sector sizes on cd-roms vs. hard disks...

Getting the GUI running on 1.1.1 should normally require you to manipulate the inittab to boot into multi-user mode, and run /etc/toolboxdaemon in the background as a daemon. But I haven't even tried to do that yet. To get 1.1.1's GUI running, just launch the toolbox daemon in the background from the single-user shell# /etc/toolboxdaemon &

Then you can run mac GUI apps, e.g.# term

Regarding A/UX filesystem fragility, A/UX 1, 2 and 3 will all automatically run fsck on their root images if you boot into verbose mode. You can set "verbose mode" in Shoebill's preferences. That way, if you bork the root image, you can *usually* still boot it and have fsck run. Sometimes it's so corrupted that it can't even boot enough to load fsck, but usually it works. 3.0.0 seems especially resilient in that regard.

Yeah, 256MB seems to be the maximum A/UX 3.0.0 can handle. A/UX 2.0.0 seems to support all the way up to 1GB, the maximum supported by the 68k Mac architecture, albeit with lots of complaining.

I think I recall this being kind of an issue back in the day too... Like I had to install with 32 or 64 then update, then I could run properly with 192 or whatever it was I had...

pruten wrote:

I've mostly had luck so far with ISOs on 3.0.0. 2.0.0 takes exception to the partition scheme on a lot of CD images (I think). Which ISOs aren't mounting for you? I could take a look at them if they're publicly available. Might be related to different sector sizes on cd-roms vs. hard disks...

Yeah, 256MB seems to be the maximum A/UX 3.0.0 can handle. A/UX 2.0.0 seems to support all the way up to 1GB, the maximum supported by the 68k Mac architecture, albeit with lots of complaining.

I think I recall this being kind of an issue back in the day too... Like I had to install with 32 or 64 then update, then I could run properly with 192 or whatever it was I had...

pruten wrote:

I've mostly had luck so far with ISOs on 3.0.0. 2.0.0 takes exception to the partition scheme on a lot of CD images (I think). Which ISOs aren't mounting for you? I could take a look at them if they're publicly available. Might be related to different sector sizes on cd-roms vs. hard disks...

I built Shoebill succesfully on OSX 10.9.2, but it seems I can't boot into the desktop with AUX 3.0.0. It always throws me back into single user mode. When I disable verbose boot, I see the Welcome to A/UX. Launching... message. Cd image seems OK as I get: /dev/dsk/c0d0s0: filesystem state OKThis with memory: 32Mb; screen: 800x600

No such problems with A/UX 2.0

Is this a simple user error?

I should also mention that I haven't been able to mount any additional CD images or HFS hard disk images (created and formatted with Basilisk)

btw: the shoebill website mentions getting the unix kernel file. An easy way to get the file is by mounting the iso inside a linux virtual machine. I have been succesfull with Zorin in Virtualbox.

I should also mention that I haven't been able to mount any additional CD images or HFS hard disk images (created and formatted with Basilisk)

It's my understanding that HFS volumes aren't enough, they have to be partitioned disk images... which has been my stumbling block there, as I can't get anything to run in BasiliskII to partition a disk, as they say nothing is connected to the SCSI bus......

Is it possible you're booting a 3.x.x kernel with a 2.0.x root image, or 2.0.x kernel with the 3.x.x image? I've done that accidentally several times, and the symptom is that it boots a little, then fails and dumps you into the single-user shell.

I was accidentally running a 3.0.1 kernel with a 3.0.0 image and struggled for a long time to figure out why the Finder wouldn't start.

Regarding HFS images - I did manage to make one using Basilisk II a while ago ("Dogcow" in the screenshots). IIRC, I think maybe I used Disk Utility to partition my blank image with an apple partition map, and then had System 7 in BII format the partition. I understand the apple partition map scheme much better these days, so it's possible that a future release of Shoebill could *automagically* wrap raw HFS volumes in a virtual partition map, so that A/UX can recognize them.

Also, it's super interesting that Linux can mount BSD 4.3 UFS volumes! I wrote a stripped down implementation of UFS/SVFS for reading kernel files (core/filesystem.c), and in trying to figure out the A/UX's UFS implementation, discovered that there's extremely wide variety in the on-disk data structures for UFS across OSes.

Yes, that was my problem.The 3.0 iso, once mounted in Linux, shows three partititions, two of which contain several files named unix, newunix, nextunix . I just copied one of the incorrect ones into OSX

After creation I changed the extension to .img and booted basilisk with the image. Then formatted the disk image and attached it to Shoebill. After numerous disk errors which were fixed by fsck in verbose startup, the image appeared on the desktop. I was able to install A/UX on the image but was not able to boot from it, as it seems the root file system is missing.Trying to run Apple HD SC Setup crashes Shoebill

After creation I changed the extension to .img and booted basilisk with the image. Then formatted the disk image and attached it to Shoebill. After numerous disk errors which were fixed by fsck in verbose startup, the image appeared on the desktop. I was able to install A/UX on the image but was not able to boot from it, as it seems the root file system is missing.

It'll probably be a while before you can install A/UX "the right way" via shoebill. Ultimately, I think the installer just partitions your disk and copies the root image from the CD. Penelope used to have instructions for manually copying the root filesystem to a new disk.

Cat_7 wrote:

Trying to run Apple HD SC Setup crashes Shoebill

I think Apple HD SC Setup is using SCSI commands that aren't implemented yet (causing shoebill to assert). There's a command line partitioning tool on A/UX, /bin/dp. It's harder to use, but it can build a partition map that you can boot from. There's no need to create an HFS partition unless you want one, since Shoebill bootstraps A/UX itself and can't even boot regular Mac OS.

If you do create a new root image, be sure to back it up! Shoebill crashes a lot, and fsck can't always repair the filesystem

neozeed wrote:

So I have a simple shell script running in a terminal

while truedo true/usr/games/fortuneuptimesleep 7cleardone

and the clock actually goes BACKWARDS!!!! it starts around 4pm, then goes to 358, then back to 4, then back again to 358....

Ah! System 7 depends on the higher-precision VIA timers, which aren't implemented yet. I'm surprised timers even work at all, and don't just hang forever. Marathon under A/UX 2.0.0 works as expected, but under 3.0.0 it runs, like, 3x faster than normal. I'll get those timers working eventually... I suspect it's the cause of a lot of weird problems on 3.0.0.

I just added it directly to Shoebill, and booted up. A/UX says the disk uses a newer filesystem that it cannot read, and wants to initialize the disk. I hit cancel as I don't want the disk to be mounted.

Next bring up a command shell, and using DP we will examine the disk, delete the HFS partition, and then create a UFS partition.