Non-ASCII characters are shown as "?"

[forthrin]

$ sidplayfp ~/Music/C64Music/MUSICIANS/H/Huelsbeck_Chris/Shades_filter_corrected.sid 
Author       : Chris H?lsbeck

# Model Identifier: MacBookAir10,1
# System Version: macOS 26.1 (25B78)
# sidplayfp: 95003de 2025-11-28
# LANG=en_US.UTF-8
# LC_CTYPE=UTF-8

[drfiemost]

Works fine here, was it compiled with iconv?

+------------------------------------------------------+
|  SIDPLAYFP - Music Player and C64 SID Chip Emulator  |
|       Sidplayfp V2.15.0, Libsidplayfp V2.15.1        |
+------------------------------------------------------+
| Title        : Shades (filter corrected)             |
| Author       : Chris Hülsbeck                        |
| Released     : 1986 Markt & Technik                  |
+------------------------------------------------------+

[forthrin]

# macOS PROVIDES iconv
$ find $(xcrun --show-sdk-path)/usr -name '*iconv*'
/usr/include/iconv.h
++

# CONFIGURE DONT WANT
$ ./configure | grep iconv
checking for iconv... yes
checking for working iconv... no
checking whether iconv is compatible with its POSIX signature... yes

# PREFIX WONT HELP
$ ./configure --with-libiconv-prefix=$(xcrun --show-sdk-path)/usr | grep iconv
checking for working iconv... no

# HOMEBREW
$ brew info libiconv
==> libiconv: stable 1.18 (bottled) [keg-only]
... macOS already provides this software ...

# NEEDS EXPLICIT PATHS
$ export CPATH=/opt/homebrew/opt/libiconv/include
$ export LIBRARY_PATH=/opt/homebrew/opt/libiconv/lib

# CHRIS HÜLSBECK IS BACK
$ ./configure | grep iconv
checking for working iconv... yes

Not intuitive nor mentioned in README. One sort of takes Unicode for granted these days.

Dir["#{Dir.home}/Music/C64Music/**/*.sid"].map do
  File.binread(it, 0x60, 0x16).tr("\x00", '.')
end.join.encode('utf-8', 'iso-8859-1').chars.tally.sort_by(&:first).each do
  printf "$%02X  %s  %7d\n", it.first.ord, it.first, it.last
end

These are the only non-ASCII characters used in the entire HVSC, most of which are very rare.

$C1  Á   174	$DA  Ú     1	$E4  ä  1151	$ED  í    16	$FA  ú    43
$C4  Ä    12	$DC  Ü     4	$E5  å   312	$EE  î     1	$FB  û     2
$C5  Å   550	$DF  ß     5	$E6  æ     2	$F1  ñ     3	$FC  ü   683
$C8  È     1	$E0  à     2	$E7  ç    49	$F3  ó   743	$FD  ý    42
$C9  É     4	$E1  á  2029	$E8  è     3	$F5  õ    53
$D6  Ö   281	$E2  â     1	$E9  é  1008	$F6  ö  1441
$D8  Ø    96	$E3  ã     1	$EA  ê     3	$F8  ø  1627

So even a simple fallback would work for most cases.

const char ascii[64 + 1] = "AAAAAAECEEEEIIIIDNOOOOOxOUUUUYTSaaaaaaeceeeeiiiidnooooo/ouuuuyty";

void asciify(unsigned char *str) {
  while(*str++) {
    if (*str >= 0xc0)
      *str = ascii[*str - 0xc0];
  }
}

Oh yeah, plus one measly ° ($B0) char. That one one would simply have HVSC maintainers obliterate.

[forthrin]

Actually, since you're just dealing with Latin 1, UTF-8 conversion is cake, and bye to the dependency.

void latin1_to_utf8(const unsigned char *s, unsigned char *d) {
  while (*s++) {
    unsigned char c = *s;
         if(c <  0x80)                *d++ = c;
    else if(c <= 0xBF) { *d++ = 0xC2; *d++ = c; }
    else               { *d++ = 0xC3; *d++ = c - 0x40; }
    if (c == 0x00)
      break;
  }
}

[drfiemost]

Interesting, but the terminal may not be UTF8 (I think mostly on Windows). Will think about it later.
For now I've applied the asciification as a fallback, even though some characters should technically be replaced by a sequence of two letters. Still a nice step forward instead of the ugly question mark. 👍🏻

[forthrin]

Nice! Well, again if on a legacy platform/charset (1252, which is Latin 1 with added $80-$9F), simply print as-is.