Hello, Guest the thread was called515 times and contains 24 replays

last post from mega65 at the

Xemu Windows to MEGA65 keyboard mapping

  • The other thing to mention is that I've mapped every keypress that I can possibly find on a Windows keyboard to the MEGA65 equivalents. I couldn't find anything like this on the Xemu wiki.


    I am happy to add this to the wiki on github as I'd assume it's worthwhile for most people using the emulator?

  • Key mapping is always a hard question :( I believe more on the positional mapping rather than symbolic. The later is more comfortable but it has problem, if a key is shifted on the PC but not on the M65, or vice versa, or we must forget the possibility to check state of the SHIFT key alone, or at least other problems can occur, it's always a hard question for an emulator. Currently Xemu can only do positional mapping. To be honest, even not every C65 key is mapped, but only the C64 subset ... The mapping table is currently "hard-coded" into the emulator, but you can find it here:


    https://github.com/lgblgblgb/x…ev/xemu/c64_kbd_mapping.c


    I guess, maybe no need for deeper C knowledge to understand, since most of this file is a table, which is used for key mapping. There are tons of things to do in this area, like:


    * there should be symbolic mapping anyway?

    * what should be the default mapping type symbolic or positional?

    * more sane values for the default positional mapping than current one?

    * configuration possibility for mapping, without the need to hack the code, so a user can do it as a config option ...

    * in general about Xemu: some kind of GUI possibility for configuration, since the previous point may need editing config files and such (not now, since it's currently not implemented to alter the key mapping, but in the future)


    And yes, documentation of key mapping, is maybe not a bad idea at all! Just, I am not sure it's worth, if it turns out, it should be heavily modified anyway soon?

  • Thanks for the link to the map source. It's handy only for the comments that help tell what key it maps to as for now, the source only has values which aren't map to an enum to explain what key goes where.


    For example this is a snippet of what I have:


    Perhaps enums for those scancode values would be useful for someone reading which key does what?

  • Ehhh, I'm sorry, it's my fault. it seems I cannot think outside of the box (... of my own world), since it was kinda clear for me at the first sight, but no wonder, since I wrote that code. You're right, that's maybe far from being enough. OK, I'll comment that file on lines basis about the PC -> C64 mapping. But anyway, my points are still valid, that I'm thinking: even if it's documented, maybe it should be changed first for a better mapping and documenting it only after that point.


    Please check the URL out some time later, hopefully I can find some minutes to put some sane comments there.


    Thanks for noticing.


    I'm not sure about the enum idea of yours: the hex values in the table are row/col of the matrix for low/hi nibble of the byte, but special meaning for some values, it would be hard to enumerate those in a same way (as you can see, there is some |8 for special keys etc) in a clean way. I think, relative few people want to read the source code :) and who wants, I can fix that with more sane comments. And anyway, I should really make it possible to load custom key mapping without modifying the source + recompiling, that's very true.

  • Thanks for the offering! And sorry for being late, I haven't done my commit I promised though :-O


    Any documentation help is warmly welcomed for sure. As well any suggestion to do things differently. Xemu quite well shows my own view on how things should work. But my view can be kinda minority among users, so any feedback is welcomed. A developer's view in any project is kinda often turned out to be not the one which is important for the users, you see :)

  • This is what I am using so far. Not everything has been located. But as you said, not every key may be mapped.

  • I'm about to modify keyboard mapping, and I would like to hear opinions. As I've already stated too, in general.


    The main problem, that only C64-compatible keys were even emulated till this point. C65 (thus M65 too) by design wanted to be reasonable compatible with C64. So the keyboard matrix works the really same way. However we have some extra keys, those are handled differently. What makes that hard from the viewpoint of keyboard mapping, that there are simply too much keys on the C65/M65 keyboard, how I should map those to a standard PC keyboard? Note, that we're talking about positional mapping, not symbolic (ie, what is shifted on C65 needs to be shifted on PC, and what is not a shifted key on C65 can't be a shifted key on PC either).


    For example, C65 has function keys F1,F3,F5,F7,F9,F11,F13. If I map those keys for the right PC keys, there is the problem, that regular PC keyboard does not have F13. Also, it would be a bit miss-leading (maybe?) too much those keys to F1,F2,... etc, since keys F2,F4,... etc are shifted F1,F3,... etc keys on the C65 for real. For some more easy access, I would map PC's F2 as being F1+shift. But then you see, we exhaust PC function keys quite quickly. And we haven't even talked about the HELP key ... (at least cursor up and cursor left is handled on the C65 at hardware level to have shifted down,right, which is easy to be emulated).


    Also, regular PC keyboards have three different "modify" keys, shift, control, alt. C65 has four, control, shift, alt and "commodore" (on M65, the "commodore" key is maybe marked as "M" for "mega" key, for copyright reasons on the "commodore" name, I assume, but surely, the function is the same).


    And so on.


    My approach would be probably to use the same PC keyboard mapping what Mega65 would use with PC keyboard attached (ie with the Nexys4 FPGA board). However, even then, there can be some minor problems, because Xemu is an emulator and runs on a top of an OS (ie, Windows, MacOS, Linux ....), where some keys are usually owned by the OS, for some functions, and not so much a good idea to try to use that for the emulator. For example, C65's "NO SCROLL" key is quite logically can be "Scroll Lock" on PC (similar name ...), but that key can have special role on some OSes. Also, "windows" key is candidate for having having four modifier keys on the PC to be able to be assigned for the four "modifier" keys of the C65, but again, windows key (or the equivalent on other platforms) can have special role on a PC, so again, here I have the problem.


    The funny thing, that mapping keys are the much less technical challenge in writing an emulator (ie, just a table) but still the hardest to think about a sane solution which is good for users. Especially with Xemu, where there are at least four different platforms it must be run on:


    * Linux and UNIX-likes OSes in general

    * Windows

    * OSX

    * Javascript/js.asm/webassembly (inside a browser with the help of the emscripten compiler)


    These can have different layouts a bit, and also different keys where are usually cannot be used by user software. Surely, there can be a per-platform mapping, but for obvious reason, it should be not extreme to avoid confusion, etc, in my opinion.

  • Can you make it read the key map from a file on start up if a special command line option is given?

    That way people can use their own maps, if they want to, and experiment with different mappings to see what they like.

    In general, I'd suggest mirroring VICE as much as possible, then deal with the extra keys to make something still hopefully sensible.


    Paul.

  • This is definitely tricky.


    For function keys, it would be possible for F2 to be accessed by both F2 on the PC as well as Shift + F1 on the PC. Of course then you run out pretty quick. Does Alt + Function or Control + Function have any function on a real Mega65? If not, that combination on the PC could access the higher Function key numbers, Help, No Scroll and maybe more?

  • Can you make it read the key map from a file on start up if a special command line option is given?

    That way people can use their own maps, if they want to, and experiment with different mappings to see what they like.

    In general, I'd suggest mirroring VICE as much as possible, then deal with the extra keys to make something still hopefully sensible.


    Actually, that's the plan, to read mapping from a config file, just having some hard coded default anyway, if there is no other choice has been made by the user to override it.

    I'm not sure about VICE's mapping, I thought for M65 emulator, the most nice way would be to mirror the choice of the M65 itself if PS/2 kbd is connected, it makes more sense. Hmm, or maybe not :) After all, the primarily form of M65 would use its own keyboard, PS/2 kbd feels more like a development solution to have some easy-to-find solution with the Nexys4 board.

  • This is definitely tricky.


    For function keys, it would be possible for F2 to be accessed by both F2 on the PC as well as Shift + F1 on the PC.

    Currently, this is the situation. PC F1 is mapped as M65 F1, F3 as M65 F3, etc .... PC F2,F4,... are mapped to M65 F2,F4...+Shift pressed. Thus, pressing PC key F1 with shift has the very same effect as pressing only F2 with or without the shift, since it's "virtually pressed" anyway. The same way, as cursor up and cursor left is just shifted cursor down and cursor right (though these at least are existing solutions even on C64 for real this way, while with function keys, it's just Xemu does the same not a real C65). Though, this "wastes" available PC keys to be mapped a lot, for function keys, and those are hardly used in my opinion most of the time. So maybe it's better to stick with F1,F2,F3 PC keys to be mapped as F1/F3/F5 ... even if it looks strange we don't run out of keys.

    ANYWAY. I think maybe with configurable mapping, it just matter of the user what's used, and maybe just it's me who makes this topic a so huge deal, when it's not ... ?

  • My initial motivation for key mapping was to try to arrange keys resembles the "look" of a C65 keyboard by key positions, and/but using different positions when it was not possible to do so. '+' was placed to "Insert" as there was not enough keys in a row on a PC keyboard mimics the C65 look ;-P So that was so simple theory, but indeed, hard to remember then, even I can't find sometimes :-O

  • If someone feels adventurous, the "dev" branch of Xemu on github can be tried (now just from source ...). Currently it has some preliminary support for custom keymaps. On startup both of Xemu/C65 and Xemu/M65 emulators creates a file keymap-default.cfg in the corresponding "pref" (preferences) directory for the C65 or the M65 emulator inside Xemu (preferences directory is platform/system dependent but can be read in the console/terminal, "SDL preferences directory: ..."). That file must be copied, and then customized (the default file is overwritten by Xemu at each startup!!!), and either be loaded with the -keymap option, or can be renamed to keymap.cfg in the same directory to load automatically without any option.


    Also, there is preliminary support for extra keys of C65/M65 (over C64 keys, I mean). Some of them are not-mapped by default, but can be done with custom keymaps. See also the comments in the keymap-default.cfg.


    Yes, it's still a bit hard to configure Xemu, since it's a config file based scheme, and you must know the SDL scancode names, etc, to be able to do that. But at least, if there are some useful layouts, it can be provided to download for users then, which is still better than modify Xemu source and recompile ... The GUI component of Xemu to be able to configure this graphically would be currently hard, since literally there is no any GUI in Xemu, just a single SDL window ... That would require a ton of works, and also would be not platform independent (ie, Windows, Linux, Mac ...) or a full GUI framework should be developed and/or utilized on the top of the SDL2 ... :-O

  • Yeah, I'll be curious to give this a try soon, as I was reading in the c65 txt manual about how the BASIC editor mode supports new text attributes (flashing? Underline?) and thought it might be fun to give those a try, but the catch was I need to press the c65's escape key to start typing their escape sequences.


    So will give the dev branch a try to see if I can get a kick out of seeing flashing and underlined text in BASIC :-D

  • Interesting, as usual I'm more in the hardware itself, I didn't even know about the process you've described above ... I guess it would be interesting for others too, if you have some posts about it in the future?


    I've just tested that TAB works now (and btw I have to move restore to pageDown, since TAB was used that purpose ... for more, see the mentioned keymap-default.cfg file in the preferences directory, or the source file xemu/c64_kbd_mapping.c).