24

PETSCII (sometimes PETASCII) is the character set developed by Commodore for use in its microcomputers. The first of these, the PET, started to be developed in early 1976. Why, then, did Commodore base the lower seven bits of PETSCII on the obsolete 1963 version of the ASCII standard (USAS X3.4-1963) instead of the then-current 1967 revision (USAS X3.4-1967)? (The consequences of this are most obvious in PETSCII's use of the and characters in place of the then-standard _ and ^, as discussed in this question.)

Was Commodore simply unaware of the 1967 revision? Or did they knowingly select the older version because it brought some particular benefit? (For example, at the time, a handful of other manufacturers' computers were still using the 1963 ASCII. Was Commodore aiming at compatibility with them, at least in terms of data interchange?)

1
  • 3
    Don't forget the 1965 and 1968 revisions of the standard as well... The two characters you specifically mention were changed in the 1965 one.
    – Jon Custer
    Jun 15, 2022 at 18:40

1 Answer 1

20

TL;DR PETSCII isn't "based on ASCII". Rather, the specifications Commodore wanted for PETSCII caused them to "back into" supporting the only version of the ASCII standard that didn't include lowercase.

As I understand the early history of ASCII, there was debate about including lowercase characters. So they were left out of the 1963 (first) standard, which just had 28 "reserved for future use" code points in their place. The upside is that you could follow the standard with a single-case implementation.

Commodore was going way beyond what ASCII allowed with PETSCII. In order to maximize available code points for graphical glyphs, Commodore chose to use a "Shifted" character set. So two control code are used to change the "Shift" mode, and this changes the characters available, with only one of the two modes including upper/lowercase.

Then, in order to make the text display mostly readable in either mode, Commodore designed PETSCII to use the same code points for both uppercase or lowercase. That's why you see the text instantly switch cases when toggling the "Shift" mode (e.g by pressing C=+LShift).

Reusing the same 26 code points for both upper and lowercase characters can only be consistent with the early version of the ASCII standard, which did not specify two cases at all. Therefore, to meet their other requirements for PETSCII, Commodore had to limit its compatibility to only what was specified for the 1963 ASCII standard.

6
  • Interesting theory. Like it. Still a bit far on the assuming side, as others as well left out lower case without going for some never implemented standard. Any substantial proof?
    – Raffzahn
    Jun 15, 2022 at 20:22
  • @Raffzahn: A lot of software expected to receive letters in the range 0x41-0x5A only, and having that range be uppercase would require the use of a caps-lock-style key when using software that wasn't equipped to handle lowercase letters. When I got the VIC-20, I thought the PETSCII approach was a rather clever way of handling the issue.
    – supercat
    Jun 15, 2022 at 21:21
  • 2
    @Raffzahn: My point is that on systems which do support two cases, having to use caps lock with software which doesn't support two cases would be a bit inelegant, especially if one wanted to be able to type graphical characters into code that didn't need lower case.
    – supercat
    Jun 15, 2022 at 22:03
  • 2
    @Raffzahn: It is not conjecture that a lot of programs would expect to receive letters using ASCII codes 0x41-0x5A only. Many such programs from that era still exist, and will behave poorly if given lowercase input. Further, typing letters without the shift key should produce lowercase letters. What could be a simpler way of meeting both objectives than having character codes 0x41-0x5A map to lowercase letters?
    – supercat
    Jun 15, 2022 at 22:11
  • 1
    @Raffzahn: As for up-arrow and back-arrow, a lot of books about BASIC used the up-arrow character, and one of PETSCII's graphics characters was a line across the bottom of the character box, making an underscore largely redundant. I would think putting the UK pound at 0x5F and leaving 0x5C as a backslash would have been better than having 0x5F being a back arrow and 0x5C a UK pound, but the lack of an underscore seems a reasonable decision, especially compared to the lack of a backslash.
    – supercat
    Jun 15, 2022 at 23:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .