CPCTelera KeyID to ASCII and reverse

[Typhon]

Hello!

Just a quick CPCTelera question.

What's an easy way to convert an ASCII value (char) to a cpct_keyID and vice-versa.

cpct_getKeypressedAsASCII from 1.5 dev branch only works on keys actively pressed. I want to be able to convert back and forth on demand (for redefine, high score entry etc) without having to resort to a massive switch or if/then else.

Thanking you in Advance.
T.

(new game coming soon from Typhonsoft!)

[lightforce6128]

I do not have experience with CPCTelera. But do not use a bunch of if/then or switch/case! Converting from one (smaller) number to another (smaller) number can usually be acomplished best by using an array / a table for translation. If conversion in both directions is needed, you can either use two tables, or stay with one table, but you have to implement a search-loop for one of the directions.

Code Select Expand

// Define two tables:
char from_key_code_to_ascii [128] = { ... };
unsigned char from_ascii_to_key_code [128] = { ... }

// Convert from key code to ASCII:
int key_code = 69;
assert  from_key_code_to_ascii [key_code] == 'A';

// Convert from ASCII to key code:
char ascii = 'A';
assert  from_ascii_to_key_code [int(ascii)] == 69;
With this example one problem gets apparent: Should key 69 map to uppercase "A" or to lowercase "a"? Often more than one key is used to create a character.


Sometimes it is possible to find a mathematical formula for conversion, and maybe this one is even invertible for the other direction. But as far as I know there is no relation between the key codes and ASCII numbers in the CPC.

[lightforce6128]

No reason to reinvent the wheel: The operating system already contains the table (at least for one direction) and routines to access it:

• Call BB2A (KM GET TRANSLATE) with the key code in register A, then you get the ASCII character back, also in register A.
• Call BB30 (KM GET SHIFT) for the shifted ASCII character.
• Call BB36 (KM GET CTRL) for control codes.

For the CPC 464 the tables are stored in the lower ROM at

• 1D69 (KEY TRANSLATION TABLE)
• 1DB9 (KEY SHIFT TABLE)
• 1E09 (KEY CTRL TABLE)

For other CPCs the location of the tables might be shifted a bit.

If your program uses the memory differently then intended by the operating system, the tables and routines should still work, as they do not need access to initialized RAM areas. But paging of ROMs needs to be done in the right way.

[Typhon]

I don't have access to firmware though.. 

Having looked at the CPCTelera keypressedasascii asm, I think I'll go with your suggestion if using a lookup table. I see there's already one available for one direction at least: the cpckeyidtoascii[80] table.

Thank you! 

[andycadley]

If you need a full table and need to kick the OS out of the way, you can build up your own by just looping over calls to KM_GET_TRANSLATE before ditching the OS. This can avoid having to prod around inside the ROM trying to guess the version (although that is an option if space is tight)

The advantage of using the OS rather than a pre built table is that it will correctly identify things like an Azerty keyboard layout for you.

[awergh]

Usually with cpctelera you turn off the firmware as some of the functions expect for it to be disabled.

I have been using this getKey function from ronaldo for my games when I want to get a key from the player
https://www.cpcwiki.eu/forum/programming/cpctelera-question-entering-your-name-into-a-high-score-table/

It looks like it is doesn't do the ascii conversion which the function you mention does.