Merge with cebix?

[SegHaxx]

Okay, so maybe the cebix repo isn't dead? I moved to this fork because it had the 64bit slirp fixes already, and generally seemed to work better. Basilisk II JIT works perfectly in this tree, and... does not in cebix. The cebix tree doesn't seem to compile in MSYS2 at all.

Is there other forks I should know about?

It's unfortunate this fork broke history with the cebix repo. I've moved my Flatpak work to the cebix tree to see how that works out.

At this point the way forward seems to be to hand-pick the working stuff from this tree and port it over to cebix?

The CI stuff is nice. :)

[ianfixes]

I've had some correspondence with the cebix maintainers about doing this, which is unfolding slowly but steadily.

In my perfect world, macemu would be split into entirely separate repositories (cxmon, BasiliskII, and SheepShaver) each with its own multi-platform CI. Possibly, a new repo that comprises the common elements between BasiliskII and SheepShaver. This would mostly be an attempt to keep the build matrix from spiraling out of control, especially when pull requests would normally touch only one of those codebases.

This raises a second requirement, which is that the hosting would have to move from a monorepo in cebix to a GitHub organization. That would empower the present maintainer (or maintainers) to create new repos and/or configure CI without having to work through the original owner -- i.e. the exact thing that they'd have to do to accept the work done in this repo.

My preferred solution is to turn this GitHub org over to the current set of people with write permissions on cebix/macemu, whether they want to forcibly replace the separate cxmon and macemu repos here with the latest revision of the upstream monorepo or find a way to work all the new changes into the tree. But that leaves a lot of documentation to do (to point users to the new location), presumes that @cebix would be comfortable with such a change, and will affect an entire community of existing users/contributors that has existed for many years.

I expect the change to come slowly, if at all. Thanks for opening this issue as I'm looking forward to where it might go.

[webspacecreations]

https://github.com/kanjitalk755/macemu is the other repository getting regular updates.

Although last updated mid-2012, it appears that SheepShear (https://github.com/amade/sheepshear) achieved the objective of code consolidation (Done Items: Basilisk II code integrated). Whether that means that SheepShear is/was able to emulate both 68K and PPC isn't immediately obvious, but if that IS what it means, then a sensible path (based on previously expressed objectives) would be to take SheepShear and apply useful patches & updates to get an updated, single code-base from which further improvements can be made.

With working MMU code in both QEMU and PearPC, as well as PPC projects like https://github.com/dingusdev/dingusppc, https://github.com/dolphin-emu/dolphin, https://github.com/yui-konnu/PPC-Altivec-IDA, https://github.com/marakew/emuppc and Voodoo Graphics hardware emulation (https://github.com/jenshemprich/MacGLide), there are MANY opportunities for substantial improvement (and not just regular maintenance). The point really is that the energy spent on divergent paths could be combined to create a renewed project with a singular and substantial objective.

QEMU is slow on hardware like Pi4 (and sound seems to still be a lingering issue in general), but QEMU is getting regular updates and benefits from contributions from a larger dev pool. If the goal of this fork (or other repos) is simply to get regular updates, then this project is deprecated by QEMU. I think this would be a shame as I believe there are benefits to a more purpose-oriented emulator.

I'll delve into what state the SheepShear codebase is currently in over the coming week or so to determine whether some of the assumptions I've made here are accurate.

[webspacecreations]

It appears that SheepShear (back in the day) was an effort to integrate more modern Basilisk II code into a stagnated SheepShaver codebase, rather than merging the functions of both (i.e. 68k+PPC). Might have some good ideas, but I have to assume the SheepShaver maintainer(s) have since copied whatever good ideas SheepShear contributed.

That being said, it seems there are a couple “low hanging fruit” options for improving Basilisk II & SheepShaver:

1.) On the Basilisk II side, UAE code along with “glue code” is used to emulate 68k processors. That code is really rather old and taking a look at what’s been done since in WinUAE (https://github.com/tonioni/WinUAE) might allow for some notable improvements in Basilisk II.

2.) On the SheepShaver side, Kheperix (dating back to 2005) is being used for PPC emulation. The PearPC developer apparently reviewed the code and has this to say in April 2004: “I looked at the source code of Kheperix by Gwenole Beauchesne [https://github.com/gbeauchesne]. Kheperix is a part of SheepShaver, and available as a separate project. Little documentation is available and even the source code doesn't make it easy to understand what exactly Kheperix does. It looks like it is a recompiler from PowerPC to x86. It is derived from QEMU, as it contains many references to it, but all frontends other than PowerPC and all backends other than x86 have been removed.”

Depending upon how much Kheperix factors into PPC emulation in the SheepShaver codebase, repeating the process with modern QEMU code might improve PPC emulation in SheepShaver. The PearPC developer wasn’t entirely sure what Kheperix was doing and the Kheperix repository seems to be offline. Someone could reach out to the original maintainer (linked above) on Github to find out whether a modern derivation of “Kheperix” from QEMU would offer any advantage (i.e. worth the effort).

[SegHaxx]

Well the problem everyone seems to be having with JIT is that it sits on a house of cards of janky memory mapping that causes crashes. I'm sitting on a patch that fixes all this in Basilisk II, its just been a problem figuring out what repo to merge this work into lol.

I've taken the kanjitalk755 repo as it seems to be where the current SDL2 work is happening, and merged cebix into it, picking up a few features from there. near as i can tell this covers most all recent development. I'm becoming very well versed in merging and rebasing patches....

I've rebased my patches on that, and it has been giving me rock solid JIT on i386/x86_64. With a solid base to work on, things like "merge uae4arm's JIT" so we can have JIT on aarch64 can then happen. :)

I really need to polish it up and release but I'm currently stymied by Flatpak seeming to enforce W^X protections, so JIT still doesn't work there. https://en.wikipedia.org/wiki/W%5EX

Working JIT is my main goal for the next Flatpak release.

[SegHaxx]

my kanjitalk755 merge with cebix is in fact live in my master tree: https://github.com/SegHaxx/macemu-flatpak

[webspacecreations]

@SegHaxx Thanks for sharing the repository URL. Your situation is a pattern I'm seeing with many of the sporadically updated repos and the way search works on GitHub, contributions like this fly under the radar (unless you fork which only further fragments resources). I think it'd be worth opening issues in the other repos to see whether at least one will uptake your improvements.

Getting JIT for ARM would be a major achievement.

[webspacecreations]

@SegHaxx the kanjitalk/macemu maintainer seems open to including patches you've made, but isn't clear on what those patches are and what they do. I've taken a look at your code and the substantial bits seem to be around patching ROM and 24-bit addressing in BasiliskII, but I expect you'll be able to explain much better what the code is doing and why it's worth including. It sounds like your changes are worthwhile, but I don't want to make any inaccurate representations. If you think they should be wrapped into the kanjitalk/macemu repo, would you mind posting a short write-up there (https://github.com/kanjitalk755/macemu/issues/85)?