I don't know in what loop the audio runs, but I guess it doesn't get enough time. There is some talk on the development list about supporting sdl2 audio playback as you probably have seen. Perhaps that is a route.Or threading. It seems there are some issues with SDL and threading.

Best,Cat_7

I think you are on to something. There isn't any mutex locks in the screamer source code. So what is stopping two or more threads from changing the audio buffer - nothing!

I can't seem to run DP2 from a build of the source code that alex linked, I think Cat_7 built the qemu.exe from that source code, I'm not sure it will run DP2.

It keeps rebooting on me, before I get passed BootX, but it maybe the Screamer mod I did to the source code.

Just on the off chance it happens to be helpful, I have a recompiled version of BootX with logging here; in /theory/ it should work for DP2 (it works for Server 1.x and OS X 10.0+): https://github.com/steventroughtonsmith/BootX

I can't seem to run DP2 from a build of the source code that alex linked, I think Cat_7 built the qemu.exe from that source code, I'm not sure it will run DP2.

It keeps rebooting on me, before I get passed BootX, but it maybe the Screamer mod I did to the source code.

Just on the off chance it happens to be helpful, I have a recompiled version of BootX with logging here; in /theory/ it should work for DP2 (it works for Server 1.x and OS X 10.0+): https://github.com/steventroughtonsmith/BootX

(find it in the Releases tab)

Thanks steven, I I've been checking out booting emu-system-ppc64 with -cpu 970fx, but it hangs at BootX, so maybe this will tell me why the mach_kernel never loads.

I don't think I was able to boot DP2 with mac99, I think it has to be g3beige, but I was just checking if steven's BootX with logging would tell me anything useful as to why the mac99_U3 G5 wouldn't boot Panther's kernel.

I used to boot DP2 in mac99 so far.Just now have tried 5 or 6 times to boot in g3beige (checking filesystem,rebooting and an error with LoginWindow).The last attempt successful(-usb -device usb-mouse and 32 bit mode on command line).The second boot (after shutdown) successful,the third not.MacOS.app in DP2 provides Mac OS 9.0 with Mac OS ROM 3.0.In DP1 it is MOS 8.6.By the way,it's a proof of concept: MOS 8.6 and 9.0 can work in qemu g3beige.We only need to find the way.

Last edited by alex195812 on Mon Feb 06, 2017 3:54 am, edited 1 time in total.

MacOS.app in DP2 provides Mac OS 9.0 with Mac OS ROM 3.0.In DP1 it is MOS 8.6.By the way,it's a proof of concept: MOS 8.6 and 9.0 can work in qemu g3beige.We only need to find the way.

Interesting, I thought the "Blue Box" ran in some sort of emulation, I thought I read somewhere that it didn't really boot on the real hardware, if it does, the we show be able to get OS 9 to run on a G5?

I forget how to use MacBugs, but it's not really useful, because it doesn't load till after all the toolbox calls and MacOS Rom calls?

Yes it's kinda emulation,but not too sotfy (there must be many redirections to "real" hardware).Afaik,no one has booted MOS 9 on G5.On unsupported G4 -- yes.There's something about it at https://www.thinkclassic.org/viewtopic.php?id=46I think the most "native" system for G5 is Leopard.And it seems that nothing yet works in qemu-system-ppc64 mac99.It's in an early state yet.

Last edited by alex195812 on Mon Feb 06, 2017 4:49 am, edited 5 times in total.

Actually that sounds like the partition isn't being opened correctly, probably at the OpenBIOS level? It was something like this that required my OpenBIOS partition check patch on Server 1.x. It would go beyond that in BootX if the problem were the kernel itself (it tells you when it's about to jump to the kernel).

Actually that sounds like the partition isn't being opened correctly, probably at the OpenBIOS level? It was something like this that required my OpenBIOS partition check patch on Server 1.x. It would go beyond that in BootX if the problem were the kernel itself (it tells you when it's about to jump to the kernel).

Granted I haven't tried with 10.3's kernel, only 10.1 and earlier

Could be, when I tried the same thing with the 32 bit G4 and mac99, I got:

I think people have Linux working on the ppc64 mac99, using 970fx, but I'm not sure.

I'm not really sure the point of trying to run 8.6 on the g3beige. The g3beige seems to be the one closest to a real mac, I've even encountered the 768MB ram limit for the Beige G3. It may need a rewrite of the mac_oldworld.c to even support Rom in Ram.

Sure, ideally, we'd love to see the g3beige support booting 8.1, 8.5, 8.6, 9.0, 9.0.4, 9.1, 9.2.1, 9.2.2, 10.0, 10.1, and 10.2.x, but it would either require incorporating the actual boot rom image of a Beige G3 into Qemu, or rewriting the g3beige emulator to make it pretty much like mac99, that is a bastard of a Beige G3, a Yikes, and a Sawtooth.

Maybe, it can be done by only modifying the Mac OS Rom, and the Systems suitcase, but, in the end, I can't think of any software that will run on a Powermac emulator in 8.1, 8.5, or 8.6, that won't run in OS 9. It's all about compatibility with older software, getting older OS's to run is pointless, without the need to run an older version, for software to run.

BeOS may be started from Mac OS ,but it seems it doesn't support Mac OS 9.That's why I want 8.6.But booting 8.6 in mac99(with changed MacOS ROM and edited System file) fails with "bus error".That's why the hope is for g3beige.Though currently it fails,too

BeOS may be started from Mac OS ,but it seems it doesn't support Mac OS 9.That's why I want 8.6.But booting 8.6 in mac99(with changed MacOS ROM and edited System file) fails with "bus error".That's why the hope is for g3beige.Though currently it fails,too

BeOS definitely won't work as-is, I looked into it—the MacOS portion of the installer chain-loads a PEF bootloader from its resource fork, I believe. I ripped it out to study it; if you could boot it directly, then you don't need the Mac OS bit at all. https://www.dropbox.com/s/8khd9ycss1w1z35/BEBOOT.zip?dl=0

I believe this only supports PReP machines, not OpenFirmware (OpenBIOS), so you'd need a whole new hardware target in qemu emulating an older kind of PowerMac.

BeOS may be started from Mac OS ,but it seems it doesn't support Mac OS 9.That's why I want 8.6.But booting 8.6 in mac99(with changed MacOS ROM and edited System file) fails with "bus error".That's why the hope is for g3beige.Though currently it fails,too

I think it maybe easier to get the Mac99 to boot from 8.6 than the g3biege. Years ago I edited the Systems suitcase to support 9..2.1/2 on Old World mac's I think I had a thread over at macfixit that explained what all I changed, I changed more the the patcher utilities do, as they were unstable on my PM8600, but my edits were more stable than OS 9.1 was on the same Machine.

If I can dig up the thread, I maybe able to help with the bus error.

EDIT: Seems macfixit sold out to CNet, and I had to set the wayback machine to 2009 just to reach their forum archives, but they didn't appear to have the old archives, from around 2002, so my Google assisted memory won't be of much use.

The floating point unit in QEMU is slow, but I think it might be fast enough handle sound playback.

A number of months ago, when we were looking at the USB sound, we discovered that the FPU was the culprit in causing the delays to the sound buffer. I still think that the floating point unit is the culprit here (and in a number of other performance areas) and the tinycode is going to band-aid it, but not really fix the issue.

I'm not sure we can say the FPU is the problem. It was more of a theory rather than a proven fact.

adespoton wrote:

Has anyone started looking at implementing a new streamlined FPU module? It would take me a few years to do it, but if nobody else is, I might start.

I have. I tried making it so that floating point math was handled by the host floating point unit. Things did not work out. Just changing the optimization level of GCC was enough to make the code break. I could show you my patch if you want.

How would you go about making QEMU's floating point unit faster?

My plan was to start off doing a pass-through like you did, then work backwards, abstracting as needed to stabilize each instruction. The biggest part in my mind would be keeping the FPU properly synced without sacrificing performance. Based on the theory we were running with before, it seems that only a few of the FPU instructions were really involved in the slowdown... if we can find some way to cheat at those ones, we should do better.

As a totally blue sky thought... I wonder what would happen if we passed the FPU emulation off to SDL/OpenGL?

For me,fixing bus error is way too high.What bus,for the beginning?...It needs using debuuger,then coding.It's not my land yet.Though I suppose that it is IDE bus.Why?Booting DP1 from hd in mac99 shows "Still waiting for root device" which is surely related to IDE bus not handled.DP1 and 8.6 are contemporary systems...How do we workaround it in DP1?We don't fix IDE hardware,we just successfully boot DP1 in g3beige.So,for me, hacking around with openbios and MacOS ROM is a more realistic way. Though it isn't easy,too.First,we often get "No valid state" trying to start OS 8 or 9.I found that adding "PowerMac1,1" and "PowerMac3,1" to "compatible" property for both mac99 and g3beige eliminates the message in many cases (By the way, it also allows booting DP1 w/o additional parameters on command line).But new error messages come:"unable to find /rtas" when loading ROMs <3.6 in both mac99 and g3beige.Loading ROMs >=3.6 in g3beige shows "cannot find interrupt controller node".ROMs >=3.6 in mac99 may work.(Though 3.6 boots successfully only from cd,not hd). There is a patch about rtas for openbios: https://www.openfirmware.info/pipermail ... 09073.html that allows to go farther.(Interesting,that almost identical patch was proposed by Cormac O'Brian in 2015: https://www.coreboot.org/pipermail/open ... 08687.html).This patch creates /rtas in mac99(Real g3beige had no rtas at all).But it doesn't give much:passing "cannot find /rtas" it stops at "Mac OS :unable to find RTAS" as rtas is not implemented in qemu itself.I wonder if creating "illegal" rtas for g3beige could give anything... I wonder why ROMs>=3.6 don't need rtas neither in openbios dev tree nor in qemu?That's why we can boot OS 9 at all. As for BeBoot file posted by Steven,to go this way also needs whole lotta digging about PEF and Mac genarally... Though some documentation is available here: https://web.archive.org/web/20020208214 ... ch-89.html and in other places. Here is openbios version with changes I mentioned above(modified "compatible" property,rtas):https://drive.google.com/open?id=0B69bs ... UVEQ25Vb1kif someone's curious.

For me,fixing bus error is way too high.What bus,for the beginning?...It needs using debuuger,then coding.It's not my land yet.Though I suppose that it is IDE bus.Why?Booting DP1 from hd in mac99 shows "Still waiting for root device" which is surely related to IDE bus not handled.DP1 and 8.6 are contemporary systems...How do we workaround it in DP1?We don't fix IDE hardware,we just successfully boot DP1 in g3beige.So,for me, hacking around with openbios and MacOS ROM is a more realistic way. Though it isn't easy,too.First,we often get "No valid state" trying to start OS 8 or 9.I found that adding "PowerMac1,1" and "PowerMac3,1" to "compatible" property for both mac99 and g3beige eliminates the message in many cases (By the way, it also allows booting DP1 w/o additional parameters on command line).But new error messages come:"unable to find /rtas" when loading ROMs <3.6 in both mac99 and g3beige.Loading ROMs >=3.6 in g3beige shows "cannot find interrupt controller node".ROMs >=3.6 in mac99 may work.(Though 3.6 boots successfully only from cd,not hd). There is a patch about rtas for openbios: https://www.openfirmware.info/pipermail ... 09073.html that allows to go farther.(Interesting,that almost identical patch was proposed by Cormac O'Brian in 2015: https://www.coreboot.org/pipermail/open ... 08687.html).This patch creates /rtas in mac99(Real g3beige had no rtas at all).But it doesn't give much:passing "cannot find /rtas" it stops at "Mac OS :unable to find RTAS" as rtas is not implemented in qemu itself.I wonder if creating "illegal" rtas for g3beige could give anything... I wonder why ROMs>=3.6 don't need rtas neither in openbios dev tree nor in qemu?That's why we can boot OS 9 at all. As for BeBoot file posted by Steven,to go this way also needs whole lotta digging about PEF and Mac genarally... Though some documentation is available here: https://web.archive.org/web/20020208214 ... ch-89.html and in other places. Here is openbios version with changes I mentioned above(modified "compatible" property,rtas):https://drive.google.com/open?id=0B69bs ... UVEQ25Vb1kif someone's curious.

I use this to boot past the RTAS node part of Mac OS 8.6's ROM (I'm booting the ROM file directly from a temporary disk image); it then fails at finding the right interrupt controller node:

I've been using that form of device spoofing to get around boot problems on other OSes, like Rhapsody. If the RTAS can be spoofed that easily, then perhaps you needn't focus on it rather than the interrupt controller stuff (which, I presume, is just looking for a specific form of interrupt controller that the g3beige device tree doesn't have?).

I may have missed something but I saw no interrupt controller in dev tree for g3beige at all.There is hw/intc/heathrow_pic.c in qemu source tree.May it be that pic is simply missing in openbios dev tree for g3beige?That wouldn't affect MOSX work.If so what should be the values for this device?Does anybody have a real G3 Mac to see it?

Here are settings for interrupt-controller from Mac-on-linux source from file mol-0.9-72-1/mollib/oftree.nw.old:

In MOL mac-io is in pci-bridge and hex words are used instead of int values.Hex may be converted to decimal,surely,but I don't know what to do with "reg" property as it has two numbers: 16 and 32.And generally,would it be sufficient to place (suppose correct) values in dev tree?Wouldn't it need correspondent changes somewhere in qemu files? Qemu has pci-bridge,too.Isn't it necessary to create pci-bridge in dev tree like in MOL?So many questions...

The first text part is a script in Forth language,the second are the messages printed on the screen...As seen from the bootscript it looks for /rom device and next,/rom/macos (hardware Mac OS ROM?).Rather strange for PowerMac1,1 is kinda New World,isn't it?The screen messages show that interrupt-controller is looked in /pci/mac-io (not /pci/pci-bridge/mac-io where it is in MOL).If we pass int-controller check will we get missing /rom/macos error?

Last edited by alex195812 on Wed Feb 08, 2017 12:08 pm, edited 2 times in total.

I guess you guys are confusing things again. No "Mac OS ROM" file, from any software revision, can boot Old World machines like the g3beige. Them don't have the necessary code to do it. I though this was clear enough from the last talk.If you really want a G3 class machine model which can boot the "Mac OS ROM" file included in the 8.6 CD, you need look at the "blue&white" NewWorld G3, which was somewhat emulated by PearPC, and port it to QEMU, that's the only way. The problem is that g3bw doesn't allow you go lower than MacOS 8.6, and is less compatible with things like Rhapsody and BeOS... And you really don't gain anything emulating OS 8.6 instead something newer like OS9.2.

steventroughtonsmith wrote:

BeOS definitely won't work as-is, I looked into it—the MacOS portion of the installer chain-loads a PEF bootloader from its resource fork, I believe. I ripped it out to study it; if you could boot it directly, then you don't need the Mac OS bit at all. https://www.dropbox.com/s/8khd9ycss1w1z35/BEBOOT.zip?dl=0

I believe this only supports PReP machines, not OpenFirmware (OpenBIOS), so you'd need a whole new hardware target in qemu emulating an older kind of PowerMac.

PReP =! OldWorld. PowerMacs never were PReP. And PowerMacs from Nitro (8600) and upwards are all them CHRP-like designs and all them have OpenFirmware, despite it being incomplete and hidden.With that said... BeOS was tested in 7xxx, 8xxx and 9xxx PCI PowerMacs, and people says BeOS can boot in the G3 Beige, all them OldWorld machines. Is well known BeOS will not work in the G3 Blue&White and upwards, which are NewWorld machines. There are wikis and the Wayback Archive with the BeOS hardware requeriments out there.

alex195812 wrote:

Here are settings for interrupt-controller from Mac-on-linux source from file mol-0.9-72-1/mollib/oftree.nw.old:

In fact,we use qemu g3beige as "BW" PowerMac1,1 (adding it to "compatible" property or even change "model" to PowerMac1,1,then creating a dummy /rtas to go through) when trying to boot 8.5 or 8.6.The next stand is interrupt-controller which is missing from g3beige dev tree. And it appears (as shown by @steventroughtonsmith) that DP1/Server/Rhapsody are more compatible just with PowerMac1,1 (we cannot boot DP1/Rhapsody in ordinary mac99 or g3beige without "pretending to be a BW").And,also,I read that original OS for BW was 8.5.As for BeOS,I didn't know that it doesn't work on BW.Still,there is a chance.If we manage to boot OS 8.6 in "pretended" BW,BeOS might start from it (as "really" it is g3beige). That MOL devtree seems to be "universal", both old and new world (Power Macintosh in "compatible" property,heathrow in interrupt-controller "compatible" property,/rom...Though "model" is a NewWorld PowerMac1,1,but it's OK).As for usb,we often use -usb -device usb-mouse with g3beige in qemu for adb mouse emulation is not well with DP1.Yes,it's hacky and not "ideologically clean" but that's how it is currently. Generally,g3beige and g3bw are rather similar and it seems that g3bw profile could be created basing on g3beige qemu code.

In fact,we use qemu g3beige as "BW" PowerMac1,1 (adding it to "compatible" property or even change "model" to PowerMac1,1,then creating a dummy /rtas to go through) when trying to boot 8.5 or 8.6.The next stand is interrupt-controller which is missing from g3beige dev tree. And it appears (as shown by @steventroughtonsmith) that DP1/Server/Rhapsody are more compatible just with PowerMac1,1 (we cannot boot DP1/Rhapsody in ordinary mac99 or g3beige without "pretending to be a BW").

Just to clarify — the reason my boot scripts sometimes spoof PowerMac1,1 isn't anything to do with the OS itself, but the Forth/OF boot script that runs before BootX to decide whether your machine is compatible with the OS or not. It's not a hard check for anything, it just checks the model number. You can patch the ISO if you prefer, but spoofing is easy. Oldworld g3beige is significantly different from an actual New World Yosemite-class PowerMac1,1.