Screen values vs PETSCII

[Robbie]

Hello folks.

POKE 4096,1 (expanded VIC20) puts the character 'a' in the top left corner.
POKE 4096,2 displays a b, and so on

I was expecting PETSCII codes ( a= $41, b= $42 etc), but nope!

Are the numbers a reference to the character 'map' in character ROM perhaps?

What I found, with chars unshifted:
0 = @
1-26 = a-z
27-47 = [£] up left space !"#$%&'()*+,-./
48-57 = 0-9
58 -63 = ;:<=>?-
65-90 = A-Z
after that we're into the pictograms

[srowe]

Are the numbers a reference to the character 'map' in character ROM perhaps?

Yes, screen codes are a (scaled) index into the character generator, by default the ROM at $8000.

PETSCII is mapped to these coded by the KERNAL print routines.

[Robbie]

Ah... In reading the thread about memory location 36869 below, I decided to check out the reference to Compute's Programming the Vic...

https://commodore.bombjack.org/vic-20/books-vic.htm

pp585 in Appendix J lists 'screen codes', which is exactly what I was after.

I can't believe I answered my own question, and so quickly... and in such a random way!

[Robbie]

Yes, screen codes are a (scaled) index into the character generator, by default the ROM at $8000.

PETSCII is mapped to these coded by the KERNAL print routines.

Thanks srowe. I might have a prod around at $8000.

[wimoos]

From screenvalue to PETSCII

Code: Select all

input in X
		
Y = X AND 63
IF (X AND 32) = 0 THEN Y = Y OR 64
IF (X AND 64) THEN Y = Y OR 128

result in Y (if X>127 then char is reverse)

From PETSCII to screenvalue

Code: Select all

input in X

IF (X AND 96) = 0 THEN REM it is a control code
X = X AND 191
IF X > 127 THEN X = X AND 127 : X = X OR 64
IF PEEK(199) = 18 THEN X = X OR 128:REM reverse

result in X

[Robbie]

From screenvalue to PETSCII

Code: Select all

input in X
		
Y = X AND 63
IF (X AND 32) = 0 THEN Y = Y OR 64
IF (X AND 64) THEN Y = Y OR 128

result in Y (if X>127 then char is reverse)

From PETSCII to screenvalue

Code: Select all

input in X

IF (X AND 96) = 0 THEN REM it is a control code
X = X AND 191
IF X > 127 THEN X = X AND 127 : X = X OR 64
IF PEEK(199) = 18 THEN X = X OR 128:REM reverse

result in X

Blimey. Good work wimoos!

[Mike]

[...] I decided to check out the reference to Compute's Programming the Vic [...]

Actually, the VIC-20 User Guide already contains the two tables of PETSCII and screen codes in its appendices.

There is one easily overlooked detail though: there are duplicates of the PETSCII codes, and when you enter them as 'plain text', with the screen editor, into a string (for PRINT or as variable), you only get one of the possible codes. Also, the pi symbol is special cased. Here is the correspondence table I use:

Code: Select all

with X=0..31:

PETSCII     screen code

   32+X <-> 32+X
   64+X <->    X
  160+X <-> 96+X
  192+X <-> 64+X (_except_ X=30!)
    255 <->   94

In my implementation of the MAD computer program, I used a PETSCII string with all screen codes to initialise a conversion table (come to think of it ... the table is probably much easier built using the correspondence above. Oh well.). That table in turn indexes into the character ROM when the characters of a string are 'printed' into the screen bitmap.

(Also @wimoos): reverse characters outside quotes do not have separate PETSCII codes. You need to 'bracket' them with {RVS ON} and {RVS OFF}. You should also take into account, that a quote toggles quote mode, so if you want to print quotes in a programs, I recommend to define a helper string like Q$=CHR$(34)+CHR$(20)+CHR$(34) and use it like this:

PRINT Q$+"THIS IS QUOTED."+Q$

The first CHR$(34) already does a quote, but it also activates quote mode - CHR$(20) deletes that quote, moving the cursor back one position and then the second CHR$(34) reprints the quote, but also switches off quote mode! I.e. you can also print a reverse quote like thus:

PRINT "{RVS ON}"+Q$+"{RVS OFF} <- A REVERSE QUOTE."

... and {RVS OFF} works as intended. With just "Q$=CHR$(34)", you unintentionally print {RVS OFF} as quoted control character and the remainder of the print string still appears reverse.

[chysn]

Sorry to necro this thread; I've always mistaken 2021 for 2020! But it's a thing I've been working on the last couple days. I've been trying to find a reliable way to go from PETSCII to screen codes, so I've been scrounging through the forum. Finally, I decided to just to go the KERNAL, figuring that CHROUT has to do the conversion at some point.

That point seems to be $E75D. The evaluations after CMP #" " are there. Everything else (like handling of pi) is kind of scattered around.

I didn't see where the KERNAL handles PETSCII above $A0, but Mike's chart helped with those.

This routine works for non-control characters, converting PETSCII to screen code. PETSCII characters from 0-31 and 128-159, I treated with wanton indifference.

Code: Select all

   CMP #$FF ; PI
   BEQ @P
   CMP #$C0
   BCS @C
   CMP #$A0
   BCS @A
   CMP #" "
   BCC @R
   CMP #$60
   BCC @6
   AND #$DF
   BNE @R
@6 AND #$3F
@R RTS
@A SBC #$40
@C AND #$7F
   RTS
@P LDA #$5E
   RTS   

[wimoos]

This does the trick:

Code: Select all

	BIT exit
	BEQ ctrlchr
	CMP #$FF
	BEQ ispi
	AND #$BF
	BPL exit
	EOR #$C0
	.BYTE $2C
ispi	LDA #$5E
exit	RTS

[chysn]

This does the trick:

Code: Select all

	BIT exit
	BEQ ctrlchr
	CMP #$FF
	BEQ ispi
	AND #$BF
	BPL exit
	EOR #$C0
	.BYTE $2C
ispi	LDA #$5E
exit	RTS

This starts failing at PETSCII character 96, where the input is $60 and the output is $20, when it should be $40. This is AND #$BF at work.

I do like the BIT RTS trick, and if I had to capture control characters, that's a tidy technique.

Update: I understand why the mismatches might not matter, though. My test program goes strictly "by the book" (The VIC-20 user manual). If you can't type a character on the keyboard, does it even matter? Maybe, maybe not. For my application, I'd rather convert everything, because I can think of reasons it might matter.

[wimoos]

Update: I understand why the mismatches might not matter, though. My test program goes strictly "by the book" (The VIC-20 user manual). If you can't type a character on the keyboard, does it even matter? Maybe, maybe not. For my application, I'd rather convert everything, because I can think of reasons it might matter.

Ah, this is where we meet. The code I presented is what I implemented in WimBasic (the INPUTFORM statement). Hence, only keyboardcodes mattered. I hadn't realised (never tested) that it didn't work correctly for non-keyboardcodes.

Regards,

Wim.

[chysn]

Ah, this is where we meet. The code I presented is what I implemented in WimBasic (the INPUTFORM statement). Hence, only keyboardcodes mattered. I hadn't realised (never tested) that it didn't work correctly for non-keyboardcodes.

That's fair. I can't think of a reason you'd need to go beyond keyboard input for that use. In my case, the input can come from anywhere, including a user directly editing hex while reading Personal Computing on the VIC-20, Appendix J, so it must be thorough.