CHIRP

Hm I see. This breaks down to two sub-problems, the first one being how to enter and display this in chirp, and the second one being how this is coded in the radio / serial traffic. The second one is probably easier to address. I understand that you can't use your radio with the Alinco software due to the restriction mentioned in #4355, but do you happen to know how this is done in their software?

I have found a solution to use here the Alinco software and also CHIRP with 57600bps (create a virtual COM port with redirection to a TCP port and than connect this TCP port to the real serial port; without using RFC 2217 you can adjust different speeds).
BTW a download with CHIRP takes 8.5 minutes with this setup.

The first part of problem:

What is happen with their software? You get an "Port Error" if you read a memory with double width characters. They cannot display the names with double width characters at all (at least with an German/English Windows 7, perhaps it works with a Chinese/Japanese version but I wouldn't install this language packs). All parameters except the name are displayed correct. With single width characters everything is OK. Everything tried with "One Memory Read", "Memory Read" stopped at the first error and that is here the first memory...
For use in CHIRP you may use something like in old programs: bold with "*", italic with "_" or ~strikethrough~ with "~".

The second part:

As you described in #4355 the second byte is for all double width characters I have checked 0x82 and not 0x00. The first byte is 0x1A (for digits and upper char) or 0x20 (for lower char) higher than normal ASCII ("T" (0x54) becomes 0x6E82; "0" zero (0x30) -> 0x4F82; "o" (0x6F) -> 0x8F82). "Mobil" -> 0x6C828F82828289828C82

Thanks for the update. Does it also take 8.5 minutes with the #4355 patch? I find 8.5 minutes quite a long time but that's what is to be expected at such low rates I guess. Getting or home-brewing a cable that works at the fast rate is probably the way to go if you want to do this regularly. I find it somewhat slow-ish at the fast rate still but it's bearable and that's as much as I can do.

On implementing the wide characters: The markup idea is what I have agreed on with other developers in the chirp IRC channel. This will be fairly specific to this particular radio, but there doesn't seem to be any opposition against using e.g. @U@ for the wide U. This rises a number of subtle issues that I need to sort out though. For example, The channel name limit has to take into account that @U@ counts as one character instead of 3. A single * needs to be entered as @**@ and the field shall never have an odd number of *. But I think it won't take long to get a crude patch ready for testing. I'll also have to document this feature, probably by adding a 'Help' pane for this radio that explains the steps for programming (implemented as dialog boxes in th #4355 patch but that's not ideal IMO) and that also explains the markup subtleties. I'll also have to add a check for characters that are unsupported yet, such as all those Asian symbols. Those could be added at a later stage if there is need. Stay tuned, week-end is almost here!

Edit: Almost forgot, but of course I also want to thank you for checking on how to convert the wide chars to their uint16_t representation and back. Saved me some work right there.

Regarding wide characters:

It seems like using "Fullwidth Characters":https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms#In_Unicode from Unicode would be less ad-hoc solution? This would allow the name in chirp to be displayed the same as the name on the radio.