Programming my own Mac emulator

[mcayland]

A bit of a bump, but Mihai fixed up Mac OS X. Now it displays properly (mostly). We've looked into BeOS a little bit and it seems to be quite the challenge, since it expects the 53c94 emulation to be accurate.

If it's any consolation I had the same issue with QEMU's ESP emulation and ended up doing almost a complete rewrite to allow MacOS to boot under the Q800 machine. Are the problems related to mixed DMA and FIFO transfers or something else?

[kataetheweirdo]

I think we fixed those problems (seems to be FIFO transfers), but now we have issues in the ESCC emulation to fix. But just to be sure, here's the problem we were having, paraphrased from maximumspatium:

53c9x SCSI controllers implement a couple of multi-step commands (Select with ATN for example). Those chips will generate a single interrupt when a multi-step command is completed. SW can then read the Sequence Step register to determine how far the internal sequencer was able to execute some command. Sequence step counter is implemented internally using SS0-SS2 bits. They can be read via Sequence Step and FIFO flags registers.

NCR and AMD docs for the chips tell us that reading the Interrupt Status register while INT is asserted will clear the Interrupt, Status and Sequence Step registers. That behavior was implemented in DingusPPC.
I was surprised that the 53c94 driver in BeOS refused to work with my 53c94 emulator resulting in a hang while transferring data using PIO.

I then found out the cause. The [BeOS driver] reads the FIFO Flags register and issues the Transfer command only if the obtained register value is not zero. The FIFO Flags register returns a combination of the current FIFO position and SS0-SS2 bits. FIFO position will likely be zero at this point. If SS0-SS2 bits are also zero the driver will hang. I fixed the above problem by leveraging an internal variable for the SS0-SS2 bits that won't be cleared when the Interrupt register is read. They are cleared at the beginning of a multi-step command. Each step will update both SS0-SS2 bits and the Sequence Step register whose value is held in a separate variable. All other commands don't touch the SS0-SS2 bits.

[adespoton]

I think we fixed those problems (seems to be FIFO transfers), but now we have issues in the ESCC emulation to fix. But just to be sure, here's the problem we were having, paraphrased from maximumspatium:

53c9x SCSI controllers implement a couple of multi-step commands (Select with ATN for example). Those chips will generate a single interrupt when a multi-step command is completed. SW can then read the Sequence Step register to determine how far the internal sequencer was able to execute some command. Sequence step counter is implemented internally using SS0-SS2 bits. They can be read via Sequence Step and FIFO flags registers.

NCR and AMD docs for the chips tell us that reading the Interrupt Status register while INT is asserted will clear the Interrupt, Status and Sequence Step registers. That behavior was implemented in DingusPPC.
I was surprised that the 53c94 driver in BeOS refused to work with my 53c94 emulator resulting in a hang while transferring data using PIO.

I then found out the cause. The [BeOS driver] reads the FIFO Flags register and issues the Transfer command only if the obtained register value is not zero. The FIFO Flags register returns a combination of the current FIFO position and SS0-SS2 bits. FIFO position will likely be zero at this point. If SS0-SS2 bits are also zero the driver will hang. I fixed the above problem by leveraging an internal variable for the SS0-SS2 bits that won't be cleared when the Interrupt register is read. They are cleared at the beginning of a multi-step command. Each step will update both SS0-SS2 bits and the Sequence Step register whose value is held in a separate variable. All other commands don't touch the SS0-SS2 bits.

Wasn't that ESCC emulation issue the same thing Arbee was talking about a month or so ago for MAME PPC emulation? Seems to me that all three of you are starting to narrow in on the same implementation issues?

[andreas_g]

Maybe have a look at Previous. It has a quite accurate ESP simulation: https://sourceforge.net/p/previous/code ... /src/esp.c

[kataetheweirdo]

We've fixed up SCSI emulation to the point where MkLinux's bootstrap fully loads up, but there is an issue in vmlinux that prevents the OS itself from running.

From powermax:

At the very end of its main mach_msg_server is called that initiates an interaction with some server, presumably located in the vmlinux image.
It then enters some spin-waiting loop that never exits. Looks like it's waiting for some HW response that is never delivered.

[adespoton]

We've fixed up SCSI emulation to the point where MkLinux's bootstrap fully loads up, but there is an issue in vmlinux that prevents the OS itself from running.

From powermax:

At the very end of its main mach_msg_server is called that initiates an interaction with some server, presumably located in the vmlinux image.
It then enters some spin-waiting loop that never exits. Looks like it's waiting for some HW response that is never delivered.

Tricky; is it stuck in a polling loop? Could it be possible to disable different pieces of virtual hardware and see if that affects the behaviour? Just thinking that if we can eliminate everything down to a single piece of simulated hardware, maybe we could find out what output is missing that it's expecting....

[kataetheweirdo]

We've partially solved this. Turns out there were errors with timer emulation in the VIA Cuda. It can boot up MkLinux DR1 now, but there's a good chance it can freeze during boot-up. Powermax thinks this may a result of AMIC/VIA interrupt handling issues.

[kataetheweirdo]

We've managed to get Quake running, but we have an interesting bug to note.

This one has been very persistent and it seems to revolve around sound playback issues.
I'm looking into the Power Mac 6100 emulation first and I notice these two entries right before it freezes:

WARN| Unknown AMIC register read, offset=14011
INFO| AMIC Sound In Ctrl updated, val=4

Trying to implement Sound In DMA doesn't seem to be working though.

[kataetheweirdo]

We've got some updates in that allow us to finally run BeOS. Pippin emulation is also improving.

[gsteemso]

The most recent commit appears to be a duplicate of one from most of a year ago. I had to git reset --hard to the second-to-last commit, dated June 21, to get a working build. What's going on there?

[joevt]

The most recent commit appears to be a duplicate of one from most of a year ago.

Which two commits are you comparing? The latest commit has title "Add Alchemy machines emulation.".

This is the first time Alchemy has been added. Maybe you are referring to a previous commit that added a different machine type? Gazelle?

I had to git reset --hard to the second-to-last commit, dated June 21, to get a working build. What's going on there?

When you checkout a commit that adds new source files, you need to rebuild the "make" files or the IDE project files using cmake before you can compile with the new changes.

[gsteemso]

Which two commits are you comparing? The latest commit has title "Add Alchemy machines emulation.".

Well, here is the relevant excerpt from `git log`:

Code: Select all

  commit 103a06536cf4869279f9532e57873255b53271f9
  Author: dingusdev <[email protected]>
  Date:   Fri Jun 26 07:44:38 2026 -0700
  
      Small PPC Floating-Point fixes
  
  commit f1472e6f0e6db26be12407d9dc9d8a50be0d99e0
  Author: Maxim Poliakovski <[email protected]>
  Date:   Sat Nov 15 22:09:47 2025 +0100
  
      Add Alchemy machines emulation.
  
  commit 4d9f6f33eed01bd253582e85b2128b1a1684e3d4
  Author: Maxim Poliakovski <[email protected]>
  Date:   Sun Jun 21 16:19:52 2026 +0200
  
      maciotwo: support partial writes to the control registers.

I'm not sure why the Alchemy addition was dated 2025-11-15, but it failed to build correctly. The most recent build (not shown in the above log excerpt) is fine – well, I’m still having issues with it, but they appear mostly self-inflicted and I have filed a bug report on GtHub for the one that clearly wasn’t.

When you checkout a commit that adds new source files, you need to rebuild the "make" files or the IDE project files using cmake before you can compile with the new changes.

Oh yes. I deleted my build directory’s contents entirely and redid the whole process from the beginning – Cmake and then make, as directed for new installs. That’s why I felt relatively confident that it wasn’t anything I had done or not done.

[joevt]

Well, here is the relevant excerpt from `git log`:

Code: Select all

  commit 103a06536cf4869279f9532e57873255b53271f9
  Author: dingusdev <[email protected]>
  Date:   Fri Jun 26 07:44:38 2026 -0700
  
      Small PPC Floating-Point fixes
  
  commit f1472e6f0e6db26be12407d9dc9d8a50be0d99e0
  Author: Maxim Poliakovski <[email protected]>
  Date:   Sat Nov 15 22:09:47 2025 +0100
  
      Add Alchemy machines emulation.
  
  commit 4d9f6f33eed01bd253582e85b2128b1a1684e3d4
  Author: Maxim Poliakovski <[email protected]>
  Date:   Sun Jun 21 16:19:52 2026 +0200
  
      maciotwo: support partial writes to the control registers.

I'm not sure why the Alchemy addition was dated 2025-11-15, but it failed to build correctly. The most recent build (not shown in the above log excerpt) is fine – well, I’m still having issues with it, but they appear mostly self-inflicted and I have filed a bug report on GtHub for the one that clearly wasn’t.

Hmm, I meant to answer this a week ago:

"Small PPC Floating-Point fixes" is from after you reported a problem.

"Add Alchemy machines emulation." has a date of 2025 because that's when it was added to a local repository. Are you saying this is a duplicate just because of the date? You haven't actually found a duplicate?

I have commits in my repository from 2023 that have not been added to the main repository. Sometimes I make updates to my commits using Interactive Rebase -> Fix Up which doesn't modify the date.

Perhaps the new commit is missing an include that is required by some build environments but not by all of them.

If you are still having questions or problems, let us know.

[gsteemso]

I did not realize that the date of a commit was fixed upon its original creation rather than when it was included into the trunk. My mistake! That was clearly unrelated to the fact of the repo, as of that commit, not building on my machine. As you note, development has since moved on, and current builds are just fine; please disregard.

[kataetheweirdo]

I've merged quite a few fixes recently for all sorts of things - from MMU optimizations, floating point fixes, DBDMA fixes, etc.

Thus far, we can indeed boot Mac OS X Tiger. The caveat being that I had to use safe boot. It's pretty slow, but that it can boot at all is nothing short of impressive if you ask me.

[adespoton]

I've merged quite a few fixes recently for all sorts of things - from MMU optimizations, floating point fixes, DBDMA fixes, etc.

Thus far, we can indeed boot Mac OS X Tiger. The caveat being that I had to use safe boot. It's pretty slow, but that it can boot at all is nothing short of impressive if you ask me.

Well done! What hardware are you emulating to hit the Tiger target? I presume it's not the 6100.... Something New World with xpostfacto? Or something new enough to actually be supported?

[joevt]

Well done! What hardware are you emulating to hit the Tiger target? I presume it's not the 6100.... Something New World with xpostfacto? Or something new enough to actually be supported?

iMac. Using the infinitemac 10.4.11 disk image (from GitHub).

With my fork, you can set it to have 2 GiB of RAM but I need to fix some SDL3 changes that affect the display.