Emulatotor key mapping.

[roudoudou]

i looked for greek keyboard and the only thing i found was stickers to put on another keyboard

[RobertM]

Well I am back more than a year later.

I have read all the comments and I hope I didn't miss anything.

I have coded Win API but not for decades now and I can tell you that an emulator can make any symbol translation whatsoever and there is no need for changing maps in emulated system ROMs. That's not key translations, that's symbol translations. So for example if you press a key that is not a "shift" key on your windows system then the shift can be emulated along with the appropriate key in the emulated system keyboard emulated hardware matrix.

I did discover that some of the cursor keys (Insert, Delete, Home, End, Page Up, Page Down) do something and I can split the emulated cursor and move one around but even if I copy something (which I was only able to do once) then the whole god damned keyboard layout changes from that point forth so you can do nothing but close the emulator and reopen it. I'm dam sure that was NOT a feature of the CPC.

So I am hoping for suggestions for another emulator even though Caprice64 is absolutely fantastic for all of it's additional features all but for this one issue mind-blowing insane absence of information.

BUT!!!

I want to add something obvious to the definition of "Emulator".

My system (CPC 6128 Classic) has a "COPY" key. If any "software" that is being called an "emulator" and it does NOT have a copy key or it does NOT in any way describe how to use this feature of the original system then it is NOT worthy of being called an Emulator technically as it does NOT (unless documented) have one of the MOST BASIC features of the original system.

I'm on the verge of selling my CPC 6128 to preserve my mental health and sanity. I can't develop on the actual system because I use so many other windows based tools. And I am moving to *nix soon as I no longer work and I don't have to deal with customers that can't use anything but Windows.

There are so many emulators to PLAY GAMES on old emulated systems that no emulator is going to compete if it can't be used by developers.

So please please ! save my sanity and someone if you can tell me of am emulator that allows me to use the windows layout keyboard. Or tell me how to copy on Caprice64. I always transfer screen copied special symbols into the program to save 10,000 CHR$(x) which bog the whole system down.

I learnt to type on a mechanical typewriter typing quick brown foxes until every joint in you hand aches for days. I learnt this as a child and I can't UNLEARN it.

[roudoudou]

i did some true, exact, correct, mapping on ACE-DL for most common users (UK, FR, SP, DE and DK) but this must be done for each keyboards

to sum up, there is no simple solution for this and it's a huge work because there is no generic translation on symbol working on every keyz

[Jean-Marie]

Yeah, there's an annoying bug with Caprice64, where you can only use the COPY key(ALT) if the Use hardware mapping option is ticked on. Otherwise, it won't work
ACE for Windows (WinACE?) has an option to remap the keyboard to a German one !
So it works like under Caprice64, but this time the COPY key is fully functional.
There is a little bug though : they key repetition doesn't work when the Remap option is on. That means, if you keep pressing on a key, it will be displayed only once.

[SkulleateR]

Nearly every emu I know use the left ALT Key (left OPTION Key on MacOS) as COPY KEY ...

Like CPCEmu, JavaCPC, AceDL ... or do I miss the point here  ?

[roudoudou]

Yeah, there's an annoying bug with Caprice64, where you can only use the COPY key(ALT) if the Use hardware mapping option is ticked on. Otherwise, it won't work
ACE for Windows (WinACE?) has an option to remap the keyboard to a German one !
So it works like under Caprice64, but this time the COPY key is fully functional.
There is a little bug though : they key repetition doesn't work when the Remap option is on. That means, if you keep pressing on a key, it will be displayed only once.

maybe i miss something when patching ROM Keymap for repetitions, thanks

[Prodatron]

Nearly every emu I know use the left ALT Key (left OPTION Key on MacOS) as COPY KEY ...

There is a special case, where this is a problem.
At least in Windows the GUI keyboard shortcuts somehow have a higher priority and will be executed no matter if the application itself could use these shortcut as well.
E.g. ALT+ESC or ALT+TAB will switch to the next window, and the emu disappears.
This is why I user other keys for COPY and CONTROL, as in my case I use the same shortcuts on the CPC.

[andycadley]

Well I am back more than a year later.

I have read all the comments and I hope I didn't miss anything.

I have coded Win API but not for decades now and I can tell you that an emulator can make any symbol translation whatsoever and there is no need for changing maps in emulated system ROMs. That's not key translations, that's symbol translations. So for example if you press a key that is not a "shift" key on your windows system then the shift can be emulated along with the appropriate key in the emulated system keyboard emulated hardware matrix.

Sure, an emulator could do that. But then it's useless for anything that doesn't read the keyboard in the way you're expecting (i.e. games, non UK keyboard layouts etc).

It might seem like this would improve development, but actually it would make it harder as though you could directly enter code, when you tried to test it the results might not actually be what you expect since the emulator will be messing around performing intermediary translations into potentially different key pressed.

So, you either have an emulator that is really only meant for BASIC programming (see things like BASIN for the Spectrum), write yourself a bunch of KEY commands that map the CPC's firmware to the layout of the PC keyboard (or have the emulator do this for you), or you just accept that it's about a gazillion times easier to do cross-development using PC tools and not have to worry about key layout differences at all.

[andycadley]

To try and put this in more concrete terms, imagine a game that uses 8 and 9 for left and right, with SHIFT for fire.

If the emulator steps in and transparently attempts to remap the keys for BASIC typing, key combinations will go awry. When you try pressing Left and Fire, the emulator will guess you're pressing the "*:" key with SHIFT and that's what the emulated CPC would see. As a result, your game doesn't see a direction pressed.

If you press Right and Fire, the emulator thinks you're trying to type a (, so dutifully translates this to pressing the 8 and SHIFT, so your game ends up seeing the as LEFT and FIRE, essentially the opposite of what you intended.

This is why remapping the keys in the Firmware makes the most sense if you really want to code on the emulated CPC (though I'd never recommend that). It means any software which only cares about the symbols on the keys gets what it wants (well assuming it uses the firmware) whereas things which actually only care about physical key numbers (i.e. most games) see a more direct mapping of one PC key to one CPC key.

[OffseT]

i did some true, exact, correct, mapping on ACE-DL for most common users (UK, FR, SP, DE and DK) but this must be done for each keyboards

That's because you are afraid of OS-specific code. 😛
But you are not to blame, afaik even PulkoMandy did not implement this part for Haiku version of ACE. 🙃

Anyway, it should be possible to make it fully automatic for any keyboard layout... just like ACE does on MorphOS. 😎
Only Amiga makes it possible? 😁

[RobertM]

Well I am back more than a year later.

I have read all the comments and I hope I didn't miss anything.

I have coded Win API but not for decades now and I can tell you that an emulator can make any symbol translation whatsoever and there is no need for changing maps in emulated system ROMs. That's not key translations, that's symbol translations. So for example if you press a key that is not a "shift" key on your windows system then the shift can be emulated along with the appropriate key in the emulated system keyboard emulated hardware matrix.

Sure, an emulator could do that. But then it's useless for anything that doesn't read the keyboard in the way you're expecting (i.e. games, non UK keyboard layouts etc).

It might seem like this would improve development, but actually it would make it harder as though you could directly enter code, when you tried to test it the results might not actually be what you expect since the emulator will be messing around performing intermediary translations into potentially different key pressed.

So, you either have an emulator that is really only meant for BASIC programming (see things like BASIN for the Spectrum), write yourself a bunch of KEY commands that map the CPC's firmware to the layout of the PC keyboard (or have the emulator do this for you), or you just accept that it's about a gazillion times easier to do cross-development using PC tools and not have to worry about key layout differences at all.

I am 1000% aware of the difference between a system (BIOS) call to the ROM and a hardware read of the matrix in the actual CPC. But do you think the emulator is an extension and a PC keyboard is matrix and the emulator re-ports reads to the PC keyboard matrix. Of course not. The emulator makes a translation and most of them give you a selection of translation so you choose the appropriate translation for what your doing at the time.
And " It might seem like this would improve development, but actually it would make it harder". Well there no "harder", it's impossible to use and I have installed it again. I am a developer so if it's not useful for developers then what is it useful for. There is nothing "harder" than impossible. Well impossible to know. It appears that this emulator may be able to do this as I mention but I have searched for months for documentation and found nothing.
Just grab your real CPC and pop out the "Copy" key and see how you go with some development.
The start of your third paragraph will cause exactly the problem you describe in the paragraph above and that is why the "SYMBOL" (not key) translation has to be done in the emulator level.

and what are these - "gazillion times easier to do cross-development using PC tools "

[RobertM]

To try and put this in more concrete terms, imagine a game that uses 8 and 9 for left and right, with SHIFT for fire.

If the emulator steps in and transparently attempts to remap the keys for BASIC typing, key combinations will go awry. When you try pressing Left and Fire, the emulator will guess you're pressing the "*:" key with SHIFT and that's what the emulated CPC would see. As a result, your game doesn't see a direction pressed.

If you press Right and Fire, the emulator thinks you're trying to type a (, so dutifully translates this to pressing the 8 and SHIFT, so your game ends up seeing the as LEFT and FIRE, essentially the opposite of what you intended.

This is why remapping the keys in the Firmware makes the most sense if you really want to code on the emulated CPC (though I'd never recommend that). It means any software which only cares about the symbols on the keys gets what it wants (well assuming it uses the firmware) whereas things which actually only care about physical key numbers (i.e. most games) see a more direct mapping of one PC key to one CPC key.

That's the difference between key translation and symbol translation.

All emulators that I know have address this issue but don't symbol translate.

So I will put it to you this way. CHR$(x) is slow. So you print CHR$(x) in immediate mode and then type
10 PRINT"";
and then edit 10 to COPY the printed character into the quotes because its about a trillion times faster.

Now you now how to do this on real hardware. I have been trying to find how to do it on the emulator for over a year.

So as far as I am concerned now "COPY" IS A KEY ON A CPC so if the emulator doesn't have this feature then it's broken, it's not an emulator and it needs to be un-installed and forever forgotten. as in Caprice Forever Forgotten - what a shame such a marvelous but entirely useless emulator.

[RobertM]

To try and put this in more concrete terms, imagine a game that uses 8 and 9 for left and right, with SHIFT for fire.

If the emulator steps in and transparently attempts to remap the keys for BASIC typing, key combinations will go awry. When you try pressing Left and Fire, the emulator will guess you're pressing the "*:" key with SHIFT and that's what the emulated CPC would see. As a result, your game doesn't see a direction pressed.

If you press Right and Fire, the emulator thinks you're trying to type a (, so dutifully translates this to pressing the 8 and SHIFT, so your game ends up seeing the as LEFT and FIRE, essentially the opposite of what you intended.

This is why remapping the keys in the Firmware makes the most sense if you really want to code on the emulated CPC (though I'd never recommend that). It means any software which only cares about the symbols on the keys gets what it wants (well assuming it uses the firmware) whereas things which actually only care about physical key numbers (i.e. most games) see a more direct mapping of one PC key to one CPC key.

Both the CPC and PC have arrow keys. There are 2 SHIFT-8 because there are two sets of number try it yourself Press SHIFT and the 8 on the numeric pad try numlock try scroll lock - you can't get an "*" out of shift and the "8" key on the number pad they have different codes.

I know the hardware level protocols from when they introduced the release codes on a PC keyboard as before that you couldn't tell if a key was still pressed which was no good for games. The PC keyboard DOES NOT SEND ASCII, DOES NOT SEND SYMBOLS, DOES NOT SEND SHIFTED KEYS or ANY KEY COMBINATION. It only reports when key x (where x appears mostly random) because it was based on an IBM keyboard before the XT or PC JR.

So you see it's not that the emulator has to fix this problem. It's that the emulator is creating this problem because some library somewhere was handy and easy to use.

The only keys that are out of scope to the windows client application are the Windows key, the Alt key and conditionally the CTRL key with the condition that it is not used with a Fn key as these are reserved for the application control system layer and not the client layer. 

[RobertM]

i did some true, exact, correct, mapping on ACE-DL for most common users (UK, FR, SP, DE and DK) but this must be done for each keyboards

That's because you are afraid of OS-specific code. 😛
But you are not to blame, afaik even PulkoMandy did not implement this part for Haiku version of ACE. 🙃

Anyway, it should be possible to make it fully automatic for any keyboard layout... just like ACE does on MorphOS. 😎
Only Amiga makes it possible? 😁

It's because I learnt to type professionally 50 years ago and I code at the speed of though - not the speed of "oh where is that key again". I don't look at the keyboard. The raised edges on "F" "J" and "5" on the numeric keypad are there so you never have to look at the keyboard.

[RobertM]

OK what I have found from frustration that can only be described as PTSD triggering -

The "Page Up" (I remember reading "Prior key" somewhere) is the shift key to split the cursor BUT BUT you have to hold it except that you have to release it when you holding it to repeat and hold.

So it's only a shift key once even if you hold it down so you have to

press and HOLD Page Up and then press and release the arrow key and THEN release the Page Up key and keep repeating this for every use of the arrow for the source cursor. You can't move the destination cursor once they are split and when you have the two cursors located correctly and your Page up key is falling apart then and only then you can used the Home key to copy. If you use some other keys in that cluster out of sequence then the keyboard layout completely changes and you have to close the app and restart.

If you press the Page Up key once and then up up up up then the cursor will split and the source cursor will go up once and then the destination cursor will go up three times so the destination cursor is two lines above the source cursor instead of the source cursor being 4 lines above the destination cursor. Home (Copy) will repeat.

I repeat: Home is COPY and will repeat.

[andycadley]

I know the hardware level protocols from when they introduced the release codes on a PC keyboard as before that you couldn't tell if a key was still pressed which was no good for games. The PC keyboard DOES NOT SEND ASCII, DOES NOT SEND SYMBOLS, DOES NOT SEND SHIFTED KEYS or ANY KEY COMBINATION. It only reports when key x (where x appears mostly random) because it was based on an IBM keyboard before the XT or PC JR.

Yes, I'm well aware of that. What you're overlooking is that the CPC keyboard also does not send SYMBOLS, it simply reports key numbers and 99% of CPC software is reading the keyboard by using those key codes rather than what ASCII symbols are on them.

So you see it's not that the emulator has to fix this problem. It's that the emulator is creating this problem because some library somewhere was handy and easy to use.

It has literally nothing to do with what libraries you use. Either you map things so there is a 1:1 mapping between the symbols on the keyboard, which makes typing in BASIC easy but everything else broken. Or you map things such that there is a 1:1 mapping between physical buttons, but BASIC will therefore give the symbols it thinks are on the keys when you type things like SHIFT+8.

Most (if not all) emulator authors prefer the latter arrangement because it causes less weirdness overall. And because the Amstrad firmware is flexible enough to allow you to remap all the keys to use as you wish (unlike, say, Sinclair BASIC).

[andycadley]

If it's literally just the COPY key you care about, have you tried using a different emulator? WinAPE, for example, will let you map it to any PC key you like. The failure to detect it's being held down in Caprice might be an emulator bug or it might be a quirk of your actual PC keyboard (modern USB ones don't necessarily all act the same in this regards, unlike in the old days).

[Jean-Marie]

Here is a quick & dirty workaround for Caprice64 :
1) Press CTRL and F9 to switch to "Hardware mapping".
2) you can now freely use the SHIFT and COPY (Alt) keys to carry out your copy operation.
2) Press again CTRL and F9 to switch back to "ASCII mapping"

Problem solved 

[RobertM]

I know the hardware level protocols from when they introduced the release codes on a PC keyboard as before that you couldn't tell if a key was still pressed which was no good for games. The PC keyboard DOES NOT SEND ASCII, DOES NOT SEND SYMBOLS, DOES NOT SEND SHIFTED KEYS or ANY KEY COMBINATION. It only reports when key x (where x appears mostly random) because it was based on an IBM keyboard before the XT or PC JR.

Yes, I'm well aware of that. What you're overlooking is that the CPC keyboard also does not send SYMBOLS, it simply reports key numbers and 99% of CPC software is reading the keyboard by using those key codes rather than what ASCII symbols are on them.

So you see it's not that the emulator has to fix this problem. It's that the emulator is creating this problem because some library somewhere was handy and easy to use.

It has literally nothing to do with what libraries you use. Either you map things so there is a 1:1 mapping between the symbols on the keyboard, which makes typing in BASIC easy but everything else broken. Or you map things such that there is a 1:1 mapping between physical buttons, but BASIC will therefore give the symbols it thinks are on the keys when you type things like SHIFT+8.

Most (if not all) emulator authors prefer the latter arrangement because it causes less weirdness overall. And because the Amstrad firmware is flexible enough to allow you to remap all the keys to use as you wish (unlike, say, Sinclair BASIC).

It is absolutely positivity inarguable impossible to map key 1:1 because of the exact very statement you made - " What you're overlooking is that the CPC keyboard also does not send SYMBOLS" so if the CPC keyboard doesn't send key codes then is impossible to map 1:1 with a PC keyboard that does.

I'm not overlooking anything. I know you can used the port numbers directly with the PPI and PSG to read the keys WITHOUT using the vectored IO routines provided in ROM!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I Purchased and SOFT 968 back in the day - go read that if you want to understand how the CPC 6128 ROM's bank switching work.

Let skip that and get to what YOU'RE NOT understanding.

In a hardware emulator (is this NOT a Hardware Emulator)  you will have all sorts of problems if you intercept calls to system routines for example THIS PROBLEM. If on the other hand you emulated the data returned from specific port read and write YOU CAN'T GO WRONG because that is what a HARDWARE emulator does. It does NOT PATCH SYSTEM CODE on to the code written on the emulator host because that is SOFTWARE EMULATION.

If the emulated Z80 is using the original ROMs and reading ports and seeing KEYS then that's what the EMULATOR is giving it. It the EMULATORS (design) CHOICE. BECAUSE the emulated CPC is NOT reading the PC keyboard. The emulator is already in the middle.

So you need to know the difference between KEY TRANSLATION (your argument) and SYMBOL TRANSLATION. The SHIFT ******KEY****** is NOT a SYMBOL. So when it is pressed in the PC keyboard **ALONE** if can be presented as a key in the matrix after it PRIMARY function of conveying TRANSLATED SYMBOLS *** NOT KEYS ***

AND NOT ONE BIT OF THIS RELATES TO MY QUESTION because NONE of the KEYS used for the COPY function involve PC Keyboard ***KEYS*** that exist in the CPC KEYboard.

Seriously - absolutely seriously - go read SOFT968, most of it is online, some of it is missing (a couple of chapters) but I had the in paper BOOK in the 1980's and being an enthusiast I read every word from start to finish several times.

But I have to end this with SYMBOL translation is NOT KEY translation. You MAP key translations you don't MAP symbol translations.

Jesus, I use ATTINY85's to emulate PC keyboards including VID/PID identification and feature negotiation. And I am obviously talking USB not the old PS/2 Protocol. There isn't a part of the hardware or software (os) of these two systems that I don't know.

My current project is to use a very small stepper to send quadrature (not receive quadrature drive) though a back EMF limiter (some diodes) to the GPIO of an ATTINY85 emulating a multi media USB keyboard just to turn the volume up and down - with a stepper that has a knob. I have done the same with star (Wye) and delta HDD platter spindle motors but the resolution is to low and error correction lowers it further.

[ZorrO]

@roudoudou - Jeśli nadal szukasz greckiej klawiatury dla CPC, przeczytaj to:
https://www.cpcwiki.eu/forum/programming/basic-programming-tips/msg117543/#msg117543
... i ta strona:
https://www.cpcwiki.eu/forum/off-topic/just-for-fun-c64-roms-v2/msg94970/#msg94970

[roudoudou]

maybe i miss something when patching ROM Keymap for repetitions, thanks

@Jean-Marie  the repeat will work on next release, i was not building the firmware map the right way

[andycadley]

But I have to end this with SYMBOL translation is NOT KEY translation. You MAP key translations you don't MAP symbol translations.

Your OP complained that doing this in WinAPE meant you could only map things on a per-key basis and not a per-symbol basis, which is entirely a result of mapping KEY translation only.

At this point I'm not really sure what you're expecting.

[RobertM]

But I have to end this with SYMBOL translation is NOT KEY translation. You MAP key translations you don't MAP symbol translations.

Your OP complained that doing this in WinAPE meant you could only map things on a per-key basis and not a per-symbol basis, which is entirely a result of mapping KEY translation only.

At this point I'm not really sure what you're expecting.

My first comment over a year ago was about both WinAPE and CAPRICE64 and at that time I mentioned that I had completely given up on WinAPE and struggled along with CAPRICE64.

My next comment a year later was about CAPRICE64. I have to use the symbol translated mode because I type ! (I don't look at keys) and I couldn't find how to split the cursor to use the copy function and I now have a vague idea of how to use it but if you bump one of the adjacent keys the entire key-mapping changes and all you can do is close CAPRICE64 and open it again.

So it took me over a year to get a vague idea of how to use one of the central features of the CPC in the emulator. No one else has been able to answer that question in that time.

As far as CAPRICE is concerned I have only uses symbol translation. I was responding to other people  about key translation as there was confusion between the two. There was talk of changing ROM images that has nothing to do with symbol translation as that is exclusively in the emulator and changing ROM images would cause the exact problem people were describing.

I read somewhere in french to use the prior key. So I translated prior to English and it means prior. What they probably meant was Page Prior or "Page Up". Which doesn't work like the original SHIFT (Arrows) because you have to press and hold it, press the arrow and release the arrow key and then release the page up and then repeat starting with the Page Down key or it won't work for for subsequent arrow keys so the cursor your moving changes from the source cursor to the destination cursor. Which leads to a whole lot of WFT.

But anyway, over a year to find that out. And I am from the RTFM generation.

[andycadley]

[There was talk of changing ROM images that has nothing to do with symbol translation as that is exclusively in the emulator and changing ROM images would cause the exact problem people were describing.

Right, I see.

The reason everyone is talking about using a modified ROM is because then you can have the best of both worlds. You can just have 1:1 hardware key mapping, but still get all the SYMBOLS to appear like they do on a PC keyboard so you don't need a reference or muscle memory etc.

You could do the same with a bunch of KEY DEF statements in BASIC, but just modifying the default key mapping inside the ROM would save RAM.

[RobertM]

[There was talk of changing ROM images that has nothing to do with symbol translation as that is exclusively in the emulator and changing ROM images would cause the exact problem people were describing.

Right, I see.

The reason everyone is talking about using a modified ROM is because then you can have the best of both worlds. You can just have 1:1 hardware key mapping, but still get all the SYMBOLS to appear like they do on a PC keyboard so you don't need a reference or muscle memory etc.

You could do the same with a bunch of KEY DEF statements in BASIC, but just modifying the default key mapping inside the ROM would save RAM.

I understand this but there is no copy key on a PC keyboard and yet it is emulated but not documented so it took me a year to find what key it is and how to use it. I use Caprice64 which already does symbol translation so there no need to modify ROM images.

I think that it was WinAPE that I regrettably had to abandon a year ago as it had no symbol translation.