Talk:PETSCII

message: 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)
replies: text: 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)
replies: text: 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)
thread_title: Terminology

message: 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: 
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)
replies: text: 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)
thread_title:  More archaism 

message: "...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)
replies: text: 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)
replies: text:  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)
thread_title:  Font convertion algorithm? 

message: 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)
thread_title:  STOP or RUN key 

message: 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)
replies: text:  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)
thread_title:  chr$(8) and chr$(9) 

message: 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)
thread_title:  Character Set Table