[SkillzTech1]

What

Builds on #8923, which adds 27 single-byte profiles and leaves out the Windows code pages whose best-fit tables map bytes to private use. This adds those three: sceCesRefersUcsProfileCp1253, sceCesRefersUcsProfileCp1255 and sceCesRefersUcsProfileCp1257 now return a profile instead of throwing.

• Tables: the MBTABLE of Microsoft's bestfit1253.txt, bestfit1255.txt and bestfit1257.txt, the same source as CP1250_HIGH, CP1251_HIGH and feat(libSceCesCs): add 27 single-byte code page profiles #8923's 1254, 1256 and 1258. They are three more entries in feat(libSceCesCs): add 27 single-byte code page profiles #8923's SingleByte.hpp, used through its sbcHighTable; no other code changes.
• Private use bytes: 15 bytes map to the Private Use Area, as the tables give them: Cp1253 0xAA, 0xD2, 0xFF (U+F8F9-U+F8FB), Cp1255 0xD9-0xDF, 0xFB, 0xFC, 0xFF (U+F88D-U+F896) and Cp1257 0xA1, 0xA5 (U+F8FC, U+F8FD). This is what Windows' own conversion does for these code pages. Every other byte, including Cp1255 0xCA (U+05BA), is a regular character or a C1 control as in the other Windows tables.
• Table properties: in each table bytes 0x00-0x7F map to themselves and the 256 bytes map to 256 different BMP characters, so sceCesUtf8ToSbc and MBCS output are unambiguous.
• Stacked on feat(libSceCesCs): add 27 single-byte code page profiles #8923: the branch contains feat(libSceCesCs): add 27 single-byte code page profiles #8923's commit 27c3f6b; the change here is the last commit only. I will rebase it onto main once feat(libSceCesCs): add 27 single-byte code page profiles #8923 merges.
• Unverified: the console's handling of the 15 bytes is not known; the "Single-byte profiles" entry in docs/dev/debt/libSceCesCs.md says so, now for 30 profiles. The pending-exports count drops from 222 to 219.

Tested

Windows 11 Pro, MSYS2 UCRT64 GCC 16.1.0, Release, this branch merged into main 9e568a3 (#8923's base no longer configures with this GCC, which needs the SEH support added since).

• ctest -R '^guest_ces': 6/6 pass (guest_ces, guest_ces_module, guest_ces_dbcs, guest_ces_dbcs_module, guest_ces_unicode, guest_ces_unicode_module). CheckSingleByteProfiles covers the three new profiles: distinct stable pointers, the 1-255 round trip, and four sample bytes each plus two of the private use bytes and Cp1255 0xCA.
• Outside the repository, a harness linked against the built libSceCesCs.prx decoded all 256 bytes and encoded all BMP scalars for 1250-1258 and compared them with Python 3.13's cp125x codecs: 0 mismatches in both directions; the only bytes not compared are those Python leaves undefined, listed above. Each profile encodes exactly 256 scalars.
• python3 tools/check_conventions.py --base origin/main passes.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: feat(libSceCesCs): add 27 single-byte code page profiles #8923
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

🤖 Generated with Claude Code

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 10056	core/libs/prx/libSceCesCs/Export.cpp core/libs/prx/libSceCesCs/PendingExports.cpp core/libs/prx/libSceCesCs/SingleByte.hpp docs/dev/debt/libSceCesCs.md
PR 10428	core/libs/prx/libSceCesCs/Export.cpp core/libs/prx/libSceCesCs/PendingExports.cpp docs/dev/debt/libSceCesCs.md
PR 10431	core/libs/prx/libSceCesCs/Export.cpp core/libs/prx/libSceCesCs/PendingExports.cpp docs/dev/debt/libSceCesCs.md
PR 10751	core/libs/prx/libSceCesCs/Export.cpp core/libs/prx/libSceCesCs/PendingExports.cpp docs/dev/debt/libSceCesCs.md
PR 11614	core/libs/prx/libSceCesCs/Export.cpp core/libs/prx/libSceCesCs/PendingExports.cpp core/libs/prx/libSceCesCs/SingleByte.hpp core/libs/tests/GuestCes.cpp docs/dev/debt/libSceCesCs.md

[MarcZX10]

I checked the three added 128-entry high-byte tables against the linked Microsoft MBTABLE sections and confirmed the mapped entries match for CP1255 (256 source mappings) and the defined entries for CP1253/1257; undefined source bytes remain identity C1 controls in the candidate, consistent with the documented existing-table policy. git diff --check is clean. The checks show conventions/intake/labels passing, while hosted product builds are skipped; your PR reports the six CES tests and an external full-byte comparison. #8923 is still open, so the declared dependency/rebase remains the relevant integration step. No blocking issue found in the table/test changes.

[VakzOs]

Hi, I’m the author of boykopovar/AnyPS5#10214, which adds the code page 858 profile in libSceCesCs. A reviewer asked the PRs touching the CES files to agree on a landing order. This PR and boykopovar/AnyPS5#10214 both append to the end of the table in SingleByte.hpp, to the profile list in GuestCes.cpp and to the CES debt file. All three are keep-both overlaps, and no export is shared. This branch also conflicts with current main already (docs/dev/debt/libSceCesCs.md). My proposal is boykopovar/AnyPS5#10056, then boykopovar/AnyPS5#10214, then this PR refreshed on top. If you would rather land first, tell me and I’ll rebase boykopovar/AnyPS5#10214 onto yours.

[BunnyFl]

I checked the three profiles against firmware 13.42's own libSceCesCs.sprx (sha256 00c01529bc13223be8afabbde566fcbdc027a0366c6d6224effc86ba6cba3173). The module was loaded natively on x86-64 and called directly, with the profile each 13.42 getter returns: sceCesSbcToUtf32 and sceCesSbcToUtf8 on every byte 0x00-0xFF, and sceCesUtf32ToSbc on every scalar 0-0x10FFFF.

On 13.42 these bytes are unassigned: decoding them answers 0x805C0020, and no scalar encodes to them (U+F8F9, U+F88D, U+F8FC, U+05BA and U+0081 also answer 0x805C0020 with these profiles):

• the 15 private use bytes: Cp1253 AA D2 FF, Cp1255 D9-DF FB FC FF, Cp1257 A1 A5
• Cp1255 CA (U+05BA here)
• the C1 positions that the best-fit tables leave undefined: Cp1253 81 88 8A 8C 8D 8E 8F 90 98 9A 9C 9D 9E 9F, Cp1255 81 8A 8C 8D 8E 8F 90 9A 9C 9D 9E 9F, Cp1257 81 83 88 8A 8C 90 98 9A 9C 9F

Every other byte matches this head's tables (Cp1253 239, Cp1255 233, Cp1257 244 of 256 bytes). Each profile encodes exactly the scalars it decodes, back to the same byte. The UTF-8 and UTF-32 decoders give the same result on every byte.

Main's Cp1250-1252 already answer 0x805C0020 for their undefined bytes (#10185), and our 13.42 run agrees with them byte for byte. It also gives the Cp1254 and Cp1258 holes that rooklz measured on a PS5 in #10183 (Cp1254 81 8D 8E 8F 90 9D 9E, Cp1258 81 8A 8D 8E 8F 90 9A 9D 9E).

In GuestCes.cpp, CheckSingleByteProfiles requires every byte 1-255 of the three profiles to decode, and the samples expect AA, D2, FF (Cp1253), FF, CA, D9 (Cp1255) and A1, A5 (Cp1257) to decode to the values above; on 13.42 those bytes answer 0x805C0020.

Three runs, identical output. Not checked: the MBCS context conversions with these profiles.

[oneandonlydean]

@SkillzTech1 @BunnyFl The reported 13.42 results differ from the current tables and tests for the private-use bytes, Cp1255 0xCA and the listed C1 positions. Could you reconcile all of those cases, including reverse encoding and the all-bytes round-trip test? Please attach the text output and probe details for the reported run so the mapping and error results can be checked. The module hash is useful provenance, but this still needs evidence we can inspect.

[BunnyFl]

@oneandonlydean the probe source, the text output and the comparison with this head are in https://gist.github.com/BunnyFl/ea10c37840bd46a27caea4a84b6d14a5:

• ces_sweep.c and the loader: how the module is loaded and what each call gets.
• ces-13.42-output.txt: for Cp1250-1258, every byte's sceCesSbcToUtf32 / sceCesSbcToUtf8 result and output, every scalar sceCesUtf32ToSbc accepts, and the result counts for the rest.
• compare-pr9912-d5bff75774.txt: each byte where this head's tables differ from the run.

For the three new profiles, the reverse direction is the exact inverse of decoding. The scalars that encode are those the decoder returns, back to the same byte, and nothing else encodes (Cp1253 239, Cp1255 233, Cp1257 244 scalars). Every other scalar up to 0x10FFFF answers 0x805C0020, except the surrogates U+D800-U+DFFF (0x805C0015); 0x110000 answers 0x805C0014.