DingusPPC To-Do List

[kataetheweirdo]

As this emulator is a huge work in progress, I'll be listing out what needs to be done for this emulator.

TO BE REFINED
* non-word DBDMA operations

IN PROGRESS
* Cached Interpreter
* ATI Rage 128 support
* CMD646 support
* Floating point fixes (See also)

TO BE STARTED
* Networking support
* USB support

[thecloud]

Any updates to this list for 2026?

I've compiled dingusppc from current master, as of 30 May 2026, and got Mac OS 9.2.2 installed on it. (Found that I had to remove the ATI driver extensions so things would draw correctly.) But the most annoying thing is that the mouse doesn't stay in sync with the cursor in the window, even with ctrl-G, making it very hard to use. I know this was a solved problem for QEMU via the declrom for a tablet that you can add as a NuBus/PCI virtio device. Is there any equivalent hack for DPPC?

Also, I see there is BMAC ethernet support in the source code, and it looks like the PowerMac G3 desktop machine has it. But I'm not sure if it's working, since I haven't been able to connect to other machines on my LAN or elsewhere with a manual TCP setup using a static IP address. Is networking still TBD?

[kataetheweirdo]

The floating-point has been fixed up mostly, enough to satisfy Mac OS X. The CMD646 emulation has been started, though I don't know how complete it is.

As for the mouse, there's no hacks for that yet.

The BMac Ethernet is mostly a stub to satisfy booting up the OS, so networking is still something to be done.

[joevt]

You can see some floating point issues if you run the Graphing Calculator demo in Mac OS 9.

What host OS are you having mouse issues with? DingusPPC uses SDL2 to capture the mouse when you press Control-G. The host mouse cursor should disappear during this time.

DingusPPC doesn't have networking support yet.

[thecloud]

What host OS are you having mouse issues with? DingusPPC uses SDL2 to capture the mouse when you press Control-G. The host mouse cursor should disappear during this time.

Host OS is Monterey (macOS 10.12) at the moment, but same issue occurs in Sequoia (macOS 15). The host cursor does disappear when ctrl-G is pressed, but the problem is that the host cursor position is not always within the emulator window. If I move the mouse up so the guest cursor appears to be in the guest menu bar and try to click on a menu, the hidden host cursor is actually positioned somewhere above that window. As soon as I click the mouse button, whatever window/application happens to be under its "real" position is selected and comes to the front.

It's exactly the same behavior that QEMU has if you don't use one of the workaround solutions to create an absolute pointing device which can move seamlessly in and out of the emulator window. The host cursor and guest cursor move at different speeds and so it's very difficult to position the guest cursor where it needs to be.

Thanks for the confirmation that networking is not expected to be functional yet.

[joevt]

Host OS is Monterey (macOS 10.12) at the moment, but same issue occurs in Sequoia (macOS 15). The host cursor does disappear when ctrl-G is pressed, but the problem is that the host cursor position is not always within the emulator window. If I move the mouse up so the guest cursor appears to be in the guest menu bar and try to click on a menu, the hidden host cursor is actually positioned somewhere above that window. As soon as I click the mouse button, whatever window/application happens to be under its "real" position is selected and comes to the front.

It's exactly the same behavior that QEMU has if you don't use one of the workaround solutions to create an absolute pointing device which can move seamlessly in and out of the emulator window. The host cursor and guest cursor move at different speeds and so it's very difficult to position the guest cursor where it needs to be.

I also use Monterey. I am unable to reproduce this. Are you using my fork or the main fork? I think they should both have similar behaviour. Did you compile from latest or use an alpha release? I don't notice anything significant related to this issue since the last alpha release but I haven't tried it. Maybe you can make a short video that shows the problem using Command-Shift-5?

[thecloud]

I also use Monterey. I am unable to reproduce this. Are you using my fork or the main fork? I think they should both have similar behaviour. Did you compile from latest or use an alpha release? I don't notice anything significant related to this issue since the last alpha release but I haven't tried it. Maybe you can make a short video that shows the problem using Command-Shift-5?

I compiled latest master from https://github.com/dingusdev/dingusppc, but it might not have been a clean build since the last time I tried building the project in 2025. Will try doing a fresh checkout and rebuilding it from scratch. EDIT: that made no difference; problem still occurs. Here is what I am doing to build DPPC:

Code: Select all

git clone https://github.com/dingusdev/dingusppc
cd dingusppc
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cp -p ./bin/dingusppc.app/Contents/MacOS/dingusppc ./bin/dingusppc

See screen recording here: https://drive.google.com/file/d/1pqWy5I ... share_link

[joevt]

I usually use Xcode to build but it shouldn't matter.

Create a separate build folder for Xcode. Then use cmake to create an Xcode project.

Code: Select all

cd       /Volumes/Work/Programming/dingusppc/joevt-dingusppc
mkdir -p /Volumes/Work/Programming/dingusppc/joevt-dingusppc/build-xcode
cd       /Volumes/Work/Programming/dingusppc/joevt-dingusppc/build-x-code
cmake -DDPPC_KGMACROS=ON -DDPPC_BUILD_BENCHMARKS=ON -DDPPC_BUILD_PPC_TESTS=ON -DDPPC_BUILD_DBDMA_TESTS=ON -DDPPC_68K_DEBUGGER=ON -DCAPSTONE_BUILD_CSTOOL=ON -DDPPC_SUPPORT_PPC_LE=ON -DDPPC_SUPPORT_MEM_LE=ON -G Xcode ..

You don't need -DDPPC_SUPPORT_PPC_LE=ON -DDPPC_SUPPORT_MEM_LE=ON if you're not booting a little-endian OS in the guest Power Mac such as Windows NT.
Maybe have a separate build folder for the little endian capable version of DingusPPC if you want to see the difference.

You don't need any of the other options either.

You can open the project file in Xcode to edit source files, build, and debug.

Code: Select all

open dingusppc.xcodeproj

Or you can use the xcodebuild command to build the project in the Terminal.app.

Code: Select all

xcodebuild -project dingusppc.xcodeproj -configuration Debug

Build Release instead of Debug when you're not debugging because Release has better performance.

I haven't seen your video yet. Need permission or something.

[thecloud]

I haven't seen your video yet. Need permission or something.

Sorry about that. Permissions should be fixed now.

[joevt]

I haven't seen your video yet. Need permission or something.

Sorry about that. Permissions should be fixed now.

The video clearly shows the problem. What's supposed to happen is that the mouse should not be able to leave the boundaries of the window while it is grabbed. If the mouse is grabbed while it is outside the window, it will be moved to the centre of the window. You can see this by moving the mouse while it is grabbed. When you ungrab it, the mouse should appear inside the window content area. It may be near the border of the window if you moved the mouse continuously in a single direction. Somehow, you are able to move the mouse while it is grabbed to outside of the window area.

I'm using Monterey 12.7.2. What version are you using?

What kind of mouse are you using?

How many displays do you have connected to the host Mac?

Where did you get SDL2 for compiling DingusPPC? I got mine from Homebrew. I think this shows the version info:

Code: Select all

brew info sdl2
✔︎ JSON API formula_tap_migrations.jws.json   Downloaded    2.0KB/  2.0KB
✔︎ JSON API cask_tap_migrations.jws.json      Downloaded    2.2KB/  2.2KB
✔︎ JSON API formula.jws.json                  Downloaded   33.3MB/ 33.3MB
✔︎ JSON API cask.jws.json                     Downloaded   16.9MB/ 16.9MB
==> sdl2 ↑: 2.30.5 → stable 2.32.10, HEAD
Low-level access to audio, keyboard, mouse, joystick, and graphics
https://www.libsdl.org/
Installed (on request)
/usr/local/Cellar/sdl2/2.30.5 (94 files, 6.8MB) *
  Poured from bottle using the formulae.brew.sh API on 2024-07-15 at 16:53:39
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/s/sdl2.rb
License: Zlib
==> Dependencies
Dependents: 1
==> Options
--HEAD
	Install HEAD version
==> Downloading https://formulae.brew.sh/api/formula/sdl2.json
==> Analytics
install: 56,469 (30 days), 192,281 (90 days), 611,340 (365 days)
install-on-request: 4,518 (30 days), 18,039 (90 days), 75,301 (365 days)
build-error: 11 (30 days)
joevt@Joes-Giga-Mac ~ % 

[thecloud]

What kind of mouse are you using?
How many displays do you have connected to the host Mac?

Thinking about these two questions helped me narrow down the issue. It's not the version of libsdl2 (2.30.9, installed via MacPorts) or host system version. It's that I'm using Screen Sharing (i.e. VNC) to drive the host machine which runs DPPC, and it apparently does not move the mouse cursor in the same way that the physical trackpad on the host machine does.

If I use the trackpad on the host Mac which is running DPPC, then SDL's cursor grabbing behaves exactly as you describe, and the cursor does not leave the bounds of the window while it is grabbed. However, if I use Screen Sharing to connect to that host Mac, moving the host Mac's cursor with my remote machine's trackpad, then SDL's cursor grabbing does not pin the cursor to the window.

I've been running QEMU instances this way for a long time, but I have them set up with virtual tablet devices that use absolute rather than relative coordinates, and that makes all the difference.

[joevt]

It's that I'm using Screen Sharing (i.e. VNC) to drive the host machine which runs DPPC, and it apparently does not move the mouse cursor in the same way that the physical trackpad on the host machine does.

I think I remember running into this problem when I was using Screen Sharing to run DingusPPC on my Quad G5 (Mac OS X 10.5.8 PPC 32 host).

This is what I wrote about that:

There's a couple issues with grabbing the cursor:
1) SDL2 in 10.5.8 does not prevent the host mouse cursor from moving outside the focused window. Actually, this is only a problem with Apple Screen Sharing or Microsoft Remote Desktop. This is documented in the SDL2 source. The grabbed cursor works fine when not using screen sharing to control the PPC host.
2) 10.5.8 doesn't have the mouse emoji character or doesn't allow using emojis in the title bar of a window.

[joevt]

DingusPPC does have a full screen mode. I suppose moving the mouse out of the window area in that case will be more difficult.
Press Control-F. It cycles between window mode, fullscreen integer scale mode, fullscreen with BARs, fullscreen with no BARs.
You can increase or decrease zoom with Control-- and Control-+. It works in window and fullscreen mode.

[thecloud]

DingusPPC does have a full screen mode. I suppose moving the mouse out of the window area in that case will be more difficult.
Press Control-F. It cycles between window mode, fullscreen integer scale mode, fullscreen with BARs, fullscreen with no BARs.
You can increase or decrease zoom with Control-- and Control-+. It works in window and fullscreen mode.

Thanks! The fullscreen-with-bars mode (pressing ctrl-F twice) does improves usability, since there's less space outside the emulated display area for the cursor to end up in. And in fullscreen, accidentally clicking outside the display area doesn't bring some other app to the front.

Glad that DPPC is still being actively developed. Will watch this thread for more updates to the to-do list!

[joevt]

Thanks! The fullscreen-with-bars mode (pressing ctrl-F twice) does improves usability, since there's less space outside the emulated display area for the cursor to end up in. And in fullscreen, accidentally clicking outside the display area doesn't bring some other app to the front.

If full screen with bars is not the same as full screen integer scale, then you should make sure Control-S has smooth scaling toggled on so that you don't see any rows or columns that are a different width.

If the two modes were the same, then Control-F would skip full screen integer scale and the next mode would be full screen with no BARs.

We'll eventually have an emulated display card that can do any resolution - such as matching the host display size and aspect ratio, etc, and any color depth and any number of displays.