Dolphin, the GameCube and Wii emulator - Forums

Pangu can't "apply the RWX patch" because kernel patch protection means you can't apply any patches [to the kernel].

So after a while working on some App Store stuff, I caught up on some other iOS emulation projects (more specifically Play! and PPSSPP). There is this excellent post by angelXwind (a prominent figure in the JB community) that you can read if you want more details, but here's the highlights:

1. KPP ("rootless"), as Fiora said, prevents the kernel from being patched
2. Pangu9 does some black magic to achieve "patching the kernel" without actually patching the kernel
3. vm_protect (the thing that is patched to allow RWX) isn't changed in this magic
4. Pangu9 actually does patch the kernel on 32-bit devices, so we can run JITs there... however, that is pretty much useless to us as the armv7 JIT was abolished last year
5. There exists a MAP_JIT flag which you can pass to mmap, though nobody has ever really used it before ...well, except for Apple. This only works because of Pangu9's magic somehow so it doesn't work on non-jb'd devices.
   

Of course, even by some voodoo or something we manage to disable KPP, the other big problem (memory limit) still is yet to be solved. Speaking of the virtual memory limit issue, I had a thought earlier before this rootless mess happened: maybe we could patch the kernel to remove the restriction (or hack in the dynamic_pager swap system, which would be hell on the NAND but still)? I haven't measured Dolphin's memory usage before, but if it can somehow fit in the RAM sizes of 2GB (iPhone 6S) or 4GB (iPad Pro), then it might work. (I'm not sure that it will happen on devices with 1GB of RAM.)

This is completely unrelated to everything else but it was brought to my attention that someone was apparently interested in this project and uploaded a copy of my work to their repo. That's interesting. Considering that he "couldn't find the files" for the iOS part of Dolphin, I went back to look at it and tbh it was just a mess. I need to start over on a fresh slate and make notes on what I did... (Also, perfect example of how weird it was: I set ANDROID to true to build for iOS.)

(I need to stop writing mini-essays when posting.)

(01-02-2016, 11:23 AM)OatmealDome Wrote: [ -> ]So after a while working on some App Store stuff, I caught up on some other iOS emulation projects (more specifically Play! and PPSSPP). There is this excellent post by angelXwind (a prominent figure in the JB community) that you can read if you want more details, but here's the highlights:

1. KPP ("rootless"), as Fiora said, prevents the kernel from being patched
2. Pangu9 does some black magic to achieve "patching the kernel" without actually patching the kernel
3. vm_protect (the thing that is patched to allow RWX) isn't changed in this magic
4. Pangu9 actually does patch the kernel on 32-bit devices, so we can run JITs there... however, that is pretty much useless to us as the armv7 JIT was abolished last year
5. There exists a MAP_JIT flag which you can pass to mmap, though nobody has ever really used it before ...well, except for Apple. This only works because of Pangu9's magic somehow so it doesn't work on non-jb'd devices.
   

Of course, even by some voodoo or something we manage to disable KPP, the other big problem (memory limit) still is yet to be solved. Speaking of the virtual memory limit issue, I had a thought earlier before this rootless mess happened: maybe we could patch the kernel to remove the restriction (or hack in the dynamic_pager swap system, which would be hell on the NAND but still)? I haven't measured Dolphin's memory usage before, but if it can somehow fit in the RAM sizes of 2GB (iPhone 6S) or 4GB (iPad Pro), then it might work. (I'm not sure that it will happen on devices with 1GB of RAM.)

This is completely unrelated to everything else but it was brought to my attention that someone was apparently interested in this project and uploaded a copy of my work to their repo. That's interesting. Considering that he "couldn't find the files" for the iOS part of Dolphin, I went back to look at it and tbh it was just a mess. I need to start over on a fresh slate and make notes on what I did... (Also, perfect example of how weird it was: I set ANDROID to true to build for iOS.)

(I need to stop writing mini-essays when posting.)

That was me, SORRY! I searched on GitHub for dophiniOS but couldn't find your repo or I would have jut forked it. I also took all of the other dolphin stuff out and just left everything related to iOS. And I gave you credit at the top of the readme, I really wasn't trying to steal your work or take credit or anything. I'll make a proper fork so it links back to you.

Anyway I've had more luck switching the emulator to interpreter mode and that is probably what we should focus on until we get something on the screen to work with (even though it'll be extremely slow) or until JIT is restored on 64bit phones.

Ah, it's okay You can't really fork my fork because GitHub doesn't allow you to, which is a shame. You'll have to download the source and upload it into a separate repo.

If we switch into interpreter on the simulator (no virtual memory limits there), I was thinking that we could be able to sort out the graphics side, but then I remembered that there's a Vertex Loader JIT that has to be active as well... I'm not sure if the simulator will allow running JITs. (maybe it will?) There's also the fact that I don't think my fork allows building for the simulator, which only gives me more reason to redo the entire thing again.

It would be nice if we could set it up to compile dolphin in Xcode. I've been working on that but Xcode really likes to make it hard. I'll post a link to a repo if I can get it working

Our vertex loader JITs can be disabled in source if they are an issue. We have a C implementation fallback for a reason.

(01-03-2016, 10:37 AM)Sonicadvance1 Wrote: [ -> ]Our vertex loader JITs can be disabled in source if they are an issue. We have a C implementation fallback for a reason.

So if we can squeeze it into 2 GB somehow and use that, maybe we could get it to work.

Alright, I spent a week's worth of free time while I was sick to just start over from the latest master. Here's the list of improvements!

• Everything in the build process is automated via shell scripts embedded in the Xcode project. Everything. Making a change to the code? All you have to do is make your change, press "Run", and the application runs. No extra work.* No copying libraries and headers around manually, as that is handled by the scripts. Overall, it's less tedious and is a better experience. This also makes it easier for new developers to just hop right in.
• Running Dolphin in the iOS Simulator is now supported! This allows us to bypass the memory issues for now and also allows us to test things like the OpenGLES renderer. (the Simulator does provide an implementation of the OpenGLES 3 environment found on iOS, though it should not be used as a 100% accurate substitute for the real thing.) The x86_64 JIT also just recently started working after some changes I made 30 minutes ago as of this post! (more specifically, I disabled PIC and set the pagezero_size linker flag when I remembered about them)
• "As few changes to the core emulator as possible" was my goal. With the help of not setting ANDROID to true, I'd say it was a success (for now). A secondary goal was to abide by the code style guidelines, and I think I've done a pretty good job so far. The biggest thing here is that I set Xcode to prefer tabs instead of 4 spaces so everything doesn't look horribly misaligned in programs that aren't Xcode.
  

Currently sitting at 71 commits and counting. I'll update the OP soon so it accurately reflects our current situation.

Oh, and here's a screenshot of the emulator running in the Simulator. It's trying to render something, but it's obviously failing somehow. This would be easier if Xcode allowed us to use the GLES debugger in the Simulator, but it only works on actual devices. (NOTE: It is NOT running on an actual device and it will not be running on one any time soon.)

The latest source code is located here: https://github.com/OatmealDome/dolphin/tree/ios
The old branch is located here, if you want to look at it for whatever reason: https://github.com/OatmealDome/dolphin/tree/old-ios

* Some setup required first. See iOSSetup.md.

It may be worthwhile to begin upstreaming bits of the code here that is clean enough to actually do so.
Just so you don't have to maintain such a large out of upstream patchset, and to make my life easier once I jump in to iOS development.
#dolphin-dev on Freenode is a good place to discuss about this if you would want.

I only really see like 5 or 6 changes that might have a chance to be merged into upstream. (Maybe I'm wrong and more could be accepted at this point in time?)
I'll hop on to IRC when I have some free time. (haven't used IRC since like 2010! it's nice to see that it's still in active use in some places)