ShuriZma
/
dolphin
mirror of https://github.com/dolphin-emu/dolphin.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated IOS Overview (markdown)

Leo Lam 2017-11-19 17:14:17 +01:00
parent b1242efef9
commit 57908d66e2
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
IOS-Overview.md

@ -28,7 +28,7 @@ Differences between IOS versions are typically not emulated, since they are most
| OH1 | Complete |
| USB | Not implemented (internal). |
| USB_HID (v4) | Complete |
| USB_HID (v5) | Stubbed. Used by Dragon Quest X. |
| USB_HID (v5) | Mostly complete |
| USB_HUB | Not implemented (internal?) |
| USB_MSC | Not implemented (internal) |
| USB_SHARED | Not implemented (internal) |
@ -52,14 +52,14 @@ Differences between IOS versions are typically not emulated, since they are most
Dolphin currently runs the entirety of IOS HLE on a single thread, including blocking IO such as NAND filesystem access and networking tasks. This causes terrible performance or stuttering depending on what modules are actually used, and more generally affects all titles using the NAND to a lesser extent.
The difficulty of implementing threading is that IOS uses many threads internally and there is internal IPC. This means that if the ES thread is blocked for example, the USB thread may just carry on serving IPC requests and processing USB transfers. A naïve implementation that just moves IOS HLE to a single separate thread will either cause issues (as requests can time out) or be ineffective at eliminating performance issues (if most requests still end up blocking). Additionally, any threaded implementation must still maintain determinism.
The difficulty of implementing threading is that IOS uses many threads internally and there is internal IPC. This means that if the ES thread is blocked for example, the USB thread may just carry on servicing IPC requests and processing USB transfers. A naïve implementation that just moves IOS HLE to a single separate thread will either cause issues (as requests can time out) or be ineffective at eliminating performance issues (if most requests still end up blocking). Additionally, any threaded implementation must still maintain determinism.
* [ ] Implement more differences between versions.
We should only expose resource managers that exist in the running version. This may seem irrelevant, until you remember that a game was relying on differences between IOS versions for their anti-piracy system. This applies to ioctls too.
## [ES](https://wiibrew.org/wiki//dev/es) TODO
* [ ] [Title limits and consumption tracking.](https://emucross.com/dolphin-developer-resurrects-incomplete-wii-ios-feature/)
* [ ] [Title limits and consumption tracking.](https://emucross.com/dolphin-developer-resurrects-incomplete-wii-ios-feature/) (really low priority)
# References
* [WiiBrew](https://wiibrew.org/wiki/IOS) is probably the best (and only) reference for IOS.