I’m being a bit unfair as far as Alpha’s go it’s rough to get going but wow it’s GREAT! For starters it’s a Quadra 800 so System 7.1 through 8.1 will work. Also this has full 68040 capabilities so yes that means MMU and YES A/UX (and NetBSD!) will run
As always you can find more on emaculation, the best source for news and info on emulating the Mac.
Additionally you can find the setup guide here.
Many of my Shoebill/Cockatrice III images didn’t work at all. Some at least were picked up as blank disks. I had less luck with freshly created raw/vmdk or qcow2 disks. Not sure at all. My minimal 7 2gb disk worked fine as a donor, and even converting to a vmdk was fine. Sooo YMMV. But hey it’s an Alpha and YES IT CAN WORK.
Another plus is that the idle loop works fine so it won’t burn 100% of your CPU. This could possibly be a great gopher server!? Time will tell.
I wonder what branch they’re using? Would like to build this myself on Linux…
That Qemu build was created from https://github.com/mcayland/qemu/tree/q800.upstream. It will run AUX. To get a binary that can boot and run MacOS revert the latest commit and build again.
Can you share the installed image
That’s awesome! I’ve always loved the concept behind A/UX but I’ve never been able to try it myself (my SE/30 is under-specced)…until now! It turns out to be pretty awesome. (I’ve been testing on macOS using the Cocoa front end.)
The Mac environment in A/UX 3.1.1 is compatible with most things I’ve thrown at it, including Netscape, MS Word, WordPerfect, the famous Aaron platinum extension, and Adobe Type Manager (but not Adobe Acrobat, which fails to install its fonts in the System).
The Unix side is showing its age (my kingdom for pre-configured tab-completion and history!) but is perfectly respectable, albeit quirky, even for the time (I think; it predates my use of Unix systems by a few years). Lots of extras are included. I love how configuring TCP/IP in Unix also makes it available to the Mac environment.
It would have been interesting to see development on A/UX continue.
Thanks for the post, and thanks to those that did the work.
Have you tried using something like hfdisk (https://www.codesrc.com/gitweb/index.cgi?p=hfdisk.git;a=summary) to try to figure out what the difference is between your good and bad disk images?
The UFS is able to mount. Best I could figure is that it’s non blessed system 7, and it being 3.0.0 which won’t run on a Quadra 800.
I already did a dump/restore onto bigger disks so it’s kind of too late now. At least the partition tables and UFS was fine, I can always reinstall Soft PC.
How did you started a telnet server? Please tell me how!
I was pretty sure it was on by default? If not check /etc/inetd.conf ? or something like that.
I have observed that simply running the Quadra 800 ROM on qemu-system-m68k on GNU/Linux, the qemu process uses 100% of the CPU. Is it because the Mac Quadra 800 ROM and / or the OS uses a “tight loop” as an idle loop, which translates as a constant 100% CPU usage on the host machine?
Is there a way to prevent that (an OS/ROM patch of some kind), or is A/UX the only way to run Mac 68K apps on qemu-system-m68k without that constant 100% CPU usage?
Also, do Mac 68k games run on A/UX?
I am asking all this here because it’s the only place I could find where the idle loop problem with Quadra 800 emulation on QEMU is mentioned…
fundamentally the 68000 has no ‘idle’ instruction to catch so it’d require profiling like dynamips, or the injection of an illegal instruction from a task with the lowest priority.
As far as games go , I mostly like SimCity on MacOS. I’m sure plenty of others run though!
Many thanks for your answer, really. There isn’t much info around this anywhere.
So, just to be sure, running Quadra 800 + System 7/8 on qemu-system-m68k AND seeing that 100% CPU usage is expected, right?
I mean, the only current way around it would be running the A/UX on the Quadra 800 emulation, is that correct?
Yes it is expected behavior. I guess if you are using Linux you can try to renice it to a lower priority, or set the affinity and priority on Windows task manager.
68000s like other processors before them really didn’t have anything mobile in mind. You see the same thing with MIPS or other processors. It’s a pitty it doesn’t have a cycles per second cap like BOCHS or 86Box
Yes, I am indeed using GNU/Linux, so I will try changing the process niceness.
Please let me do another question, since you are giving me the answers I have been searching online for a long time:
Lemmings on the Quadra 800 under qemu-system-m68k has audio problems if I force vsync on the host (by passing SDL_RENDERER_PRESENTVSYNC to the SDL_CreateRenderer() call in QEMU).
That happens even if I set a 66.662467 Hz physical video mode on the host, which is what the Mac II originally used.
That leads me to think that old Mac games expect asynchronous video refresh, ie: not waiting for vblank, using internal timers instead to keep an adequate framerate (but full of tearing in scroll sequences).
Am I right? Or is Lemmings for example expected to move smoothly on a real Mac II? How do games manage the fact that after the first Mac II there where a plethora of VGA video modes available they would run on?
A lot of things back then were tied to timings you’d expect on real hardware, and I wouldn’t be surprised at all if some things are totally screwed up with a substantially faster cpu/video/ram/disk access. I’m afraid all I can say is that you are best making single changes, and measuring/observing what is going on, and seeing what if any changes make an impact. Many people make LOTS of changes all at once, and have no idea if or what did anything, so I do one at a time, but make more extreme variations, no need to start single stepping!
Which Simcity for MacOS? Can you indicate me which version is it (i.e. website describing it and how to download it)
I use version 1.2! As it runs fine under 68k mode, and on my PowerMac as well!
A quick search shows me, it’s still on Macintosh Garden!
But is it the same of windows version, for curiosity?
No idea I only play on MacOS classic.