Qemu-system-m68k for macOS to run AUX 3.x

About Qemu-system-m68k, a m68k Mac emulator for Windows, macOS and Linux that can run MacOS 7.1 to 8.1, AUX 3.x and NetBSD

Moderators: Cat_7, Ronald P. Regensburg

User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Thanks to the awesome work by some of the Qemu developers you can now run AUX 3.x with Qemu, emulating a Quadra 800 machine:

note: downloads removed, see forum topic viewtopic.php?t=11728

Download an experimental, alpha build for macOS hosts here:
Guide: https://www.emaculation.com/doku.php/m68k-qemu-on-osx

Best,
Cat_7
thecloud
Student Driver
Posts: 19
Joined: Mon Oct 19, 2015 4:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by thecloud »

Thanks for all your work and documentation! Using the linked qemu-system-m68k-AUX-alpha build and sample config, I was able to boot and run A/UX 3.1.1 from an image I'd previously made. Networking was functional by default and after configuring my host address to 10.0.2.15, gateway to 10.0.2.2, and nameserver to 10.0.2.3, I could ping Google, ssh to other (ssh1-capable) boxes, and everything worked. Great!

But I noticed your binary was built for x86_64, so I set about trying to build a native arm64 binary, following the instructions here: viewtopic.php?p=71794#p71794. I cloned the mcayland repo, made sure I was on the q800.upstream branch, and reverted the last commit (the one with the WIP: revert AUX comment from Wed Aug 11.) Then ./configure --target-list=m68k-softmmu, omitting GTK and SDL because Cocoa is the default on macOS, and finally make.

The resulting qemu-system-m68k binary runs noticeably faster on Apple Silicon than the x86_64 version, with one problem: A/UX can't use the network! :cry: It's as if my qemu was built without networking enabled, though the configure output claims to be using internal slirp support. A comparison of the two binaries with otool -L shows different versions of various dylibs are in use, so that may be part of the issue.

Has anyone else been successful in building this branch for arm64?
thecloud
Student Driver
Posts: 19
Joined: Mon Oct 19, 2015 4:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by thecloud »

When running Cat_7's x86_64 build, the A/UX System Console reports the Ethernet MAC address at the very end, and ifconfig ao0 shows it has the IP address 10.0.2.15. That's all as it should be. However, running my arm64 build, no Ethernet MAC address is reported in the console, and the interface doesn't come up. Since it's the same image with the same configuration in both cases, that suggests my qemu build is missing something that is needed to emulate the network interface, but haven't been able to figure out what yet.
Image
Here's the script I use, with some extra osascript sauce that pulls the QEMU window to the front when executed; I got tired of having to bring it to the front manually every time.

Code: Select all

(
BUILD="/Volumes/Data/src/qemu-mcayland/build"
QEMU="qemu-system-m68k"

"$BUILD"/"$QEMU" \
-L pc-bios \
-m 128 \
-M q800 \
-serial stdio \
-bios Quadra800.rom \
-g 800x600x8 \
-net nic,model=dp83932 -net user \
-drive file=pram-macos.img,format=raw,if=mtd \
-device scsi-hd,scsi-id=1,drive=hd0,vendor="SEAGATE",product="ST225N",ver="1.0" \
-drive file=AUX.dmg,media=disk,format=raw,if=none,id=hd0 \
&
QPID="$!"
echo "Started QEMU with pid $QPID"

# alternate monitor size
# -g 1152x870x8 \

osascript<<EOF
tell application "System Events"
    set processList to every process whose unix id is ${QPID}
    repeat with proc in processList
        set the frontmost of proc to true
    end repeat
end tell
EOF
) &
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Hi,

Unfortunately I don't have a M1 machine available. Someone else would have to chime in.

Best,
Cat_7
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

I built a version from the repo, more or less the same way you did, for running on my M1 MacBook Air. It worked fine. I don't know if it's related, but I did have to add the commands to bring up my interface to "/etc/rc", since setting it up in newconfig didn't seem to work. It may be worth trying.

Code: Select all

/etc/ifconfig ao0 10.0.2.15 netmask 255.255.255.0
/usr/etc/route add default 10.0.2.2 1
Edit: I just checked, and I do see a MAC address for the interface in the A/UX System Console. So my "hack" probably won't help you.
Last edited by SolraBizna on Mon Sep 27, 2021 2:12 am, edited 1 time in total.
thecloud
Student Driver
Posts: 19
Joined: Mon Oct 19, 2015 4:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by thecloud »

Yes, that did it! Thank you! I double-checked my /etc/rc file, and while it included the command to add the default route, it did not explicitly call ifconfig first. After adding the ifconfig line and rebooting, networking was functional on my arm64 build! Good to confirm that it actually does work natively on M1.

But I'm still scratching my head over why the ao0 interface is able to come up without that explicit ifconfig line when I run Cat_7's x86_64 build. A/UX is normally supposed to read the contents of /etc/NETADDRS when it runs /etc/startup, which in turn should execute /etc/startup.d/ao, which calls ifconfig. There might be some timing issue, since I notice the "Loading..." dialog goes away much faster at startup with arm64. Will keep looking.
thecloud
Student Driver
Posts: 19
Joined: Mon Oct 19, 2015 4:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by thecloud »

This actually does seem to be a timing issue. When the arm64 build runs at full speed, part of the init process appears to be short-circuited. However, if I use the Speed menu in the qemu-system-68k GUI to reduce the emulation speed to 70% or less before the "Loading..." dialog appears, then the network initializes correctly and no additional call to ifconfig is required.

One obvious indication of the problem is that the GUI progress dialog, which is normally updated by calls to /etc/startmsg, never gets to phase 4 where it says "Launching..." rather than "Loading...". It just goes away when the screen clears to gray (i.e. at the point where /etc/init gets control) and doesn't come back. Running at a slower rate fixes that.

I added some basic logging in /etc/sysinitrc, after it mounts the root filesystem but before calling /etc/startup to initialize networking. My log entries are present when run at slower speeds but not at full speed, where it looks like /etc/startup isn't getting called at all.

Anyway, the workaround for this issue seems to be "slow down the emulation until it works." But I can't find QEMU's Speed menu documented anywhere! Is there a way to specify the emulator speed when invoking QEMU from a script?
thecloud
Student Driver
Posts: 19
Joined: Mon Oct 19, 2015 4:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by thecloud »

thecloud wrote: Sat Oct 02, 2021 10:08 pm Anyway, the workaround for this issue seems to be "slow down the emulation until it works." But I can't find QEMU's Speed menu documented anywhere! Is there a way to specify the emulator speed when invoking QEMU from a script?
Following up, it looks like the cpu-throttle module was added relatively recently in QEMU and apparently is more of a Monitor feature than an attribute of the virtual machine. The Speed menu in the Cocoa UI is one of the few places it's actually used.
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

I wonder what other casualties there might be of the "truncated startup"—and whether it occurs on any very fast host, or just on ARM64 ones. I do know that there are some timing-related startup problems with Windows builds too. Well, given how hardware-specific and ancient A/UX is, I'm amazed that it works this well!

Other problems I've had:
  • Badly corrupted graphics during the last stage of the startup process. Looks like a wrong bit depth is in use. This problem is only present in my ARM64 build running at full speed; when running the build at the top of this thread I don't hit the problem, and limiting the speed before A/UX loads avoids the problem.
  • Corrupted graphics when returning from "startmac" to the Console Emulator. Looks like wrong bit depth and overwritten VRAM. Typing "exit" gets me safely back to the login screen, typing "startmac" gets me a new working Mac session. I suspect this is a genuine A/UX bug. My Mac session runs in Millions of Colors, which no real Quadra 800 running A/UX could do, so maybe it's a bit depth switching issue... except my Login system also runs in Millions and I don't get corruption going from that to Console Emulator...
  • Display doesn't update properly if a program updates the gamma ramp without actually touching any pixels. An easy way to see this is to run Marathon 2, which uses the gamma ramps for fades.
  • Glitchy, awful sound. Sound works perfectly in Mac OS 8.1, and indeed in the Mac environment that A/UX bootstraps from, so this is something A/UX specific.
  • Some kind of math bug. Maybe to do with signed integer division with very large dividends? I think these examples are all the same underlying bug:
    • ping under A/UX always reports very large pings, on the order of billions of milliseconds. Sometimes this value is negative, sometimes positive.
    • Marathon 2: It's impossible to face any direction other than roughly eastward. It's impossible to induce any motion except to the east. Many polygons that should be visible are glitchy, mangled, or invisible, especially to the player's left. The AI is extremely broken. The arrow representing the player in the map view is mangled. The game usually crashes pretty quickly.
    • Ophiuchus: It's impossible to face any direction except upward, aiming rightward. It's impossible to move in any direction other than right, which results in a pointless sliding motion along the launchpad. (It's very difficult to stomach the graphics, but that's not actually a bug in QEMU. :) )
(Except for the first item, limiting speed and/or switching to the x86_64 build don't have any effect.)

I'm not sure where the best avenue for reporting and tracking these bugs is, so it all gets to be splatted into this thread for now, I guess. Even though some of these bugs aren't A/UX specific.

In any event, meanwhile, I'm quite happily able to use A/UX running in QEMU to accomplish two extremely important goals:
  1. Fulfilling my childhood dream of running the mysterious A/UX. Seriously, this must be what it would feel like to capture a living unicorn.
  2. Running WriteNow and ClarisWorks, working on files transparently stored on the host machine, with minimal idle CPU usage. (Yeah, extremely specific use case, I know. :D )
mcayland
Mac Mechanic
Posts: 152
Joined: Sun Nov 01, 2015 10:33 pm

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by mcayland »

SolraBizna wrote: Sun Oct 03, 2021 8:52 am I wonder what other casualties there might be of the "truncated startup"—and whether it occurs on any very fast host, or just on ARM64 ones. I do know that there are some timing-related startup problems with Windows builds too. Well, given how hardware-specific and ancient A/UX is, I'm amazed that it works this well!

Other problems I've had:
  • Badly corrupted graphics during the last stage of the startup process. Looks like a wrong bit depth is in use. This problem is only present in my ARM64 build running at full speed; when running the build at the top of this thread I don't hit the problem, and limiting the speed before A/UX loads avoids the problem.
  • Corrupted graphics when returning from "startmac" to the Console Emulator. Looks like wrong bit depth and overwritten VRAM. Typing "exit" gets me safely back to the login screen, typing "startmac" gets me a new working Mac session. I suspect this is a genuine A/UX bug. My Mac session runs in Millions of Colors, which no real Quadra 800 running A/UX could do, so maybe it's a bit depth switching issue... except my Login system also runs in Millions and I don't get corruption going from that to Console Emulator...
  • Display doesn't update properly if a program updates the gamma ramp without actually touching any pixels. An easy way to see this is to run Marathon 2, which uses the gamma ramps for fades.
  • Glitchy, awful sound. Sound works perfectly in Mac OS 8.1, and indeed in the Mac environment that A/UX bootstraps from, so this is something A/UX specific.
  • Some kind of math bug. Maybe to do with signed integer division with very large dividends? I think these examples are all the same underlying bug:
    • ping under A/UX always reports very large pings, on the order of billions of milliseconds. Sometimes this value is negative, sometimes positive.
    • Marathon 2: It's impossible to face any direction other than roughly eastward. It's impossible to induce any motion except to the east. Many polygons that should be visible are glitchy, mangled, or invisible, especially to the player's left. The AI is extremely broken. The arrow representing the player in the map view is mangled. The game usually crashes pretty quickly.
    • Ophiuchus: It's impossible to face any direction except upward, aiming rightward. It's impossible to move in any direction other than right, which results in a pointless sliding motion along the launchpad. (It's very difficult to stomach the graphics, but that's not actually a bug in QEMU. :) )
(Except for the first item, limiting speed and/or switching to the x86_64 build don't have any effect.)

I'm not sure where the best avenue for reporting and tracking these bugs is, so it all gets to be splatted into this thread for now, I guess. Even though some of these bugs aren't A/UX specific.

In any event, meanwhile, I'm quite happily able to use A/UX running in QEMU to accomplish two extremely important goals:
  1. Fulfilling my childhood dream of running the mysterious A/UX. Seriously, this must be what it would feel like to capture a living unicorn.
  2. Running WriteNow and ClarisWorks, working on files transparently stored on the host machine, with minimal idle CPU usage. (Yeah, extremely specific use case, I know. :D )
As the author of the QEMU patches for running MacOS and A/UX on QEMU, all feedback such as this is really useful. Regarding timing issues I wonder if the M1 is so fast that the timer calibration values injected by QEMU need to be increased? I'll also try and address the issues you mentioned:
  • Display doesn't update properly if a program updates the gamma ramp without actually touching any pixels. An easy way to see this is to run Marathon 2, which uses the gamma ramps for fades.
Currently QEMU will force a display refresh for every RGB tuple written to the palette registers, and the gamma registers are currently implemented/untouched (as on most emulators). If you run with -trace 'macfb*' on the command line you should be able to see which registers are being used for the color effects.
  • Corrupted graphics when returning from "startmac" to the Console Emulator. Looks like wrong bit depth and overwritten VRAM. Typing "exit" gets me safely back to the login screen, typing "startmac" gets me a new working Mac session. I suspect this is a genuine A/UX bug. My Mac session runs in Millions of Colors, which no real Quadra 800 running A/UX could do, so maybe it's a bit depth switching issue... except my Login system also runs in Millions and I don't get corruption going from that to Console Emulator...
I believe Apple limited the video RAM on the Quadra 800 to 1MB so that it was impossible to get the maximum color depth/resolution. QEMU allocates the full 2MB so it may be that given this can't occur on a real machine which is why there are issues here?
  • Glitchy, awful sound. Sound works perfectly in Mac OS 8.1, and indeed in the Mac environment that A/UX bootstraps from, so this is something A/UX specific.
This is an interesting one. The EASC has 2 FIFOs, one for each channel, but A/UX only ever seems to write to the R channel FIFO meaning there is junk on the L channel. Any help reverse engineering EASC would be gratefully received :)
  • Some kind of math bug. Maybe to do with signed integer division with very large dividends? I think these examples are all the same underlying bug:
That is entirely likely. If you have a Linux m68k gdb then you can use the stub file at https://github.com/mcayland/qemu-m68k-m ... 800ROM.elf to step through the toolbox ROM to find a reproducer. See the README.md file in that directory for more detail.

Anyhow thank you for the feedback, and glad that the patches give you so much enjoyment :)
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

mcayland wrote: Sun Oct 03, 2021 5:06 pm
  • Display doesn't update properly if a program updates the gamma ramp without actually touching any pixels. An easy way to see this is to run Marathon 2, which uses the gamma ramps for fades.
Currently QEMU will force a display refresh for every RGB tuple written to the palette registers, and the gamma registers are currently implemented/untouched (as on most emulators). If you run with -trace 'macfb*' on the command line you should be able to see which registers are being used for the color effects.
I assumed the game was operating in Millions, but on a 68040 it apparently won't try to use Millions, which means it'd be using the palette to implement its fades. I had to grep away the churn of reads from 0x108 and writes to 0x10C, but when I do, all I see are bytes being written to 0x213 (DAFB_LUT) during the fade. If I'm reading the macfb source correctly, this writes to the palette. So either it's not actually forcing a refresh every time the palette is changed, or something else must be going wrong. I don't see any other writes or reads during the fades.

Possibly of interest, the "Marathon 2" logo on startup has a corrupted (shuffled?) palette when I test it under A/UX, but not under Mac OS 8.1. Hard to tell if that's a problem with QEMU or with A/UX. I don't think many people would have tried running Marathon 2 on their A/UX machines. The experience on real hardware would not have been good. :)
mcayland wrote: Sun Oct 03, 2021 5:06 pm
  • Corrupted graphics when returning from "startmac" to the Console Emulator. Looks like wrong bit depth and overwritten VRAM. Typing "exit" gets me safely back to the login screen, typing "startmac" gets me a new working Mac session. I suspect this is a genuine A/UX bug. My Mac session runs in Millions of Colors, which no real Quadra 800 running A/UX could do, so maybe it's a bit depth switching issue... except my Login system also runs in Millions and I don't get corruption going from that to Console Emulator...
I believe Apple limited the video RAM on the Quadra 800 to 1MB so that it was impossible to get the maximum color depth/resolution. QEMU allocates the full 2MB so it may be that given this can't occur on a real machine which is why there are issues here?
I was thinking along those lines as well.

Some Internet sources say that the Quadra 800 could never do Millions, at any resolution, even with a separate video card installed. No idea how true that really is.
mcayland wrote: Sun Oct 03, 2021 5:06 pm
  • Glitchy, awful sound. Sound works perfectly in Mac OS 8.1, and indeed in the Mac environment that A/UX bootstraps from, so this is something A/UX specific.
This is an interesting one. The EASC has 2 FIFOs, one for each channel, but A/UX only ever seems to write to the R channel FIFO meaning there is junk on the L channel. Any help reverse engineering EASC would be gratefully received :)
Interesting indeed. I'll investigate this further, if I can find the time.
mcayland wrote: Sun Oct 03, 2021 5:06 pm
  • Some kind of math bug. Maybe to do with signed integer division with very large dividends? I think these examples are all the same underlying bug:
That is entirely likely. If you have a Linux m68k gdb then you can use the stub file at https://github.com/mcayland/qemu-m68k-m ... 800ROM.elf to step through the toolbox ROM to find a reproducer. See the README.md file in that directory for more detail.
I think it's just a buggy DIV* or MUL* instruction, in which case, once I get around to it, it shouldn't take long for me to write a simple test program reproducing the problem without the toolbox's involvement. If it proves to be more complicated than that, those symbols will be invaluable. Either way, I have a real Macintosh LC III I can use to double-check my assumptions.
mcayland wrote: Sun Oct 03, 2021 5:06 pm Anyhow thank you for the feedback, and glad that the patches give you so much enjoyment :)
Thank you for your hard work!
User avatar
adespoton
Forum All-Star
Posts: 4226
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by adespoton »

mcayland wrote: Sun Oct 03, 2021 5:06 pm Currently QEMU will force a display refresh for every RGB tuple written to the palette registers, and the gamma registers are currently implemented/untouched (as on most emulators). If you run with -trace 'macfb*' on the command line you should be able to see which registers are being used for the color effects.
This got me thinking: how difficult would it be to map the gamma value to an alpha channel value with a black foreground? Seems like it should be doable using SDL, anyway. Probably more complicated if done correctly, with the engine providing gamma value hooks linked to a display processor routine for whatever graphics front end is being used.
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

All the systems that I know of that implement gamma LUTs implement separate ones for all three channels. It would be possible to implement gamma ramps in a fragment shader, but I don't believe QEMU has the necessary plumbing to use fragment shaders.
daemonspudguy
Space Cadet
Posts: 2
Joined: Tue Aug 18, 2020 6:54 pm

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by daemonspudguy »

I'm always getting this error during booting AUX 3.0.1:"no via interrupt handler:via @ 50002000.ifr mask=90"
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Hi,

Unfortunately that can´t be helped right now, it caused by some timing issue.

Best,
Cat_7
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

Tried the newest(?) code, immediately appreciated that I no longer need separate builds for A/UX and MacOS 8.

Following up on my earlier reports:
  • System beeps, and WriteNow's "clicks", now sound perfect on A/UX.
  • Still getting the corrupted graphics when exiting "startmac" onto a console session. Still think it's a "real" A/UX bug.
  • Still need to slow the system down in order to avoid the corrupted graphics during startup. My workaround for the truncated startup is still in place so I'm not sure if the other startup timing issues are still happening.
  • Marathon 2 palette effects work almost perfectly now. After it finishes fading in, the intro graphic has the wrong palette, but during both fade-in and fade-out it's correct, and the main menu itself is correct. Since this problem only shows up under A/UX, I'm inclined to think this is a bug in A/UX's QuickDraw, and not in the video emulation.
  • Weird math bug still there. Still haven't gotten around to investigating it deeply.
I experimented some more with sound:
  • Playing a high-quality (stereo, 44.1kHz) System 7 Sound from Finder or ResEdit gets very wrong results, seemingly the correct sound data but being interpreted in the wrong sample format and/or rate.
  • Trying to use QuickTime 2.0 to play an AIFF at the same quality seems to play random memory for a while (including my current system beep) and then hit a kernel panic(!!). Note that I have no particular reason to think QuickTime 2.0 should work under A/UX.
  • Both test files play perfectly on OS8. Full quality, no pops. So the sound hardware can do it...
In the current state, there are no bugs that affect me during day-to-day use. Well, except this weird one:
  1. Boot up A/UX, log in, etc.
  2. Start ClarisWorks.
  3. New spreadsheet.
  4. Type in a number.
  5. Set that cell to format as a percentage.
  6. Copy the cell.
  7. Try to paste. Session crashes.
If I try to log in after that, the new session throws some scary disk-related messages and then A/UX eats itself horribly. I definitely wasn't expecting such a serious crash from such an innocent source, but it reproduces reliably. Maybe it's related to the "weird math bug"? Maybe it's a "real" bug being emulated correctly? (In any event, I've simply stopped formatting cells as percentages.)

Oh, and while I do have MacsBug installed and working under A/UX, it won't read the keyboard, which means I have to hit command-control-E to exit the session if it actually comes up. MacsBug under OS8 works great, but its key repeat rate is completely unhinged, because a modern CPU is so much faster than any real 68040…

…Uh, anyway, thank you again for keeping up the work.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Hi,

From which branch did you compile?

Best,
Cat_7
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

q800.upstream3
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Hi,

q800.upstream2 contains the latest code.
One clear issue: Virtual Memory cannot be enabled for Mac OS guests.

Best,
Cat_7
User avatar
SolraBizna
Inquisitive Elf
Posts: 32
Joined: Mon Sep 27, 2021 1:39 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by SolraBizna »

Cat_7 wrote: Wed Aug 17, 2022 7:29 am q800.upstream2 contains the latest code.
Surprising, but true

I tested everything I mentioned in my last post with that slightly newer code, no change. (I didn't test the ClarisWorks spreadsheet thing though.)
Cat_7 wrote: Wed Aug 17, 2022 7:29 am One clear issue: Virtual Memory cannot be enabled for Mac OS guests.
And yet A/UX, with its much more extensive use of the MMU, works...
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Yes, the mmu seems OK, but VM uses the disk to store/swap memory. Investigation into the cause is underway.

Best,
Cat_7
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by emendelson »

Probably my problems are the result of incompetence, but I'm having no luck getting Qumu to run A/UX on an M1 Mac running Ventura.

I started out by having trouble with what seem to be a few typos in the guide:

https://www.emaculation.com/doku.php/m6 ... s_in_macos

The two commands to create disk images need ./ in front of "qemu-img" and the third line of the command line that follows should start with ./ and end with /. I think the wiki should also say to run chmod +x on the command file.

I have AUX301.img (2.16GB) and AUX301.iso (426.3 MB ) in the folder. I've locked the .iso file, though the wiki doesn't say to do this (I think).

When I run the command, the startup sound plays, but then nothing happens on screen, and eventually I shut down the command with Ctrl-C.

EDIT: I found the post that says that the -display option is now needed. I was able to use -display cocoa, and the system started up....
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by emendelson »

Further information for anyone who wants to run A/UX under Qemu in macOS as described in the wiki entry.

I wasn't able to install the TuneUp using the method described in the wiki. Instead of I made a copy of the boot image disk image that included the TuneUp installer, mounted the image in SheepShaver running Mac OS 9, and deleted everything on the disk image that was NOT the TuneUp. I then added this disk to the command line and installed the TuneUp.

Question: I could not get 800x600 to work as a screen size - the OS always opened in 640x480. But 1152x870x8 worked perfectly. Is there any way to get 800x600 to work?
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by Cat_7 »

Thanks for the feedback on the A/UX guide.
I fixed the issues you mentioned.

Do you know why you were not able to use the floppy disk image (it is actually a small hard disk image) to install the tune-up? Did you have a scsi/boot disk issue?

To set the screen resolution after the initial -g on the command line, you use the System 7 monitors control panel.
See the note on resolutions in the part of the guide on System 7/8

Best,
Cat_7
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Qemu-system-m68k for macOS to run AUX 3.x

Post by emendelson »

Cat_7 wrote: Sun Aug 06, 2023 4:27 am Do you know why you were not able to use the floppy disk image (it is actually a small hard disk image) to install the tune-up? Did you have a scsi/boot disk issue?

To set the screen resolution after the initial -g on the command line, you use the System 7 monitors control panel.
See the note on resolutions in the part of the guide on System 7/8
When I put the floppy image back into the command line, and set it as SCSI 2 so it wouldn't be first in the chain, Qemu booted from it, and complained that it couldn't find a CD to install from. There was no way (that I could see) to find the files. Maybe there's a switch in the command-line that would prevent Qemu from booting from that disk, and I simply don't know where it is?

The Monitors Control Panel lets me set colors, not screen size. The Options button doesn't lead to anything useful:

Image
Post Reply