Qemu-system-m68k for macOS to run AUX 3.x
Moderators: Cat_7, Ronald P. Regensburg
Qemu-system-m68k for macOS to run AUX 3.x
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
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
Re: Qemu-system-m68k for macOS to run AUX 3.x
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! 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?
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! 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?
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.
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.
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
) &
Re: Qemu-system-m68k for macOS to run AUX 3.x
Hi,
Unfortunately I don't have a M1 machine available. Someone else would have to chime in.
Best,
Cat_7
Unfortunately I don't have a M1 machine available. Someone else would have to chime in.
Best,
Cat_7
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.
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.
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
Last edited by SolraBizna on Mon Sep 27, 2021 2:12 am, edited 1 time in total.
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.
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.
Re: Qemu-system-m68k for macOS to run AUX 3.x
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?
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?
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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:
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:
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. )
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:
- Fulfilling my childhood dream of running the mysterious A/UX. Seriously, this must be what it would feel like to capture a living unicorn.
- 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 )
Re: Qemu-system-m68k for macOS to run AUX 3.x
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: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:
(Except for the first item, limiting speed and/or switching to the x86_64 build don't have any effect.)
- 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. )
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:
- Fulfilling my childhood dream of running the mysterious A/UX. Seriously, this must be what it would feel like to capture a living unicorn.
- 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 )
- 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.
- 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...
- 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:
Anyhow thank you for the feedback, and glad that the patches give you so much enjoyment
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.mcayland wrote: ↑Sun Oct 03, 2021 5:06 pmCurrently 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.
- 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.
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.
I was thinking along those lines as well.mcayland wrote: ↑Sun Oct 03, 2021 5:06 pmI 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?
- 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...
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.
Interesting indeed. I'll investigate this further, if I can find the time.mcayland wrote: ↑Sun Oct 03, 2021 5:06 pmThis 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
- 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.
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 pmThat 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.
- 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:
Thank you for your hard work!
- adespoton
- Forum All-Star
- Posts: 4229
- Joined: Fri Nov 27, 2009 5:11 am
- Location: Emaculation.com
- Contact:
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.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.
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.
-
- Space Cadet
- Posts: 2
- Joined: Tue Aug 18, 2020 6:54 pm
Re: Qemu-system-m68k for macOS to run AUX 3.x
I'm always getting this error during booting AUX 3.0.1:"no via interrupt handler:via @ 50002000.ifr mask=90"
Re: Qemu-system-m68k for macOS to run AUX 3.x
Hi,
Unfortunately that can´t be helped right now, it caused by some timing issue.
Best,
Cat_7
Unfortunately that can´t be helped right now, it caused by some timing issue.
Best,
Cat_7
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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:
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.
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.
- 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...
- Boot up A/UX, log in, etc.
- Start ClarisWorks.
- New spreadsheet.
- Type in a number.
- Set that cell to format as a percentage.
- Copy the cell.
- Try to paste. Session crashes.
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.
Re: Qemu-system-m68k for macOS to run AUX 3.x
Hi,
From which branch did you compile?
Best,
Cat_7
From which branch did you compile?
Best,
Cat_7
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
q800.upstream3
Re: Qemu-system-m68k for macOS to run AUX 3.x
Hi,
q800.upstream2 contains the latest code.
One clear issue: Virtual Memory cannot be enabled for Mac OS guests.
Best,
Cat_7
q800.upstream2 contains the latest code.
One clear issue: Virtual Memory cannot be enabled for Mac OS guests.
Best,
Cat_7
- SolraBizna
- Inquisitive Elf
- Posts: 32
- Joined: Mon Sep 27, 2021 1:39 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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.)
And yet A/UX, with its much more extensive use of the MMU, works...
Re: Qemu-system-m68k for macOS to run AUX 3.x
Yes, the mmu seems OK, but VM uses the disk to store/swap memory. Investigation into the cause is underway.
Best,
Cat_7
Best,
Cat_7
-
- Forum All-Star
- Posts: 1706
- Joined: Tue Oct 14, 2008 12:12 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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....
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....
-
- Forum All-Star
- Posts: 1706
- Joined: Tue Oct 14, 2008 12:12 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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?
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?
Re: Qemu-system-m68k for macOS to run AUX 3.x
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
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
-
- Forum All-Star
- Posts: 1706
- Joined: Tue Oct 14, 2008 12:12 am
Re: Qemu-system-m68k for macOS to run AUX 3.x
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?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
The Monitors Control Panel lets me set colors, not screen size. The Options button doesn't lead to anything useful: