Add an overview on IOS emulation

IOS-Overview.md

@@ -0,0 +1,30 @@
+IOS is the Wii's internal operating system running on an ARM coprocessor. Games run on the bare metal but rely on IOS for essential services like DI, USB and power state management.
+
+# Emulation
+
+Dolphin does not emulate the Starlet coprocessor at all, except the IPC registers, which are however hardcoded to be routed to IOS HLE. This means that Dolphin is unable to run any IOS, and instead HLEs them. This works fine with anything that doesn't rely on raw hardware access or patching IOS.
+ 
+Differences between IOS versions are typically not emulated, since they are mostly minor and do not affect anything. The USB modules are currently the only exception.
+
+# HLE Overview
+
+## General TODO
+* [ ] 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.
+
+* [ ] Threading.
+
+  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.
+
+## [ES](https://wiibrew.org/wiki//dev/es) TODO
+* [ ] [Title limits and consumption tracking.](https://emucross.com/dolphin-developer-resurrects-incomplete-wii-ios-feature/)
+
+* [ ] Drop the direct WAD launch hack.
+
+  Keeping it forces us to be inefficient since we have to read tons of extra files or keep the entire WAD in memory, and possibly decrypt contents on every single boot. It also requires handling WAD files as a special case and encourages sloppy emulation, as inconsistent results will be returned. Additionally, getting rid of it will us to reuse the ES_LaunchTitle logic much more easily.
+
+# References
+* [WiiBrew](https://wiibrew.org/wiki/IOS) is probably the best (and only) reference for IOS.