Commander X16

Wow, re-discovered this when browsing some old files, I missed getting this on the SD card:

Here is a utility I did last year for converting a given decimal value into different Base numeric systems (Base-2, Base-8, Base-16, Base-36, Base-50). See the end of the code example for going up to Base-89 (with the max reasonable-printable characters on this system).

The example here is a pure radix numeric conversion. But this similar concept of base conversions can be a way to transport binary data across systems, as a given binary sequence can be represented by a higher-base character (embedding images in e-mails works along similar idea, see Base64 and MIME encoding - those encodings do work slightly differently than a pure numeric base conversion).

It is also an example of using BASLOAD to define some re-usable "function-like" structures (like for getting user-input capped to a certain length).

I've never heard of base 36 or 50. How are they used?

Me neither, but I'd like to see base-64 added ^_^

Well - it can really go to any base-N you want. It is limited only by whatever symbol set you want to use, as specified in the DATA sequence at the end of the BASL (which has an example for going up to Base-89).

But a "numerical" base conversion might be different than a text-encoding conversion protocol. The program here is a numerical base conversion.


If you want RFC 4648 Base64, that spec functions a little different than a general base-N conversion. For example, splitting into 6-bit groups (and the symbol set starting with A instead of 0) - as opposed to just take MOD by 64 (base) and gathering up the remainder as an index into the base-table.

desertfish wrote: ↑Sun Jun 16, 2024 9:23 pm Me neither, but I'd like to see base-64 added ^_^

I'm not sure that would fit how this program is being used, since Base64 is more about encoding byte streams.

Right, I think that's why I dropped it, to avoid that confusion or explanation on the SD card.

The set of symbols picked at the end, those are just suitable for the X16 system. Other systems might happen to support all those symbols, but the "RFC-derived" "Base64" protocols strive to pick a symbol set that is compatible with the broadest set of systems. But now I can't recall why they start with "A" instead of zero as its first symbol. If you do that, then using that same DATA table for Base-2 conversion, I'll end up with A and B instead of 0 and 1.

But that might be a nice exercise: to take any alpha-numeric string, split it into the groups of 6, and apply the actual RFC encode convention.

voidstar wrote: ↑Mon Jun 17, 2024 6:01 am the "RFC-derived" "Base64" protocols strive to pick a symbol set that is compatible with the broadest set of systems. But now I can't recall why they start with "A" instead of zero as its first symbol.

Well, the letters make up the bulk of the domain, and both upper and lower-case letters are used, so it makes sense to put them first.

My first thought is that the the symbol table was purposely designed to prevent confusion with radix encoding, since Base64 is not a number base at all. It's a binary encoding scheme, and the data encoded is not meant to be expressed in numeric form. In fact, if you do encode a single byte as a Base64 value, you get back 4 bytes. That's a required feature of the encoding, since it encodes 24 bits at a time. (in cases where the input data is not a multiple of 3 bytes, the last 1 or 2 bytes of the output string is padded with the = symbol.)

The fact that it's called Base64 is very misleading, since it's not a numeric base at all. It's actually a 24-bit encoding scheme, that uses 4-digit sequences to represent 24 bits. So it really should be called "Base 16 million." Or better, "Encode24", since that's what it actually does - encode 24 bits as 4 bytes.

Exactly, it's so misleading they call it "Base64" when it is an encoding scheme, like you said (that just happens to have a convention involving 64 symbols). And good point, maybe that is why they chose to start with "A" instead.

Did you know there's also a Base32? It's just like Base64, except it only uses one case of letters: "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567". Zero and One are not used as symbols, so humans won't confuse them with the similar looking letters "O", "uppercase-i", or "lowercase-L". (Nevermind 2Z and 5S)

There's also a version called "Base32hex", which is what you think it is: 0-9A-V.

However, hexadecimal-like base encoding only works up until base 36, and then we run out of letters. Before you mention lowercase letters, remember that the word "cheeseburger" doesn't become a different word when written out as "CHEESEBURGER", and you probably don't want to count like "big Z big Y, big Z big Z, big Z small a, big Z small b..."

Ok, updated the original post to clarify this is a numeric radix converter, not the encoder stuff.

Now with the serial-network card, an actual "Base64" Encoder might be an interesting way to transfer general-data-sequences onto the X16. Though I'd rather call it a "Plain Text Encoder" than overload the word "Base" in it.