PETSCII instead of ASCIIKEY

[Pimau]

Describe where we can find the problematic topic
On page I-76, VECTOR, vector table, 4th paragraph.

Describe the solution you'd like
CTLVEC, SHFVEC, and ESCVEC are describing to deliver "unmodified PETSCII code" in the accumulator. Shouldn't that be the ASCIIKEY (which is described in "USING THE TYPING EVENT QUEUE" on F-3)?
I think the PETSCII in A is only true for KEYSCAN.

[dansanderson]

The documentation is correct. Is there a reason why you believe it to be incorrect?

These vectors are deep inside the screen editor, which processes PETSCII codes. These codes can be printed as well as typed.

[Pimau]

Hi! When I use the three functions, I get the values back which are listed in the tables on F-5ff. The introduction to this tables speak of ASCII, not PETSCII. And for instance A is noted with 61 not 01 when pressed alone, 41 with Shift.
But in the meantime I also implemented KEYSCAN and this is also delivering the contents of table F5 „Keys pressed alone“. So my above assumption that KEYSCAN delivers PETSCII is wrong.

[Pimau]

When I think about it, it is not PETSCII and not ASCII, more somthing like a machine related key scanner code, isn‘t it?

[dansanderson]

Ah hm, ok. The ROM's own handlers really made it look like it was expecting key codes to already have been translated to PETSCII. I'll do my own test and update the docs. Thanks for the report!