The vector was not constructed with the proper size, which results in a
buffer overflow as we were using memcpy.
This commit fixes that mistake and also uses a safer way of copying the
ticket view data (std::vector::insert instead of memcpy).
This commit fixes ES_Launch to work mostly the same as the real IOS
(except temporary, internal files such as /sys/launch.sys and title
handling; the latter will be handled in a future PR).
First of all, this adds two IOS functions, which correspond to two
IOS syscalls: 0x41 (boot_ppc) and 0x42 (boot_ios).
boot_ios() writes the new version to 0x3140, loads the new kernel,
which then proceeds to reinit IPC and load modules as part of its
boot process. Note that this doesn't include writing to any of the
other constants in the 0x3100 region.
In Dolphin, this is implemented by changing the active IOS
version variable, writing to 0x3140 and resetting all devices. This
has exactly the same effect as the real syscall.
The other syscall, boot_ppc(), writes code to the EXI boot buffer,
pokes all constants to memory before bootstrapping the PPC with a
binary from the NAND.
We skip the low level stuff and just load the DOL to memory (and set
the PPC's PC to 0x3400), which is essentially what IOS does.
The other change is mostly related to how ES_Launch is handled.
With a real IOS, if the launched title type is 00000001 (system) and
the title is not 1-2 (System Menu), ES calls boot_ios().
Otherwise, ES handles the launch as a PPC title. It reads the TMD
to determine the required IOS version. If it is the same, boot_ppc()
is called directly. If not, ES saves the title to launch to the NAND
before launching the new IOS. After the new IOS has finished booting,
it will notice the flag and then launch the requested title.
What this commit does is really just implement this logic into IOS HLE.
The result is a fix for a regression introduced by SetupMemory,
where reloading an IOS would have overwritten some OS constants.
This fixes booting games from the disc channel.
No idea why this wasn't implemented whereas ES_DeleteTicket and
ES_DeleteTitleContent were.
This probably fixes title deletion in old System Menus, and maybe
the new ones as well in some cases; I've seen 4.3 use this ioctlv.
On startup, wxWidgets pops up an assertion error:
> ./src/osx/menu_osx.cpp(648): assert ""IsAttached()"" failed in
> Refresh(): can't refresh unatteched menubar
Starting in #4916, upon startup wxWidgets pops up an assertion error:
> ./src/common/cmdline.cpp(527): assert ""Assert failure"" failed in
> FindOptionByAnyName(): Unknown option verbose
Fix this by overriding wxApp::OnCmdLineParsed to disable the default
handling (since we also disable the default options in
DolphinApp::OnInitCmdLine).
We already have a TMDReader, so let's actually use it.
And move ESFormats to IOS::ES, since it's definitely part of IOS.
This adds a DiscIO dependency on Core which will be fixed in a
follow-up PR.
The /tmp directory is cleared every time IOS boots up (when the FS
driver is initialized), *not* when /dev/fs is opened.
Although this should have no effect, it fixes the case where files
could be left in /tmp and seen before opening /dev/fs.
Gets some constants out of the ControllerEmu namespace, and modifies
ControlGroup so that it uses the enum type itself to represent the
underlying type, rather than a u32 value.
As this is a base class with virtuals, there needs to be an out-of-line
function definition to prevent the vtable of the class being placed within
every translation unit it's used in (i.e. every JIT implementation).
Getting and setting configuration from the base config layer are common
and repetitive tasks. This commit adds some simpler to use functions to
make the new system easier to work with.
Config::Get and Config::Set are intended to make switching from
SConfig a bit less painful. They always operate on the main system.
Example usage:
// before
auto base_layer = Config::GetLayer(Config::LayerType::Base);
auto core = base_layer->GetOrCreateSection(Config::System::Main, "Core");
u8 language;
core->Get("Language", &language, 0);
SetData("IPL.LNG", language);
// now
auto base_layer = Config::GetLayer(Config::LayerType::Base);
auto core = base_layer->GetOrCreateSection(Config::System::Main, "Core");
SetData("IPL.LNG", core->Get<u8>("Language", 0));
// or simply
SetData("IPL.LNG", Config::Get<u8>("Core", "Language", 0));
It is kind of silly to connect all of the configured Wii remotes (from
the user config; NOT netplay assigned remotes), then connect/disconnect
additional Wii remotes *after* the core has booted.
(The bWii check has been removed, because it's actually unneeded;
m_wiimote_map is always usable regardless of bWii. And we can't get
info about the currently running game without booting the core with our
current config system…)
This should fix Netplay trying to connect all configured Wii remotes.
Fixes a logic bug I introduced as part of #4942. We were not
handling the "read past EOF" case correctly, which caused
requested_read_length to underflow in some cases.
Also fixes a comparison (though this is unlikely to change anything).
Instead, the JitInterface namespace functions should be used instead. This
gets rid of all usages of the JIT global from the wxWidgets UI code.
The null check isn't needed as the JIT core would already need to be
initialized in order to be within a paused state. The null check is just a
remnant from 2011 that existed before the check for a paused state was
added.
This changes the read request handler to work just like IOS:
* To make things clearer, we now return early from error conditions,
instead of having nested ifs.
* IOS does an additional check on the requested read length, and
substracts the current seek position from it, if the read would
cause IOS to read past the EOF (not sure what the purpose of this
check is, but IOS does it, so we should too).
* The most significant one: IOS does *not* return the requested read
length, or update the file seek position with it. Instead, it uses
the *actual* read length.
As a result of simply doing what IOS does, this fixes _Mushroom Men_.
The game creates a save file, reads 2560 bytes from it, then
immediately writes 16384 bytes to it. With IOS, the first read does not
change the seek position at all, so the save data is written at
offset 0, not 2560. With Dolphin, the read erroneously set the
seek position to 2560, which caused the data to be written at
the wrong location.
Behavior confirmed by comparing IPC replies with IOS LLE and by looking
at the FS module in IOS.
What we actually care about is whether it's a GCZ file,
not whether it's compressed. (This commit doesn't change
the behavior, since the beginning of CompressSelection
discards items that aren't BlobType::GCZ or BlobType::PLAIN.)
- There's no clear definition of what it means for a GC/Wii game
to be compressed. GC games in GCZ are obviously compressed,
but what about formats like WBFS and CISO that just discard data?
- Hardcoded colors might have bad contrast with the used theme.
- It feels Windows XP to me.
YYCJ is one of the last titles to be completely broken in Dolphin.
It would hang right after the Wii remote screen. Looking at the
game's debug messages reveals that it was failing to find some of
its files.
IOS LLE booted the game just fine, which confirmed that it was an issue
with IOS HLE.
By comparing the ioctlv requests and responses with IOS, it turns out
that one of the very first ES replies was different between IOS HLE and
IOS: there was a mismatch for the content fd returned by ES.
Changing the initial content FD to what IOS returns fixes the issue.
IOS
000000: 00 00 00 08 00 00 00 00 00 00 00 07 00 00 00 09 ................
000010: 00 00 00 01 00 00 00 00 01 38 66 f0 00 00 00 20 .........8f....
000020: 00 00 00 00 00 00 00 00 00 00 00 00 81 36 d3 18 .............6..
000030: 81 36 d3 18 00 00 ff ff ff ff ff ff ff ff ff ff .6..............
Dolphin
000000: 00 00 00 08 06 00 00 00 00 00 00 07 00 00 00 09 ................
000010: 00 00 00 01 00 00 00 00 01 38 66 f0 00 00 00 20 .........8f....
000020: 00 00 00 00 00 00 00 00 00 00 00 00 81 36 d3 18 .............6..
000030: 81 36 d3 18 00 00 ff ff ff ff ff ff ff ff ff ff .6..............
So where did 0x6000000 come from?
4bd5674 changed "Wiimote" to "Wii Remote" in the GUI
(intentionally) but also did the same change for two INI
keys (seemingly unintentional, breaks backwards compatibility,
and is inconsistent with the INI's filename). This commit
reverts the INI keys but not the GUI strings.
This commit uses the same approach as cbd539e used for GameCube
sticks (but I made sure to avoid the bug that 56531a0 fixed).
Given a std::map can't have duplicate keys, iterating over the map
explicitly isn't necessary, and find() can just be used instead.
Also, instead of manually calling push_back() for every entry to
be added, the range constructor of std::vector can be used instead to add
the whole range all at once.
Léo Lam