There's
radix 050, where 050 is octal for 40 decimal. It's a string compression method that encodes three characters in a number from 0 to 63999, which provides 33% savings over ASCII. The characters are A-Z, 0-9, space, underscore, period, and the end-of-string symbol. To make it work well, you need a division instruction or a lot of lookup tables.
I see two problems:
- If you're trying to represent arbitrary data by decoding 16-bit units as if they were radix 050, it'll trip up on any pair of bytes with a value from 64000 to 65535. This means you would have to arrange the fields in your password so as not to have $FA through $FF bytes on even addresses (if big-endian) or odd addresses (if little-endian).
- It can produce FAGGOT as a password. I remember reading a report in one of the old multiplatform gaming magazines of the 16-bit era that Nintendo eventually banned vowels in passwords to make it harder for parents to claim that a video game taught taboo language to a child gamer.
You could try
my system on for size. It encodes 32-bit units to 8-character passwords using an alphabet of 32 symbols (0-9, *, #, and letters without vowels or S). Each password includes 8 bits of parity data for error detection (not correction) and, unlike the password systems in 1943 and Mega Man 3, is hard to forge with pencil and paper.
What data do you want to represent with your password?