Programming my own Mac emulator

[kataetheweirdo]

Yes, that is the g3beige target trying to run 10.2. 10.0 gets stuck in a pinwheel.

Can't say much else yet.

[mihaiparparita]

It's impressive how far DingusPPC has come. I'm interesting in integrating it into the Infinite Mac project, since it seems like a better foundation for PPC emulation than SheepShaver (as far as aiming for more accurate emulation and being actively maintained).

I've gotten a version that's able to use a 6100 ROM to boot the System 7.1.2 Disk Tools floppy image. One that uses a 7.1.2 HD image gets stuck shortly after the Welcome To Power Macintosh screen (though my native build also has that same behavior). Do you have machine/OS combos that you're focused on/are known to be most reliable? More generally, is a better way to reach you (and Maxim?) discuss DingusPPC development?

[Cat_7]

There is a discord channel: https://discord.com/channels/3942246416 ... 7297065994

As far as I know, no emulation target boots to the desktop from HD image. There is also no keyboard support yet.
You might also look at Qemu for accurate emulation.

Best,
Cat_7

[adespoton]

There is a discord channel: https://discord.com/channels/3942246416 ... 7297065994

As far as I know, no emulation target boots to the desktop from HD image. There is also no keyboard support yet.
You might also look at Qemu for accurate emulation.

Best,
Cat_7

Running Qemu in a browser via WebASM is probably not a good idea yet. For browser-based emulation like in Infinite Mac, speed is generally more important than accuracy. If people want more accurate emulation, it's better to move off the browser-based emulation and onto dedicated apps.

I do essentially the same thing as Infinite Mac, but host all the instances in the Finder instead of a browser, with each OS version being its own app. DingusPPC isn't at the point yet where it would be appropriate to use in Infinite Mac; the emulators that should work well right now (in 2023) are Mini vMac, PCE (as used by archive.org), Basilisk II, and SheepShaver. And possibly some of the Mac cores from MAME, but those don't usually provide any benefit over Mini vMac and PCE.

[kataetheweirdo]

mihai has got some fixes in for DingusPPC. Right now, you can fiddle around with Disk Tools images. You can use the mouse and keyboard fully, and it doesn't seem to crash (unless you try to format a hard disk). However, trying to boot the OS itself from CD or Hard Disks presents an interesting problem - Namely, the icons and the text doesn't show up. We think this may be related to a event that's supposed to be called by WaitNextEvent and GetNextEvent, but that somehow never gets triggered.

[adespoton]

mihai has got some fixes in for DingusPPC. Right now, you can fiddle around with Disk Tools images. You can use the mouse and keyboard fully, and it doesn't seem to crash (unless you try to format a hard disk). However, trying to boot the OS itself from CD or Hard Disks presents an interesting problem - Namely, the icons and the text doesn't show up. We think this may be related to a event that's supposed to be called by WaitNextEvent and GetNextEvent, but that somehow never gets triggered.

I'd be really interested in getting you guys in a room with Pukka and Tony -- your project goals are different (68k vs PPC, toolbox emulation vs hardware emulation), but you seem to be running up against some similar issues.

Then again, if you could find Derek somewhere, I know he was having similar issues with Fusion and SoftMac back in the day....

All this to say, the issue seems to be one that's already been experienced by those working on 68k emulation; SheepShaver doesn't count because it fakes the hardware and patches out the toolbox calls.

I forget: is DingusPPC doing a complete OF implementation, or emulating a G2 PPC?

[Madd the Sane]

From my understanding, Old World Macs (at least those that had a PCI bus) had a stripped-down version of Open Firmware.

[kataetheweirdo]

From my understanding, Old World Macs (at least those that had a PCI bus) had a stripped-down version of Open Firmware.

Less stripped down, and more just plain buggy.

I'd be really interested in getting you guys in a room with Pukka and Tony -- your project goals are different (68k vs PPC, toolbox emulation vs hardware emulation), but you seem to be running up against some similar issues.

Then again, if you could find Derek somewhere, I know he was having similar issues with Fusion and SoftMac back in the day....

All this to say, the issue seems to be one that's already been experienced by those working on 68k emulation; SheepShaver doesn't count because it fakes the hardware and patches out the toolbox calls.

I forget: is DingusPPC doing a complete OF implementation, or emulating a G2 PPC?

I would be glad to dissect this issue really, because WaitNextEvent and GetNextEvent are both really hacky commands added as part of the MultiFinder. These managed to survive into the Carbon API, yet I'd like to know how these were implemented. DingusPPC is emulating pre-New World machines in general right now, which includes G2 PPCs.

[kataetheweirdo]

So, it turns out the reason icons and the text won't show up is because the ntrb QuickDrawText trap isn't properly working (i.e. StdTxMeas, StdText). With this deleted, the text does show up. However, to delete it, you have to edit the PowerPC Enabler. I suspect there may be some CPU error with these.

It should be noted this doesn't affect the Disk Tools images since these only have a minimal PowerPC enabler that lacks the troublesome traps.

[that-ben]

This is absolutely incredible how far retro Mac emulation has gone over the last few years. Every year, it seems something I thought would never exist is being put together. Keep it up! It's like a dream come true that all those emulators now run in WASM in what anybody has got on their device: a web browser. Doesn't matter what kind of device and what OS you've got... Hosts matter less and less and I think it's a very good thing, honestly. The only thing that some users are afraid of is that since this requires a web server, they're afraid it's going to go offline at some point, but since all those emulators also have a native port, then currently, it's not really an issue.

[kataetheweirdo]

So, it turns out the reason icons and the text won't show up is because the ntrb QuickDrawText trap isn't properly working (i.e. StdTxMeas, StdText). With this deleted, the text does show up. However, to delete it, you have to edit the PowerPC Enabler. I suspect there may be some CPU error with these.

And yep, I just merged in a fix for some Power instructions (dozi, doz, nabs) that partially fixes this. We're already working on fixing up the FPU emulation, so that's just a nice bonus.

I'll also be fixing up keyboard support for non-US keyboards.

[mihaiparparita]

And yep, I just merged in a fix for some Power instructions (dozi, doz, nabs) that partially fixes this.

https://github.com/dingusdev/dingusppc/pull/67 for anyone that's curious.

[adespoton]

So, it turns out the reason icons and the text won't show up is because the ntrb QuickDrawText trap isn't properly working (i.e. StdTxMeas, StdText). With this deleted, the text does show up. However, to delete it, you have to edit the PowerPC Enabler. I suspect there may be some CPU error with these.

And yep, I just merged in a fix for some Power instructions (dozi, doz, nabs) that partially fixes this. We're already working on fixing up the FPU emulation, so that's just a nice bonus.

I'll also be fixing up keyboard support for non-US keyboards.

Woohoo! I'm not sure if they'd be interested since their FPU emulation works differently, but it might be worth flagging this work up to Mark Cave-Ayland once you've got yours somewhat functional -- there's still issues with the QEMU PPC FPU emulation, and a fresh take might give them some ideas.

What are you guys using for your reference spec?

[adespoton]

This is absolutely incredible how far retro Mac emulation has gone over the last few years. Every year, it seems something I thought would never exist is being put together. Keep it up! It's like a dream come true that all those emulators now run in WASM in what anybody has got on their device: a web browser. Doesn't matter what kind of device and what OS you've got... Hosts matter less and less and I think it's a very good thing, honestly. The only thing that some users are afraid of is that since this requires a web server, they're afraid it's going to go offline at some point, but since all those emulators also have a native port, then currently, it's not really an issue.

How's your dream project coming along to have a simple Mac-in-a-Browser?

[that-ben]

How's your dream project coming along to have a simple Mac-in-a-Browser?

Me? Honestly, when Mihai released the first SheepShaver WASM build almost 2 years ago, I saw Mac OS 9 booting in a web page, I could not believe it! Then I tried on my iPad and my iPhone and I could even less believe it!! Now I'm seeing what looks like Mac OS X beginning to boot and I'm in complete shock. 3 years ago, nobody thought we'd ever see this and now it's happening O.O This is nothing short of incredible.

[Cat_7]

It looks like Mihai is helping with and waiting for DingusPPC. I believe it seems to him Qemu is too heavy to run in a browser.

Best,
Cat_7

[mihaiparparita]

What are you guys using for your reference spec?

DingusPPC has a PowerPC emulation test suite at https://github.com/dingusdev/dingusppc/ ... u/ppc/test. I believe it was based on https://github.com/lioncash/DolphinPPCTests.

[mcayland]

So, it turns out the reason icons and the text won't show up is because the ntrb QuickDrawText trap isn't properly working (i.e. StdTxMeas, StdText). With this deleted, the text does show up. However, to delete it, you have to edit the PowerPC Enabler. I suspect there may be some CPU error with these.

And yep, I just merged in a fix for some Power instructions (dozi, doz, nabs) that partially fixes this. We're already working on fixing up the FPU emulation, so that's just a nice bonus.

I'll also be fixing up keyboard support for non-US keyboards.

Woohoo! I'm not sure if they'd be interested since their FPU emulation works differently, but it might be worth flagging this work up to Mark Cave-Ayland once you've got yours somewhat functional -- there's still issues with the QEMU PPC FPU emulation, and a fresh take might give them some ideas.

Well, that would be me then . What do you believe are the current issues with the QEMU PPC FPU emulation? Speed is probably the main one, but the current limitation there is that QEMU uses softfloat for accurate FPU emulation rather than relying on the host (each host architecture has differences in its interpretation of the spec compared with a real PPC CPU, particularly around flags).

[adespoton]

And yep, I just merged in a fix for some Power instructions (dozi, doz, nabs) that partially fixes this. We're already working on fixing up the FPU emulation, so that's just a nice bonus.

I'll also be fixing up keyboard support for non-US keyboards.

Woohoo! I'm not sure if they'd be interested since their FPU emulation works differently, but it might be worth flagging this work up to Mark Cave-Ayland once you've got yours somewhat functional -- there's still issues with the QEMU PPC FPU emulation, and a fresh take might give them some ideas.

Well, that would be me then . What do you believe are the current issues with the QEMU PPC FPU emulation? Speed is probably the main one, but the current limitation there is that QEMU uses softfloat for accurate FPU emulation rather than relying on the host (each host architecture has differences in its interpretation of the spec compared with a real PPC CPU, particularly around flags).

Right; thanks for the reminder -- I'm sure you've told me that in the past as well, and I've dealt with it in the source too.

The only current issues with QEMU PPC FPU emulation that crop up for me are speed -- both the speed of the emulation, and the speed of hand-off to the FPU routine. The first likely comes down to SoftFloat not taking advantage of available hardware -- everything's done using standard CPU conversion instructions, which is always going to be slow. Cheating with Fast may help, but that'll also introduce errors which will compound over time. The second... I don't understand the interactions enough to really understand the problem, but it seems to me that there's some sort of a buffering or bandwidth issue going on that is adding an extra layer of slowness beyond what's intrinsic in the SoftFloat CPU-based FPU emulation. This appears to interact with the screamer audio emulation as well? I'm pretty sure you've explained what's going on here before, but I can't recall what it boils down to now.

DingusPPC is supposed to be platform agnostic though, so it's going to run up against the same issues as QEMU with FPU emulation. Which means they'll have the same performance constraints, but possibly a different approach to resolving them?

[Cat_7]

Speed is probably the main one, but the current limitation there is that QEMU uses softfloat for accurate FPU emulation rather than relying on the host (each host architecture has differences in its interpretation of the spec compared with a real PPC CPU, particularly around flags).

From following the discussion on discord, the DingusPPC people are running into the same issue with the inexact flag. They also found the paper by Cota.
Let's see which path they choose. Speed or Perfection, or something Brilliant

Partial use of hardfloat gave us ~20% speed increase for FPU operations (available in the experimental sound-enabled builds). And a warning accompanying the builds that exact FPU results cannot be guaranteed....

Best,
Cat_7