No luck with QEMU on Arm64



Welcome, Guest \| Home \| Search \| Login \| Register


Author	No luck with QEMU on Arm64 (Read 19667 times)
68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	on: May 31, 2022, 23:32 I got tired tweaking Basilisk-II all the time and tried my luck with Qemu. Unfortunately that won't even compile on Debian Arm64 - and gives me tons of error messages instead about tons of missing header files. I surely appreciate the hard work of the Mac-Qemu developers. But combined with the hit-and-miss situation of new B-II builds it appears to me that the current state of affairs for Mac emulation is questionable at best. Why can't this be a more streamlined and group based effort rather than this troublesome undertaking of single minded individuals?

wove 1024 MB Posts: 1363	Reply #1 on: June 01, 2022, 01:36 I am not sure this will be helpful. UTM was created as an emulation program for iOS built on QEMU. It has since been ported over to Mac mostly to run on the new M1 Macs. <https://github.com/utmapp/UTM/releases/tag/v3.2.4> If you scroll to the bottom, you will find that it is available as a .deb package to be installed on Debian on ARM. My Debian on ARM is running NextCloud so I have not had a chance to try it out. There is a community around it and you can find preconfigured VMs for the Classic Mac OS. Might be worth a look. Personally I would be really interested to see if it does work on Debian on ARM as it might spur me on to hunting for another Rasp PI.

68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	Reply #2 on: June 01, 2022, 19:59 I appreciate the hint, but I wanted to emulate a Quadra800 because I got a fully loaded system I can actually work with on 68k. Emulating iOS on Arm Debian gets me an unlicensed iPad at 60-80% speed at best. With next to no support and software that runs on a hit or miss basis. If I wanted an iPad I would just buy one and get the whole nine yards out of it. And btw, if the thing runs in userspace its not really emulating the whole system and if its a system app its "just" porting RISC to RISC here. The 68x was a CISC-CPU and on an Arm host that requires true emulation to work.
Last Edit: June 01, 2022, 20:03 by 68040
wove 1024 MB Posts: 1363	Reply #3 on: June 01, 2022, 22:30 This is a QEMU application originally developed for the iPad, but it is also a .deb package that runs on 64bit debian for ARM. <https://mac.getutm.app/gallery/> This provides a link to community build images that are ready to go for UTM. It might well be in the case of MacOS 9.2 it is emulation a ppc processor. UTM was originally developed for the iPad and was then ported to the M1 Macs, and it is also now ported to Debian running on ARM64 hardware. I have no ARM64 hardware to try it on, but from what I gather it is very much like Virt Manager for Linux.

68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	Reply #4 on: June 02, 2022, 00:19 Virt Manager is just a hypervisor GUI and there are already QEMU packages for Arm Debian in existence. The catch is that up to now they only emulate a ColdFire system for m68k - not a Macintosh.

wove 1024 MB Posts: 1363	Reply #5 on: June 02, 2022, 05:08 I use QEMU with the virtual-manager front end on Fedora. When I select the m68k architecture several machine types are offered one of which is the Quardra 800. I have not sorted out how to get it working with any classic Mac OS though. (Macs need a ROM and I have no clue how one would add that in a qemu setup.) I have not had any luck with OS 9 on PPC architecture, where I have a machine choice of either a Beige G3, or a G4. Although several options of Mac OS X are available in the OS chooser area for PPC. (PPC interesting also offered a Pegasus machine and I thought it might be interesting to emulate Amiga OS or Morph OS.) I think for me emulation is my gaming substitute. Why should I crash and burn killing dragons in a cave, when I can crash and burn trying to create an old obscure emulated world.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #6 on: June 02, 2022, 05:47 I love the nature of this convo.. and I hate that I have absolutely nothing to add to it except that I would love to be able to add QEMU to an ARM computer

Bolkonskij Administrator 1024 MB Posts: 2023	Reply #7 on: June 02, 2022, 06:25 I second cballero. Running System 7 on one of those all-in-one Raspi 4 machines would seem like an interesting thing. And hey, that's coming from Mr. I-love-original-hardware ;-)

galgot 64 MB Posts: 66	Reply #8 on: June 02, 2022, 10:52 Yesterday, downloaded the UTM.deb and tried installing on my R-Pi 3B : sudo dpkg -i UTM.deb Alas it get me : "the architecture of the package (iphoneos-arm) does not match that of the system (armhf)" Strange... why would they do a .deb package for iPhone ? Anyways, thanks for these news. Sure that UTM will eventually come to run on R-Pis. Action Retro did something quite fun with Qemu and a R-PI 3B: https://www.youtube.com/watch?v=wLh7c6KQAT4 Used the same screen as I did btw, I find them harder to find now... I never tried Qemu on my R-Pi, might do, but it seems notably slower than SheepShaver, which itself is slower than BasiliskII. That last one is perfect for a R-Pi in a Classic case. Fast and quite stable. But Qemu or UTM, mmmh I might wait till I get a R-Pi 4. That is when I find one at a reasonable price
Last Edit: June 02, 2022, 11:02 by galgot
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #9 on: June 02, 2022, 14:57 I do have a little Raspberry 3 somewhere.. lol I know I've thought of adding Mac, NES and MAME emulation to it as well as either Plex or another media server mostly for personal music and video libraries. Basilisk should be a fun enough, and with 3D printers these days, it could double as a Mac clone if you're creative to build your own personal, unique Mac case for it if you wanted to really jump in and tinker QEMU seems like the logical solution, it too bad that it's relegated to the Intel and AMD-chip world at least I will have a chance to play with all of that now; I scored me a A-grade 13" refurb, 16GB 512SSD touch-screen convertible W10 laptop w/1.9Ghz Core i7 for $335 shipped so I should be okay with all of my emulation needs.. and then some!! lol

68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	Reply #10 on: June 03, 2022, 14:42 QEMU is not just much more frequently maintained than B-II (where you can almost hear the winds of silence blow through the developer's forum page), but it is a commercial enterprise product by now. Even though people either hate or love it Thus there is drive behind it whereas - may Christian Bauer forgive me - Basilisk-II is rapidly approaching retirement age. My problem with it is the same that many non-Wintel geeks have: New developments are first made for Intel compatible systems and only then ported to other platforms. While I can understand the reasoning behind it, it does push us Arm-boyz to the back of the line - yet again. Yesterday I cloned the source from Github anew. I had to install a ton of dev packages for it to compile, but I did get a working binary out of that exercise - with exactly the same behaviour as before. I copied the shell script to start it directly from the developer's webpage - but he works of an Intel machine. Cat_7 from emaculation tells me to keep hopeful for that stuff to appear in the Debian repos, once it made its way up the chain. He also says they overcame most of the challenges to get MacOS 7/8 up and running (which is a lot more tasking than NetBSD, because of the differenes in the boot process). But I know from B-II that any changes in an independent SW project can take an awful long time to appear in the official repositories.
Last Edit: June 03, 2022, 14:45 by 68040
wove 1024 MB Posts: 1363	Reply #11 on: June 03, 2022, 17:16 You are right Qemu makes it almost trivial to create an Intel based system when running on the real Intel hardware. If you need Win on Linux or Linux on Win it is pretty straight forward. Going to alternatives is not so easy. ARM has a much easier time emulating Intel, than Intel has emulating ARM. Digging into the Wiki Qemu on Intel only supports emulating the Raspberry Pi 2. It does support other ARM boards, but for the PI only Raspberry Pi 2 is supported. Qemu emulates a PPC G3 and Beige G3, but Mac OS support only goes back to OS 9. <https://wiki.qemu.org/Documentation/Platforms/PowerPC> Here is the wiki page on m68k emulation <https://wiki.qemu.org/Documentation/Platforms/m68k> Qemu is a deep rabbit hole for sure. I use Qemu mainly on an Intel machine running Fedora to take a look at interesting new OSes or UIs, just to see if anything interesting is being done.

68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	Reply #12 on: June 03, 2022, 17:53 The reason for these differences lies in the way Qemu is implemented nowadays. Old fashioned progs like Bochs emulate almost the entire PC, which makes them very compatible but also slow and hard to port across platforms. Qemu on the other hand differenciates between full system and userland emulation and it runs on architecture-specific binaries. Meaning, each Qemu target has its own executable (qemu-system-x86, qemu-system-m68k, a.s.o.). And building a binary for emulating x86 on an Intel CPU requires not much more than taking advantage of the Hypervisor abillities already build into the CPU. Modern Intel/AMD chips got support for virtualization already build into their dies and that makes life a whole lot easier for programmers who develop VM software for that platform. Problem is the moment you cross that CPU line you got to start from scratch. No KVM support on Arm and no XEN either. Your binary has to replace microkernel code on a per command basis and RISC CPUs have a lot less to offer here than CISC does. That means supporting Intel guests on an Arm host is more troublesome to program than the other way around.

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #13 on: June 04, 2022, 02:19 Oh wow, so I was truly naive when I thought that a upgraded Chromebook would allow me to bump up from Basilisk II on Android up to QEMU or at least SheepShaver with Crouton, but ended up going in for a shock instead Don't get me wrong, the first time I saw Basilisk II work in Chrome OS I fell off my seat in excitement! (like literally, like 'what the..' lol) My older Basilisk II Android port performs exceptionally well on it, but even with an Intel base, I'd still have to blow Chrome OS off and replace it with Linux. The real good stuff stuff ended-up in the PPC gen. I might venture at testing out an unofficial Chrome OS variant that gives the OS and Android to any Intel machine so maybe I can find a way to make it work, plus I can also try playing with the Android Linux app I got.. Termux I think? So much testing, so little results.. so far

68040 512 MB Posts: 950 68k - thy kingdom come, thy will be done !	Reply #14 on: June 04, 2022, 11:12 The main problem with Basikusk II is that it got no central maintainer. There is 1 dude who develops the main branch - whenever he finds a spare day once or twice a year - and everyone else just grabs himself some of that code and ports his own, until the fun runs out. That is the reason why you got 1000+1 Basilisk derivatives out there by now and they all work somewhat or they don't. You can submit a bug report to the author, but you could just well write a letter to your congressman. Btw, I advise against compiling large projects on Termux (have been using it myself for many years). Opposite to common perception it is not a Debian distro. You might be successful, but why go through all that pain if you can work on a regular Debian or Ubuntu distro with LinuxDeploy? That way you get a graphical user interface (X or Wayland), a regular package manager and plenty of help on the Internet.
Last Edit: June 04, 2022, 11:57 by 68040
	Pages: [1] 2

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.