Re: Conventions for PETSCII art in assembler files?

Hi!

>> http://anonscm.debian.org/cgit/users/peterk/bastext.git/tree/tokens.c#n388
> That looks like decimalization of the non-ASCII chars in PETSCII...

Yeah, at least for the ones that cannot be entered by keyboard. The 
rest have their keyboard input equivalent.

> that really isn't what I'm after.  I can just put the "art" in the 
> code as a hex dump (with embedded text strings to be read still 
> rendered as individual printable chars) for the same effect.

Well, PETSCII art is difficult, especially since not all of the 
characters are even available in Unicode. Have a look at 
<http://style64.org/petscii/> for an overview. Mappings are available 
at <http://dflund.se/~triad/krad/recode/petscii.html>.

You still run into the issue of duplicated codes, though.

> Perhaps I didn't describe clearly enough what I'm after... I'm 
> looking for examples of any sort of descriptive symbolic labels for 
> the non-printable PETSCII chars, much like one often saw "{RVS_ON}" 
> and "{HOME}" in printed listings.

I had that in the file I linked to, things like "{cyan}" for 159, "{sh 
space}" for 160 and "{cm k}" (Commodore-K) for 161.

If you want to do a similar mapping for the duplicate codes, you 
should be able to get them for the values 96-127 by mapping them to 
192-221, IIRC).


This was based on a Commodore BASIC-based program I had that did the 
same conversion, look at the DATA lines starting at line 2100 in 
<http://www.softwolves.pp.se/cbm/syspd/d64/sys49.d64/10/p/programl%C3%A4s_3.2> 
(values are paired PETSCII code and then symbol; that program was in 
Swedish, it was used for program listings in a Swedish user group's 
magazine; some of the values have doubled keyboard references, where 
one would be the US English keyboard and the other the Swedish/Finnish 
C64 one (except for the one character which was impossible to enter 
using a Swedish C64 keyboard, $A4 I think).

> It's unlikly there is "a" standard.  I was just looking for some way 
> to place these in some assembler so the "art" could be visualized in 
> a way that a hex dump cannot.  The assembler won't care either way. 
> It's for the convenience of the humans.

Visualizing is probably best done by converting it to Unicode on a 
best-effort basis, i.e., add some look-alike mappings for the missing 
ones; I have one for visualizing SEQ files in my D64 browser here 
(again, this follows the Swedish PETSCII mapping, "**" denotes 
best-effort mappings):

<http://anonscm.debian.org/cgit/users/peterk/d64-browser.git/tree/d64.cc#n90>


(Wow, looking at code I wrote sixteen and even more years ago, I do 
see that I have improved as a programmer a bit since then)

-- 
\\// Peter - http://www.softwolves.pp.se/

       Message was sent through the cbm-hackers mailing list