Allow optional conversion & eol for OSREPORT

[WinterMute]

Recently I added code in libogc to allow homebrew to send OSREPORT messages to Dolphin but it seems more sensible to use \n to end the message and stick with UTF8 encoding on the application side. I presume that commercial games have left debug messages which follow this format? I've used variables here to default to \n and no conversion from Shift JIS but my intention is to add checkboxes in the UI to set this as appropriate & store it as a setting.

I was thinking about adding either checkboxes or dropdowns to the the log window here https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/DolphinQt/Config/LogWidget.cpp#L140 but I'm not entirely sure of the best way to get settings configured there back to the code in EXI_DeviceIPL. Could someone point me in the right direction?

[sepalani]

I might be completely wrong and EXI-IPL isn't my forte but isn't this a "hack" since the logging system automatically append a newline? Otherwise, could it be something done by the GC/Wii SDK?

AFAICT, most of the games I have with debug message strings are \0, \n\0 or \r\n\0 terminated. I don't remember having debug strings which are only \r\0 terminated.

[JosJuice]

I was thinking about adding either checkboxes or dropdowns to the the log window here https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/DolphinQt/Config/LogWidget.cpp#L140 but I'm not entirely sure of the best way to get settings configured there back to the code in EXI_DeviceIPL. Could someone point me in the right direction?

For an example of how to add a setting, see 23ad07b3688a1145c22ac72dfc35b0d2f9f834ff. (Skip the change in IsSettingSaveable.cpp – it isn't needed nowadays. Adding the setting to the Android code is optional.)

[Pokechu22]

I presume that commercial games have left debug messages which follow this format?

Yes, e.g. Super Mario Galaxy and Super Mario Sunshine both have debug messages that end up here (but the way you boot the game matters; if you use the Wii menu or gamecube menu then they won't log anything because they won't think they're in debug mode). Super Mario Galaxy in particular logs several DSP-related messages in Japanese on startup.

~~Super Mario Galaxy's strings seem to be \r\0-terminated, e.g. \rRevolution OS\r\0 at 805da870 (note the \r at the start, which does result in a blank osreport line) and ♪JDSP/Boot:: ＤＳＰとの接続に成功しました\r\0 at 8054d37c on the US release.~~ This is wrong, I mixed up the encoding of \r and \n and \n is used here (but apparently it's converted to \r when it's being written to UART?)

The \r endings do seem weird and it'd probably be better to handle both \r and \n generically (without needing to configure it), probably by treating \r on its own, \n on its own, or \r\n all as message separators (and ignoring trailing ones).

UTF-8 does seem like a good option to have.

[WinterMute]

I presume that commercial games have left debug messages which follow this format?

Yes, e.g. Super Mario Galaxy and Super Mario Sunshine both have debug messages that end up here (but the way you boot the game matters; if you use the Wii menu or gamecube menu then they won't log anything because they won't think they're in debug mode). Super Mario Galaxy in particular logs several DSP-related messages in Japanese on startup.

~Super Mario Galaxy's strings seem to be \r\0-terminated, e.g. \rRevolution OS\r\0 at 805da870 (note the \r at the start, which does result in a blank osreport line) and ♪JDSP/Boot:: ＤＳＰとの接続に成功しました\r\0 at 8054d37c on the US release.~ This is wrong, I mixed up the encoding of \r and \n and \n is used here (but apparently it's converted to \r when it's being written to UART?)

This is interesting and kind of suggests old school serial tty where commands were sent when user pressed return & sent \r then the other end responded with \n to signal ready for another transmission. (I only know this because I used to service minicomputers and their vt52/100/220 terminals. :) )

I think it's probably reasonable in that case for libogc uart code to just translate \n to \r on the fly and leave that part of Dolphin alone. Will simplify things to just have the option for encoding then.

The \r endings do seem weird and it'd probably be better to handle both \r and \n generically (without needing to configure it), probably by treating \r on its own, \n on its own, or \r\n all as message separators (and ignoring trailing ones).

UTF-8 does seem like a good option to have.

[AdmiralCurtiss]

What's the state here?