Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site gatech.UUCP
Path: utzoo!watmath!clyde!akgua!gatech!strick
From: strick@gatech.UUCP (Henry A. Strickland)
Newsgroups: net.micro.6809
Subject: Re: Bug (Feature?) in BASIC09 CHR$(N) function
Message-ID: <6781@gatech.UUCP>
Date: Thu, 3-May-84 20:37:38 EDT
Article-I.D.: gatech.6781
Posted: Thu May  3 20:37:38 1984
Date-Received: Sat, 5-May-84 00:53:43 EDT
References: <2054@ihnss.UUCP>
Organization: The Clouds Project, School of ICS, Georgia Tech
Lines: 25

> CHR$(n) masks off the high-order bit (bit 7), so your argument is
> interpreted modulo 128.  Not only can you not print pretty semigraphics
> characters, but you cannot send X and Y values to CCIO's hi-res
> graphics routines that are >127.
 
    I've never tried CHR$ on codes >127;  if i'm trying to put strange 
characters to standard output (or any other path), i use PUT:
    DIM x:BYTE
    x = whatever
    PUT #1, x
Use 1 for standard output, other path number for other paths.  X must be
type byte;  integer will send two characters, real sends more.  
   Using strange characters in strings is a bad idea in the first place,
since there is a character ( is it $00 or $FF? I forget ) that is used
to mark end-of-string, like \0 in C.
   Let me know if this doesn't work.
   While I'm at it, let me add that I love having a operating system
powerful enough to show up the hardware!  Like Unix, OS9 is a great environment
for finding a quick fix to a problem, instead of a long fix.  I use it to its
fullest...
-- 
Henry Strickland
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet:	Strick @ GATech		ARPA:	Strick.GATech @ CSNet-Relay
uucp:	...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!strick