Talk:PETSCII

Terminology

Instead of "shifted" and "unshifted", the two modes were commonly called "lowercase" (or sometimes "business") and "graphics" mode.

Quite right! The VIC 6567 has two different character sets available to it in ROM, and you could switch between the two by pressing the CMDR + SHIFT keys simultaneously, and this is how it got to be known as "shifted" and "unshifted" - but "lowercase" and "graphics" mode are much more correct. —Preceding unsigned comment added by 216.99.219.55 (talk) 02:18, 27 October 2009 (UTC) Dexter Nextnumber (talk) 05:29, 2 November 2009 (UTC)

Also, since the shift key sets the high bits in the character, the way you mention the repeating characters is the wrong way around. Normal characters are 0x20-0x5F and with shift, 0xA0-0xDF. It is the others who were repeats. The reason for the repeats is that the PETSCII characters all map to 128 different "screen codes" (in the video memory) and they don't map 1-to-1, but the conversion code didn't care about that. In screen codes, the high bit is used for reverse video. In the keyboards after the first one, there were fewer keys, so the nice regular mapping of the shift key to the high bit was partially lost.

It appears the article was written by a PC user having almost no experience with PETASCII short of observing what it looked like on the computer screen when printing it out using BASIC. The article could be improved if it were written from the perspective of someone who had SOME experience scanning the keyboard, and not just passing a byte to the BASIC print command. 216.99.201.102 (talk) 20:48, 26 October 2009 (UTC)

Also, in the very first PET model, the screen codes for upper and lower case letters were swapped. So if you turned on lower case mode, your upper case letters remained on screen as they were, and to get lower case letters you had to press shift. Presumably because that was inconvenient, the character generator rom was changed, and that meant that when you changed into lower case mode, your existing on-screen uppercase letters became lower case (and some graphics became upper case letters), as it is known also on the 64.

Going from PET to 64, the backslash was changed into a pound symbol.

See lots of docs on the CBM Hackers site, http://www.zimmers.net/anonftp/pub/cbm, some of which was contributed by me (Olaf 'Rhialto' Seibert).

Can anybody explain what "programmable" bit map modes are? The main article mentions in it passing, but if my memory serves me right, the C-64 had a hi-res graphics mode that let you fiddle with everything, right down to the bit. Similarly with sprites. In terms of 1983 architectures, what is the difference between a "programmable" bit map mode, and one that is not? 216.99.219.165 (talk) 23:31, 27 December 2008 (UTC)

Reasons for CBM to 'invent' PETSCII

This would be a more interesting and useful article if anyone could explain *why* Commodore chose to invent their own character set. In 1977, it's not like they were trying to lock people into only buying their peripherals from Commodore! --Wtshymanski 19:35, 19 Apr 2005 (UTC)

Good question/comment! My best bet (in fact, a bet I'm quite sure I would earn a little money on, had anyone bothered to bet against it) is that CBM did this to allow for the excellent (IMNSHO) block graphics extension to regular ASCII. They were thus able to alleviate, to some degree (or at least, they thought so) the lack of bitmap controllable graphics and user definable character set of the PET range. Using those graphics chars, some reasonably decent looking 'arcade games' (for the era) were actually made for the PET. :-)

As you might know, Atari also 'invented' a set of block graphics chars for their own 8-bit home computer family (different chars from CBM's, of course...). --Wernher 00:10, 20 Apr 2005 (UTC)

So there---done it (added to the article the (most?) plausible reason for PETSCII to be invented, that is). :-) --Wernher 01:00, 20 Apr 2005 (UTC)

A little dangerous, in my opinion; we're speculating, do we have a cite for this theory of the PETSCII character set? It's not apparent to me why they didn't just use the 8th bit set characters to extend the character set, as did the IBM PC and even the Osborne 1, where printable characters with the 8th bit set came out underlined (which looked way cool in WordStar) and non-printable characters were block graphics. --Wtshymanski 02:20, 20 Apr 2005 (UTC)

Yes, we're speculating, which is why I wrote "...may be one reason...". I think the current educated guess, stated very carefully, is OK. As for why did they use this scheme and not any specific one out of a range of alternatives, I think that would be a little beyound answering the basic question of why they in fact invented a proprietary char set as such. But, absolutely, a very interesting question! I'd love to have some CBM engineer(s) give a recollection of those matters from the early days of Commodore! :-)

BTW, I'm not sure whether a single one of the other extended/variable-ASCII charset articles have any mention of why their specific version got the way it is, and what other alternatives they considered (if any) and, if relevant, why they did or didn't import parts of other charsets or charset schemes. I have an idea that such information isn't the easiest one accessible; some times because none of the originators remembers (or, even, is at all alive), and/or that the documentation is non-existent. --Wernher 03:06, 20 Apr 2005 (UTC)

I don't know if we *want* to see a complete history of ASCII - there's tons of stuff on the Net, any search with "Bemer" and "ASCII" will turn up lots of documents; I once found a .PDF file (which I don't have on this machine) that went into amazing detail about the history of heated discussion over the assignement of the codes in ASCII, which exceeded even my appetite for trivia. Till we get better data (hopefully some day), your more cautious re-write will be I think sufficient. I wish we *knew*, though...--Wtshymanski 04:00, 20 Apr 2005 (UTC)

---

Peddle claims the inclusion of card suit symbols was due to the fact that one of the things that was on his specification list for the computer was an item that said that people should be able to easily construct card games with it.

I rewrote this sentence, but I wanted to highlight it here. Scary stuff. I hope I preserved the meaning. 82.92.119.11 21:43, 1 May 2006 (UTC)

I'm not sure why you consider it scary stuff. If my memory serves me right, there were a lot of people who wanted to play solitaire, and the computers in the late 1970s used cardplaying as a kind of bench test for ranking computers against each other, and for inferring thereby which computer packed more programming power into its chips. 216.99.201.109 (talk) 20:49, 30 October 2009 (UTC)

More archaism

The C64’s substitution of the pound sign for the reverse solidus in position 0x5C hearkens back to a 6-bit ISO subset of ASCII: [1]

Strictly speaking, without further confirmation it would be original research to label the ISO 6-bit subset as an influence here, though the agreement between the two narrows the list of possibilities (the other possibility I can think of is parallelism—unconnected designers making the same choice through expedience). That makes the C64 version of PETSCII both an ASCII-1963 and 6-bit subset throwback. Which amplifies my question even more: who designed that thing?! (ie a post-1970 character set with such blasts from the far past) --Shlomi Tal ☜ 15:46, 16 September 2007 (UTC)

The main article could be improved if there were some screen shots of how PETASCII were implemented on the PET. There appears to be too much emphasis on the C-64's version. 198.177.27.25 (talk) 23:20, 31 December 2008 (UTC)

Font convertion algorithm?

"...but since the PET font can be converted to the C64 font with a small program, this theory is out of question."

This is an unjustified statement. PET and VIC fonts really appear to be the same. One might think that C64 and later fonts are a bold version of this (example algorithm: (line>>1)|line), however this is not so. PET font has serifs on 'B', 'D', etc. which are not present on C64 and would not be removed by such a simple algorithm. Many characters, e.g. 'm', show that the font was redesigned altogether - i cannot imagine a generic algorithm which would automatically produce that. If one is described somewhere, i would like to know it.

Besides, the "reason" with colour artefacts sounds fishy too. ZX Spectrum had the same pixel and character size as C-64 (though C-64 could adress a larger screen area, thus higher total resolution), yet Spectrum had thin fonts, like PET, colorful output, and no color artefacts.

--89.59.25.27 21:34, 8 October 2007 (UTC)

The colour artefacts reason is not fishy. At least on PAL there are color effects with thin fonts. PAL mixes some amount of the color information from one scanline into the next. —Preceding unsigned comment added by 84.191.230.122 (talk) 04:50, 4 May 2008 (UTC)

PAL contains more scanlines than NTSC, but the color resolution is extremely poor. PAL color resolution considerably less than its luminosity resolution. The result is that PAL colors blur together - much like coloring outside the lines in a kid's coloring book. PAL hackers were able to exploit is design flaws in incredible ways. -DevinCook (talk) 05:50, 4 May 2008 (UTC)

STOP or RUN key

BASIC programmers might find it difficult to deal with the PETASCII codes for STOP or RUN, but the main article could be improved by noting that pressing the STOP key produces chr$(3) while pressing the very same key with the SHIFT key down, produces chr$(131).

The main article might unfortunately lead a PC user to think that these keys don't have PETASCII codes. Someone should fix the main article. (Especially the diagram that misrepresents these keys.) Just because the C-128 (and the C-64, apparently) are provided with their own species of BASIC as part of the operating system doesn't mean that these keys are inert; the PETASCII codes are available to any programmer calling the KERNAL GET routine at $FFE4). 198.177.27.17 (talk) 00:14, 2 January 2009 (UTC)

Table inconsistent with BASIC 'GET' function

I have a problem with the table in the main article.

It seems to presuppose that PETASCII is independent of the BASIC 'GET' function, and depends wholly on the PRINT function. If anybody bothers to look, the PETASCII values received from the BASIC 'get' command tend to depart from the values given in the main article.

For instance, the program below produces strikingly different results than those shown in the main article:

100 GET A$: IF LEN(A$)<1 THEN 100

110 PRINT ASC(A$)

120 GOTO 100

In short, the program shows that SHIFT A produces a value of 128+64+1(that is, $C1, whatever that is in decimal), and SHIFT B produces 128+64+2 (that is, $C2, whatever that is in decimal), and so on. These are hardly "duplicate" values. These are the PETASCII values that you get when monitoring the keyboard. They don't even come CLOSE to being the 'duplicate' values that the main article predicts should occur.

The main article should be improved by taking into account the proper PETASCII values for the SHIFTed keys on the keyboard.

Did I miss something? I'm not a BASIC programmer, and it is possible I mistyped something somewhere. 198.177.27.33 (talk) 20:17, 2 March 2009 (UTC)

----------------

It has little to do with BASIC and everything to do with PETSCII.

Standard ANSI ASCII uses the 7-bit $00-$7F (0-127 dec) for standard code assignments and has 32 control codes $00-$1F (0-31 dec) and 96 characters $20-$7F (32-127 dec). ASCII has uppercase letters in $41-$5A (65-90 dec) and lowercase letters in $61-$7A (97-116 dec).

PETSCII uses the full 8-bit $00-$FF (0-255 dec) and has 64 control codes and 128 characters, with two character code segments repeated to total 192 assigned characters.

PETSCII has 32 control codes $00-$1F (0-31 dec), 96 character codes $20-$7F (32-127 dec), 32 control codes $80-$9F (128-159 dec), 32 graphics codes $A0-$BF (160-191 dec), repeats characters $60-$7F for codes $C0-$DF (192-223 dec), repeats characters $A0-$BE for codes $E0-$FE (224-254 dec) and repeats character $7F for code $FF (255 dec).

PETSCII has two different character sets: "text" mode and "graphics" mode. The differences between the "text" and "graphic" mode is in the display of the characters $41-$5A (65-90 dec), $61-$7A (97-116 dec), $7E, $7F, $A9 and $BA.

PET "graphics" mode has Uppercase letters in the $41-$5A code positions and form chart graphics in $61-$7A repeated at $C1-$DA (193-218 dec).

PET "text" mode has Lowercase letters in $41-$5A and Uppercase letters in $61-$7A repeated at $C1-$DA.

Standard ASCII has uppercase letters in the $41-$5A and lowercase letters in $61-$7A just the opposite of text mode PETSCII.

In Commodore BASIC, GET the keyboard code for characters 'A' thru 'Z' in unshift returns x'41'-x'5A' and in shift returns x'C1'-x'DA' (the keyboard shift ORs the character returned with a $80 (128 dec)).

print chr$(97)

and

print chr$(193)

should both print 'A' in "text" mode.

get a$

will return $C1 or 193 decimal for a shifted key 'A'.

The values poked into or peeked from screen memory for the various characters are different from PETSCII get/print character codes:

screen codes x'00'-'5F' correspond to character codes x'40'-x'7F'

screen codes x'60'-'7F' correspond to character codes x'A0'-x'BF'

screen codes x'80'-x'FF' display reverse video of the screen codes x'00'-x'7F'.

Naaman Brown (talk) 22:26, 14 May 2009 (UTC)

------------

You are forgetting to double-check your work against the bytes that the BASIC get command produce. PETASCII is a format for the structure of the byte produced from a keypress, as well as what the byte looks like when you send it to the BASIC PRINT command. 216.99.201.102 (talk) 20:52, 26 October 2009 (UTC)

chr$(8) and chr$(9)

The main article lists chr$(8) and chr$(9) as enabling and disabling the shift mode. I never could get the shift mode to be frozen from BASIC, as people would always poke it back to normal if it ever did. Or they would just press RUN/STOP RESTORE and fix the system that way. (Hence it being far more common to do all your keyboard controller stuff from assembly language, and not let BASIC interfere with it.)

So, does anybody know if chr$(8) really did freeze the shift mode? I really doubt it. I don't think anybody had a use for that feature, and probably never used it, even if it was a feature that BASIC 2.0 offered. (Maybe it is a feature available through BASIC 7.0 for the Commodore 128?)

Similarly, chr$(9) was usually used to advance the cursor forward, not necessarily to any particular TAB setting. And it certainly wasn't used as a "field" advancer like it is used with PC compatibles, and various Internet friendly term programs/browsers.

Unless somebody pipes up and protests, I am going to fix the diagram in the main article by deleting references to $08 and $09 as features having something/anything to do with the Shift Key. Didn't people just poke the state of the shift key into the character set used by the VIC-II chip? And then trap the shift key when scanning the keyboard? Which brings up the issue of PETASCII being far more than a display standard, but also an input standard, something the main article makes no reference to whatsoever. (PETASCII has no make & break codes, like modern PC keyboards, you really did have to debounce everything yourself, and for that reason you used machine language to examine the keyboard lines at $DC00 and $DC01.) 216.99.201.109 (talk) 20:02, 30 October 2009 (UTC)

chr$(8) and chr$(9) dont enable or disable shift or the shift mode at all - they "lock" and "unlock" the possibility to switch between uppercase and lowercase using cbm+shift (and that only in basic). so the table is wrong there. (its wrong about the "unused" parts too, every code was used, some only as terminal control codes, just like in ascii) —Preceding unsigned comment added by 62.143.153.84 (talk) 10:25, 29 July 2010 (UTC)

Different table desirable

The main page has a picture by Shlomital, but it misrepresents PETSCII by drawing a false similarity with standard ASCII.

I just spent about an hour trying to upload a picture to the Wikipedia Commons. I think it looks a lot better than the one Shlomital posted.

If there isn't any objection, I will replace Shlomital's picture with the one I posted at Wikipedia Commons. The name of the file is Two_screens_PETASCII.gif, categorized as follows:

  Category:Commodore
  Category:PETASCII demo.

I hope I did it right. I don't have much experience uploading files. It shouldn't take so long to post something that is ineligible for copyright, and inherently in the public domain. Dexter Nextnumber (talk) 21:44, 5 December 2009 (UTC) Dexter Nextnumber (talk) 02:05, 6 December 2009 (UTC)

Hmmm. Let me see if I've got this straight now.

Much better. Dexter Nextnumber (talk) 04:04, 8 December 2009 (UTC)

Character Set Table

The character set table is the most important part of this article. Unfortunately, because it is trying to do too many things at once (and do it all in Unicode which isn't a superset) the current chart is a big mess. I propose splitting the chart in to more easily digestable pieces.

• A chart which shows just the basic character set, as one might have seen it in the back of a Commodore programming manual. In particular, the Lowercase ("shifted") and graphic ("unshifted") character sets should not be merged into the same cell!
• A chart showing the best possible mapping from PETSCII to UNICODE, with notations of which characters are impossible and a small inlined bitmap of what they look like. —Preceding unsigned comment added by 67.183.110.101 (talk) 07:44, 1 April 2010 (UTC)