From Newsgroup: comp.sys.cbm


Lyrical Nanoha wrote:

On Sat, 15 Oct 2005, Nick Bensema wrote:

I grew up initially with several computers in the Atari 8-bit series.
After my 130XE died, I got my grandfather's Commodore 64. They had
one thing in common: wacky dissociation between screen memory and
their OS's idea of ASCII.

With both computers, you could display letters on the screen with a
POKE to video memory. However, the number you POKEd was almost never
the same number you would put into a CHR$ function to print that
character.

For example, to get an uppercase A, you would:
(a) PRINT CHR$(65) (assuming uppercase mode if C64)
(b) POKE 1024,1 (Commodore 64)
(c) POKE 40000,33 (48k Atari 8-bit)

Is there any reason the screen memory was set up this way? Why wouldn't all three be 65?

Heh. Try the Apple ][ (where, thankfully, it's much simpler)...

]? chr$(65)
A

]poke 1024,193

]

At least it's as easy as adding a 128 on the Apple.

Also, what's the deal with the backspace? In PETSCII, it's CHR$(20),
even though CHR$(8) is right there doing nothing. In ATASCII, it's CHR$(126). I understand that ATASCII puts graphics tiles in its
first 27 characters, so it can't use CHR$(8) for backspace or
CHR$(13) for CR. But ASCII DEL, at CHR$(127), is RIGHT NEXT DOOR,
but ATASCII puts the tab there instead.

Thankfully on the Apple it's 127. (8 is Left Arrow, which made keyboard handling a nightmare in the original Dapple. 9 is of course Tab. Apple
used ASCII quite straightforwardly in their computers, thank God.)

On the TI-99/4A, you add 96 (>60). This is called the BASIC offset, and
is used to maximize VDP memory for your program. (The beginning of the character pattern table overlays another area).

So:

PRINT CHR$(65)

A

CALL POKEV(0,161) ! place A at screen location 0 (and POKEV requires E/A or Minimem or an enhanced XB)

As far as backspace, the "left arrow" key is 8, and you can hit FCTN-V
for 127. Or you can change the keyboard to PASCAL mode (mode 4) and
then Ctrl-H is 8, and 127 is still FCTN-V.

But as far as ASCII goes, outside of the BASIC offset, it is quite straightforward. Except that on the TI control characters don't get
translated (meaning control characters in files are read just as they
are, don't do strange things, control characters printed to the screen
don't cause screen clears, beeps, or anything else - they just show
whatever the character definition for that character).

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

With both computers, you could display letters on the screen with a
POKE to video memory. However, the number you POKEd was almost never
the same number you would put into a CHR$ function to print that character.

On the Commodore 64 (and Ataris as well, I presume), the values also represented BASIC tokens. You could write some very strange looking yet functional programs through careful use of PETSCII graphics embedded in the program (Jim Butterfield is the master of this). Plus there's the famous "Insert Mode" where you can do all kinds of bizarre things.

And there is yet another disconnect, with keyboard scan codes. So to
expand on your example, you would press A (keyboard code 10), and an A
(ASCII 65) would appear, and appear in screen memory as value 1 (A). o_O


--
Leif Bloomquist
leif (at) schema factor (dot) com
http://home.ica.net/~leifb/


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

In article <11l7bgqiuegh344@news.supernews.com>,
Leif Bloomquist <spam@127.0.0.1301> wrote:

With both computers, you could display letters on the screen with a
POKE to video memory. However, the number you POKEd was almost never
the same number you would put into a CHR$ function to print that
character.

And there is yet another disconnect, with keyboard scan codes. So to
expand on your example, you would press A (keyboard code 10), and an A
(ASCII 65) would appear, and appear in screen memory as value 1 (A). o_O

Well, at least scan codes can be blamed somewhat on the layout of the
keyboard. Maybe that explains the seemingly random arrangement of
the PETSCII graphics accessed by the Commodore key...

--
Nick Bensema <nickb@io.com> AIM: NBensema
==== ======= ============== http://www.io.com/~nickb/

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Am 15.09.2006, 22:22 Uhr, schrieb Nick Bensema <nickb@eris.io.com>:

In article <11l7bgqiuegh344@news.supernews.com>,

And there is yet another disconnect, with keyboard scan codes. So to
expand on your example, you would press A (keyboard code 10), and an A
(ASCII 65) would appear, and appear in screen memory as value 1 (A).
o_O

Well, at least scan codes can be blamed somewhat on the layout of the keyboard. Maybe that explains the seemingly random arrangement of
the PETSCII graphics accessed by the Commodore key...

The best explanation why screen codes are not equal to ASCII/PETSCII codes
is propably the ECM mode which limits the character set to 64 characters.
If you wanted letters + numbers within this range, you could not use
ASCII.
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

With the keyboard..take a qwerty layout, run lines vertically(two halves) and horizontally, and you get an 8 x 8 matrix, encoded into 6 bit. Add bits for shift and control, you get a byte for each regular key. Special keys decoded seperately.

So an "A" is 63, "P" is 10, etc. All keyboards do this in some fashion.

Internally, these codes get changed to atari version of ASCII. "A" is 65, "P" is 80. At least its mostly close. All computer manufacturers do some form of this too. Software changs this with a look up table.

For displaying on the screen, you normally fill memory with zeros. But that is the heart graphic character. So you have to rearrange the atascii into internal
so zero becomes the space. So "A" is 33, "P" is 48. Rearranging the codes speeds up the display, little math and conversion.

I have some of this on my site at...http://www.a8maestro.com/atari/info/kdbgrid.htm.
Atascii to internal is coming.

Rick D.
DO NOT REPLY TO a8maestro"a t"a8maestro.com.
Use rld2006 " a t " a8maestro.com instead.
This will change to rld2007 in 2007.


Nick Bensema wrote:

In article <11l7bgqiuegh344@news.supernews.com>,
Leif Bloomquist <spam@127.0.0.1301> wrote:

With both computers, you could display letters on the screen with a
POKE to video memory. However, the number you POKEd was almost never >> > > the same number you would put into a CHR$ function to print that
character.

And there is yet another disconnect, with keyboard scan codes. So to >expand on your example, you would press A (keyboard code 10), and an A >(ASCII 65) would appear, and appear in screen memory as value 1 (A). o_O

Well, at least scan codes can be blamed somewhat on the layout of the keyboard. Maybe that explains the seemingly random arrangement of
the PETSCII graphics accessed by the Commodore key...

--
Nick Bensema <nickb@io.com> AIM: NBensema
==== ======= ============== http://www.io.com/~nickb/

--- Synchronet 3.18b-Win32 NewsLink 1.113