I am sure I have been trough this several times before.
Once again I have a CPC 6128 and I want to develop using an emulator (and the real machine).
So I have reached the point of absolute insanity that goes with the common CPC emulators.
Now don't get me wrong. I understand and appreciate all the hard work and time that goes into these emulators. But Why my God Why, build an aircraft with no wings???
So firstly WinAPE - I love it, I loved it years ago. It has all the features I want to develop in ASM!!! Years ago I had a deal breaker of an issue and that very issue still exists today.
The key-mapping can only be changed PER KEY and NOT PER SYMBOL. So if I want to use a windows keyboard with the windows layout then I CAN'T because I cant separate the mapping from the "2" from the mapping of the "@" or " - a deal breaker then and a deal breaker now - so in the bin again.
So next, Caprice - a long long long history and even today "caprice forever" and I'm Running Caprice64 and after forever and ever and a really long time one would expect to find how to use one of the most significant changes in early retro computing history - the copy key!!!
I can actually use the copy key feature with (CPC) hardware mapping which is also why WinAPE went in the bin. Then If I use the normal PC key mapping then I can't find a way to use the copy key feature. I have searched and searched using so many different terms , looking directly for this feature and then searching for some form of manual that tells you more than how to compile and install the application.
RTFM!!!! Can we expect a manual that is so so complex that it briefly explains how to use one of the most central features of the device it emulates - perhaps two whole sentences.
So I am hoping someone can tell me of an emulator that is USEFUL for developing for a CPC 6128 (Classic) for BASIC and ASM and allows me to use a PC keyboard layout because I have several systems THAT ARE NOT CPC and using a different mapping on different machines is so frustrating that it's enough to turn me completely off something I once enjoyed. The only thing positional I wan about mapping is the position of the chair my ass is on. If my ass in on a chair in front of a windows PC then I want windows mapping, if my ass is on a chair in front of a specie then I want specie mapping, if my ass is on a chair in front of a CPC then I want CPC mapping or in the end I am trying to work out why my specie keys aren't working on my CPC and that really &%*&(& you up when your trying to debug.
If I am developing with a Windows CPC emulator then I am also using different apps that of course use the windows key mapping. I get to the point that I am using CPC key locations in other windows apps - it's just absolute insanity.
Typists don't look at the keys and most experienced coders are typists. I took a typists course in the 1970's because I wanted to be a programmer - jokes aside about me being a "sissy" boy for doing a girls class - why the hell don't coders learn to type.
And I can tell where all the keys are from where my ass is.
I mean! do people get into a back end loader and look for the keyboard? Do people who work in back end loaders sit down at there computer and look for the hydraulic control levers? You should be able to tell where the keys are from where your ass is.
I will add that so many people have searched for a manual for Caprice that it is now a well advertised hook for malware downloads. That's pretty much the death knell for any software products - but as I said why build a plane without wings.
most of the time, emulator authors are mapping a physical keyboard disregarding YOUR mapping because there is at least 3 possible output mappings on CPC (british, french and spanish)
mapping a real keyboard to a ROM mapping is possible if you have another approach to programming, that's what Megachur did with CPCemuPower but only from french hosted keyboard to french/british map. And you have to set the emulated keyboard
maybe emulators are lacking a good old setup.exe ?
A workaround would be to use a hex editor to change the key mapping in the ROM of the 6128. The tables for the Matrix can be found from address 0x1f80 upwards in OS6128.ROM.
I appreciate the key-for-key mapping that the emulators have - and I'd use them if I had a custom keyboard with that layout (not out of the question with replaceable keycaps, if someone was to get a set made with the CPC layout and colours).
But it would be nice to have a translation layer between modern layouts and the CPC layout.
(hey, at least it isn't the awful Spectrum keyboard layout!)
At one point there were a bunch of KEY definitions circulating (maybe in a thread here?) that you could run from BASIC to map more closely to the key layout on a standard PC keyboard (and they could easily be pasted into the auto type thing in WinAPE).
Fundamentally the emulator itself can't do this because it's job is faking hardware and the CPC hardware itself only knows about KEY codes, not what symbols they represent (that's entirely a software thing handled by the firmware).
@RobertM: If an emulator would do the mapping like you wish it, it wouldn't be a real usable emulator anymore, at least not for low level programming.
On the CPC you have single physical keys, and these are mapped 1:1 on single physical keys of your PC.
As soon as you write low level stuff, which is just using the key matrix code (0-79) and not the symbol/ascii char (0-255), defined in the CPC rom, you will get problems if the emu is mapping the keys in the way you like. It would be impossible to map the real "hardware" matrix signals in the correct way.
If you want to have a correct mapping in CPC-OS in the emulator you have to patch your ROM or run a CPC basic program, which redefines the Keys, and that's it.
Quote from: andycadley on 23:47, 13 December 22Fundamentally the emulator itself can't do this because it's job is faking hardware and the CPC hardware itself only knows about KEY codes, not what symbols they represent (that's entirely a software thing handled by the firmware).
The emulator already has to map keyboard-keys to CPC keycodes. If that would be customisable, everybody could adapt the mappings to their personal preferences.
Btw: Tiny.js is perfectly mapping the keyboard keys to the right CPC keycodes.
Quote from: eto on 00:09, 14 December 22Quote from: andycadley on 23:47, 13 December 22Fundamentally the emulator itself can't do this because it's job is faking hardware and the CPC hardware itself only knows about KEY codes, not what symbols they represent (that's entirely a software thing handled by the firmware).
The emulator already has to map keyboard-keys to CPC keycodes. If that would be customisable, everybody could adapt the mappings to their personal preferences.
Btw: Tiny.js is perfectly mapping the keyboard keys to the right CPC keycodes.
But they do, that only gets you so far though.
For example, the emulator maps the PC SHIFT key onto the CPC SHIFT key, so pressing SHIFT works as expected. Makes sense. And it maps the PC 8 key onto the CPC 8 key, So pressing 8 gives you a 8, still makes sense.
Then you press SHIFT + 8 on the PC, which would normally give you a *. The emulator dutifully sends SHIFT and 8 key codes to the CPC and the firmware maps that onto (.
The only way to avoid this is to change the key mappings in the firmware. Either by running a bunch of KEY commands or by altering the firmware ROM so the default key definitions match the PC instead. It's not like the emulator chooses not to send the key code for *, because there is no such thing.
Yes this emulator also perfectly maps keys (except i couldn't find "copy" yet)
https://digitonaut.com/retro/amstrad_cpc/emulator.php?type=cpc6128 (https://digitonaut.com/retro/amstrad_cpc/emulator.php?type=cpc6128)
So it can be done and I too wish WinApe would fix its mappings
there should be a software layer between the pc keyboard and the emulated one that does translation
I also wish Winape had a better debugger. One that showed the binary value of registers and also let you navigate quickly to recently used addresses. And right-click and set PC without having to type it
But in saying all this I have to admit i'm the most guilty person for not putting that final polish on their code.. and moving on to other projects. Winape is still awesome
The other day I used basic print command to dump some data to a text file on pc, then manipulate the output in vba then back into winape assembler as defb's!
Quote from: martin464 on 10:17, 14 December 22So it can be done and I too wish WinApe would fix its mappings
there should be a software layer between the pc keyboard and the emulated one that does translation
There is. It's the CPC firmware. And it has to be to not break things in weird ways. Presumably these emulators have a modified firmware ROM, which you could probably just use in WinAPE.
Quote from: andycadley on 10:06, 14 December 22The only way to avoid this is to change the key mappings in the firmware. Either by running a bunch of KEY commands or by altering the firmware ROM so the default key definitions match the PC instead. It's not like the emulator chooses not to send the key code for *, because there is no such thing.
You can send different keycodes if the SHIFT or CONTROL key is pressed.
For a typical UK setup it would look like this:
PC => CPC keycodes => output
8 => key code 40 => 8 will appear
SHIFT + 8 => key codes 21 + 29 => * will appear
Btw: shift+8 is not always * on a PC. German keyboards have it next to the RETURN key. If there is such a mapping feature, I can change the mapping for my keyboard easily:
SHIFT + "+" => key codes 21 + 29 are sent to the CPC => * will appearAnd if it's a Spanish CPC, I need to send other keycodes to the CPC as it has its * on a different key.
Having such a mapping imho would be the better and more flexible choice than changing values in the ROM.
Of course we still need a key for key mapping for those games, that are using one of the keys that can have different positions (e.g. Z, A, W, Y), but for programming and text editing, such a mapping would be a relief.
Quote from: andycadley on 10:31, 14 December 22Presumably these emulators have a modified firmware ROM, which you could probably just use in WinAPE.
No it doesn't have a modified ROM. It's just mapping the PC input intelligently to the keycodes.
If I switch my keyboard language to German, then SHIFT + "+" will return * and if I switch it to UK SHIFT + 8 will return '*".
If I press Z on my (German) Keyboard, it will also output Z as long as my setting is German. When I switch to UK, the same key will output "Y".
You can do it that way, but it will break software in weird ways.
Imagine if a game used 7,8,9,0 and shift for L,U,D,R and Fire respectively. The player hits Up and Fire, the emulator decides they're trying to type a * and so generates a completely different set of key presses and the player thinks the game is broken.
Or someone tries to remap the keyboard in BASIC using KEY commands. Only weird stuff happens because something is already intercepting and changing key mappings outside of the machine.
If the point of the emulator is purely for typing in BASIC programs then sure, it'll work mostly, but otherwise it's a bad solution to an already solvable problem.
So it seems what is required is a custom ROM (one per keyboard layout - UK, US, DE, FR, ES, with PC and Mac variants) for emulators.
But surely it would also be better for the emulator itself to map the key presses to entirely different CPC key press combinations. The emulator is already doing a lot of mapping to display the CPC video and play the audio and emulate a disk, there's no difference with the input device mappings. But then we get key number issues - there are times when we want the key location to matter, not what the key is - software that uses the key codes, not the firmware-provided characters.
I guess the ROMs could be used in all emulators, whereas each emulator would need to be coded to handle the second option, possibly using a function key to switch between mapping and direct methods depending on what you need at the time.
ROMs would probably be the nicest solution. Using something like WinAPE's paste function to just run a user generated set of KEY commands to remap the keyboard within BASIC would probably be the next best solution (and a bit more flexible in terms of letting user's customize to their liking).
Fudging emulators to try and map the keyboard sounds like a good idea, but in practice creates more problems than it solves.
Or someone could make a PC keyboard with a proper CPC layout. :laugh:
I would buy such a qwerty keyboard for sure
Quote from: andycadley on 10:51, 14 December 22Imagine if a game used 7,8,9,0 and shift for L,U,D,R and Fire respectively.
Of course there will be cases, where a game would use a key that is mapped. I guess your example is hypothetical but that's not even required: e.g. any game that is using the keycode of the W-key will not properly work on a French system.
However this only matters if you are not using Joystick (emulation). And for those cases, that's why I think that...
Quote from: eto on 10:35, 14 December 22Of course we still need a key for key mapping
It's relatively few code to include a mapping or just use a key-for-key-mapping. When you play a game with keyboard control, just check that checkbox and you are set.
Quote from: andycadley on 10:51, 14 December 22but otherwise it's a bad solution to an already solvable problem.
We probably have different opinions what a bad solution is. I get your point, that the available option is acceptable for you. To me, patching ROMs with a hex editor is a workaround, as no user friendly solution exists. It's great to know about that option, and I would still prefer a config-file and the option to switch back to a direct key mapping if needed for a particular game.
Quote from: Sykobee (Briggsy) on 11:02, 14 December 22So it seems what is required is a custom ROM (one per keyboard layout - UK, US, DE, FR, ES, with PC and Mac variants) for emulators.
and per system: 464,664,6128 and Plus. (664 might not be required)
Quote from: andycadley on 11:09, 14 December 22Or someone could make a PC keyboard with a proper CPC layout. :laugh:
That can be done at https://www.wasdkeyboards.com/
On the plus side (shift plus?) if all you're doing is prototyping stuff in basic intending to port it all to machine code... it's motivating to get to that point in the project you don't need basic anymore !
based on Offset remapping routines, i'm proud to annonce that AceDL will support physical mapping and true mapping (on supported languages)
i made French, British, German and Spanish keyboards, every keyz are mapped and can be used with any CPC firmware, so spanish will get their N tilde, german their "B" and everyone the § key too...
obviously if spanish/french use a UK firmware the accents wont be in the ROM but mapped as they are supposed to be
do no hesitate to answer this topic about the Layout your are using (i mean, a standard layout on your PC/Mac)
will give a look for Mac user (because Mac is his own standard ;D )
(https://i.postimg.cc/zGwYmkyv/keyboard-mapping.png)
Nice work. 😀
But I was just wondering, why did you need to handle specific keyboard layout presets?
Don't you have the ability to make it totally dynamic?
I mean, original ACE MorphOS version (and I guess Haiku too) can automatically remap any combinaison of keyboard layout for any firmware.
Not feasible on Winux?
Quote from: OffseT on 15:35, 07 October 23I was just wondering, why did you need to handle specific keyboard layout presets?
Don't you have the ability to make it totally dynamic?
Original ACE version works with any combinaison of keyboard layouts and firmwares.
Not feasible on Linux/Windows?
Not now because SDL cant get the value of all keyboard keyz + the code we get is only without shift/altGr
But this drawback makes the code very simpler ;D
If i found an alter-native method to get the mapping, it will be possible to upgrade the code and making it generic
in the meantime, i will make progress on other functionnalities
OK, so a SDL limitation. :(
Poor Belgian, Greek and Mac users then. :D
i looked for greek keyboard and the only thing i found was stickers to put on another keyboard >:(
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.
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
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 (https://www.cpcwiki.eu/forum/emulators/ace-for-linux-mac-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.
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 ??? ?
Quote from: Jean-Marie on 12:10, 05 January 24Yeah, 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 (https://www.cpcwiki.eu/forum/emulators/ace-for-linux-mac-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 :)
Quote from: SkulleateR on 12:13, 05 January 24Nearly 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.
Quote from: RobertM on 11:24, 05 January 24Well 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.
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.
Quote from: roudoudou on 11:52, 05 January 24i 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? 😁
Quote from: andycadley on 15:26, 05 January 24Quote from: RobertM on 11:24, 05 January 24Well 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 "
Quote from: andycadley on 16:15, 05 January 24To 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.
Quote from: andycadley on 16:15, 05 January 24To 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.
Quote from: OffseT on 17:10, 05 January 24Quote from: roudoudou on 11:52, 05 January 24i 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.
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.
Quote from: RobertM on 07:04, 06 January 24I 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.
Quote from: RobertM on 07:04, 06 January 24So 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).
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).
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 :)
Quote from: andycadley on 10:18, 06 January 24Quote from: RobertM on 07:04, 06 January 24I 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.
Quote from: RobertM on 07:04, 06 January 24So 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.
@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
Quote from: roudoudou on 12:55, 05 January 24maybe 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
Quote from: RobertM on 11:27, 07 January 24But 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.
Quote from: andycadley on 17:25, 08 January 24Quote from: RobertM on 11:27, 07 January 24But 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.
Quote from: RobertM on 01:38, 09 January 24[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.
Quote from: andycadley on 11:01, 09 January 24Quote from: RobertM on 01:38, 09 January 24[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.