G5 qemu attempts.

[Naiw]

I think it would be more interesting doing something similar to Classic but with Linux and a nanokernel shim (but at the same time MacOnLinux is there already)

Classic have had a lot of performance and compatibility related issues. I remember not being able to use DAW software under Classic at all. I doubt we could do it better than Apple...

I would claim that the performance issues related to Classic was more to do with the fact Classic was a second class citizen in the Mac OS X installation- if OS X prioritized the Classic process it probably wouldn't been that bad. (as well as the rootless mode, window doublebuffering hacks etc that basically only made it usable for word processors and a like applications that basically only used Toolbox (Quickdraw/Quicktime etc especially) calls for everything, a lot of applications on OS 9 however had their own implementations of blitting routines etc and those broke on Classic because of the stupid double buffering hack Apple used- which of course was necessary to allow windows to overlap without artifacts when run in a rootless window.
As for audio etc yes, the lack of hardware access of course caused issues there- but that's something that could have been solved if Apple wanted to (QEMU, VMWare etc supported it for ages) PCI passthrough etc is not a technical impossibility even without an IOMMU on the PCI buss, it's just not secure- but anyone who cares about security wouldn't run Mac OS 9 to start with.

Compatibility would be tricky regardless of solution, especially on everything but the first G5 (PCI-X; PCI-X can run in PCI compatibility mode as far as I know- so I think it's theoretically plausible to have it work with OS 9 with some efforts... but then again I never really looked into the specification at detail so it's mostly a guess), the PCIe on the other hand that the majority of the G5s used are completely different beast however and even if someone magically would manage to get PCIe working, it's not compatible with PCI so no PCI card drivers etc would work (which means no ASIO or similar).

While the alternative would be to leverage the device layer support on another kernel such as Linux would give a lot of this "for free", In fact MacOnLinux already has higher compatibility than Classic ever had- unfortunately MacOnLinux was never ported to the G5 (and I believe the original implementation is extremely dated so it's unlikely it would even work with recent linux kernels), I know there was efforts porting MacOnLinux to use KVM instead of it's own hypervisor implementation- but I guess that essentially would leave us up to the point we are right now- with QEMU and KVM, ie. The bootstrap/nanokernel is unable to boot due to supervisor differences on the G5.

Anyway it's just my two cents, getting the kernel started and Mac OS to boot at all is of course beneficial in all scenarios, regardless of what path one may take after that.

[ELN]

FWIW, if someone can get me a Trampoline that just lumps over the line to start the NanoKernel, then I can go nuts patching the NanoKernel. Progress might be swift. Excellent work all and especially darth! (Maybe this will help if you ever want to go back to graphics drivers, or maybe the kernel?)

[ELN]

I suppose I’d better get back onto the legacy NanoKernel reversal!

[Daniel]

It's a pity we can't work on all of our thousand projects at once.

[powermax]

I think it would be more interesting doing something similar to Classic but with Linux and a nanokernel shim (but at the same time MacOnLinux is there already)

Classic have had a lot of performance and compatibility related issues. I remember not being able to use DAW software under Classic at all. I doubt we could do it better than Apple...

I would claim that the performance issues related to Classic was more to do with the fact Classic was a second class citizen in the Mac OS X installation- if OS X prioritized the Classic process it probably wouldn't been that bad. (as well as the rootless mode, window doublebuffering hacks etc that basically only made it usable for word processors and a like applications that basically only used Toolbox (Quickdraw/Quicktime etc especially) calls for everything, a lot of applications on OS 9 however had their own implementations of blitting routines etc and those broke on Classic because of the stupid double buffering hack Apple used- which of course was necessary to allow windows to overlap without artifacts when run in a rootless window.
As for audio etc yes, the lack of hardware access of course caused issues there- but that's something that could have been solved if Apple wanted to (QEMU, VMWare etc supported it for ages) PCI passthrough etc is not a technical impossibility even without an IOMMU on the PCI buss, it's just not secure- but anyone who cares about security wouldn't run Mac OS 9 to start with.

Compatibility would be tricky regardless of solution, especially on everything but the first G5 (PCI-X; PCI-X can run in PCI compatibility mode as far as I know- so I think it's theoretically plausible to have it work with OS 9 with some efforts... but then again I never really looked into the specification at detail so it's mostly a guess), the PCIe on the other hand that the majority of the G5s used are completely different beast however and even if someone magically would manage to get PCIe working, it's not compatible with PCI so no PCI card drivers etc would work (which means no ASIO or similar).

While the alternative would be to leverage the device layer support on another kernel such as Linux would give a lot of this "for free", In fact MacOnLinux already has higher compatibility than Classic ever had- unfortunately MacOnLinux was never ported to the G5 (and I believe the original implementation is extremely dated so it's unlikely it would even work with recent linux kernels), I know there was efforts porting MacOnLinux to use KVM instead of it's own hypervisor implementation- but I guess that essentially would leave us up to the point we are right now- with QEMU and KVM, ie. The bootstrap/nanokernel is unable to boot due to supervisor differences on the G5.

Anyway it's just my two cents, getting the kernel started and Mac OS to boot at all is of course beneficial in all scenarios, regardless of what path one may take after that.

Thank you for this exhaustive answer. At first glance, I don't see any major software-side roadblock in updating MOL for G5 except the time constraint. Someone willing to undertake this task, will have to understand MOL's code first and that requires a lot of time.

To my knowledge, PCI cards cannot be plugged into PCIe slots. That means we cannot use pre-G5 hardware with G5 machines unless I missing something (?)

IIUC, we had a possibility to build a transition layer between legacy software and newer hardware on top of MOL, right?

I think MOL deserves a separate thread. What do you think about moving the MOL-related discussion to elsewhere? What's the right place for that? Software development?

[refinery]

To my knowledge, PCI cards cannot be plugged into PCIe slots. That means we cannot use pre-G5 hardware with G5 machines unless I missing something (?)

only the final generation of G5s used PCIe (970MP series), the others were all PCI-X.
There are actually hardware adapters which allow you to plug one into the other or vice versa, but ive no idea how well they would work on a PPC machine.

[ELN]

OS 9’s communication with the PCI bus controller is well abstracted using a pluggable module called the PCICyclesLib, which I think actually exposes part of the interface that belongs to the Expansion Bus Manager. So write a new PCICyclesLib to wang the ?K2 and we should be good.

[darthnVader]

To my knowledge, PCI cards cannot be plugged into PCIe slots. That means we cannot use pre-G5 hardware with G5 machines unless I missing something (?)

only the final generation of G5s used PCIe (970MP series), the others were all PCI-X.
There are actually hardware adapters which allow you to plug one into the other or vice versa, but ive no idea how well they would work on a PPC machine.

I have a PCI-E to PCI adepter, they are pretty transparent to the host, should work in just about any system.

We also used GPU's that had a PCI-E to AGP bridge, and they are transparent  to the host.

Likely OS 9 would just treat PCI-E slots as PCI. I pasted a PCI Firewire card in the PCI-E adepter to Qemu-PPC and it worked fine in 9.2.2 and 10.4 with my Firewire devices.

[darthnVader]

I got some new hardware( G5 Quad ), so I wanted to get back to this.......

Have a look at this from KVM-pr in Qemu.

Code: [Select]

qemu-system-ppc' -enable-kvm  -hda '/media/jam/d9d5c74c-a218-45c6-9d7f-8d8274228955/Tiger.img' -cpu g4 -M mac99 -m  1536  -prom-env "aapl,debug=3013FFF" -cdrom ~/OS9.iso -prom-env 'auto-boot?=false'
Am I getting the NanoKernel?

[ELN]

Yep. Nice!

[Jubadub]

It's amazing to see the progress you guys made with G5, QEMU and Mac OS 9. That stuff about PCI/PCIe adapters + device detection had me blown away, as well. I wouldn't have thought QEMU OS 9 would have seen the FireWire devices just like that.

Also grats on acquiring the G5 Quad, darthnvader, it's one of the loveliest machines I have ever used. But that machine and all the other G5s desperately need some native OS 9 love! I see myself using the Mac mini G4 a lot more than my Quad simply because it has OS 9. This needs to change... And you guys have made some really nice discoveries and progress to that end.

[ELN]

Just the encouragement we need!

[teroyk]

Good work! Please document well what your findings right now, it might open whole new world for G5 hardware. Although I try to not get involved in before January 2021 

[Naiw]

Been too busy to follow the Mac OS retro community for a while (and most likely will be soon again, to add to that it appears my G4 yikes had a CF card malfunction and lost basically it's entire disk...) as well as my G5 that I don't know what happened to yet.... if it's a harddrive failure or some intermittent issue- but I'm fairly sure I had OS X 10.4 installed on it... but it's also just flashing question mark when attempting to boot up now)

But long story short, I suppose there been no significant strides in either the QEMU classic macos emulation (for x86) or MacOnLinux?

[Daniel]

There is always a slow trickle of progress on one thing or another, but I don't think anything is directly relevent to the G5.