Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : PicoMiteVGA: Any possibility of KEYDOWN ?
Author | Message | ||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
Hi Peter, I've been trying to keep my head-down but INKEY$ just isn't cutting it for arcade games (because you get one key-press and then you don't know what is happening until/unless the keyboard repeat kicks in). Is there any hardware or Pico SDK limitation that prevents the PicoMiteVGA from having a KEYDOWN() function (reporting at least 2 keys), if not then I don't suppose you could be prevailed upon to implement it ? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
Major re-write of the keyboard interrupt routine (originally written by Geoff) so sorry no |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
Fair enough, but could you confirm (or deny) that a PS/2 keyboard does send keyup/keydown signals rather than just pre-processed key-presses so if some foolhardy youth wanted to have a go when (if ever) he clears his current slate then it wouldn't be impossible ? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
It does send keyup but they are completely ignored apart from modifier keys if(KeyUpCode) { if(Code == L_SHFT) LShift = 0; // left shift button is released else if(Code == R_SHFT) RShift = 0; // right shift button is released else if(Code == CTRL) Ctrl = 0; // left control button is released else if(KeyE0 && Code == 0x11) AltGrDown = 0; // release the AltGr key on non US keyboards else if(Code == KeyDownCode) KeyDownRegister = 0; // normal char so record that it is no longer depressed goto SkipOut; } You would need a table for other keys and respect the language keymapping and have all the special cases for language ALT keys |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3422 |
How does CMM2 work around this ? I understand CMM2 has KEYDOWN Volhout PicomiteVGA PETSCII ROBOTS |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
USB keyboard not PS2 so repeat requires handling keyup and remember how many auto-repeat bugs the CMM2 had if you miss a keyup. The PS2 version is MUCH simpler Edited 2022-09-26 04:33 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
Thanks for your responses Peter. I note that the CMM1 with a PS/2 keyboard did have KEYDOWN() but only for a single key, so maybe in time I will be able to do something on the PicoMiteVGA. Best wishes, Tom Edited 2022-09-26 19:23 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2282 |
hi peter, there is one way that may be easy to implement, though i'm not suggesting you do it - in fact i have no use for the functionality myself. within the keyboard handler, once any scan code has been decoded simply add it to a 16-entry ring buffer located somewhere in RAM, with the the byte following the buffer holding the current 'head' value (the location of the next empty slot in the ring buffer). either locate the ring buffer at a fixed address, or better still at an address that can be retrieved with MM.KBDINDEX. then leave the rest up to the programmer to handle. the programmer can read the 'head' value, and set their own 'tail' to this value. thereafter, whenever they see head<>tail they know to do: new_scan_code=PEEK(tail) tail=(tail+n) mod (16*n) ' (where n is the size of each slot) print new_scan_code all the heavy lifting is thereby pushed onto the programmer, while the RAM overhead could be as little as 17 bytes (i don't know how long the PS/2 scan codes are). cheers, rob :-) |
||||
Rickard5 Guru Joined: 31/03/2022 Location: United StatesPosts: 328 |
is there anyway to use an FDDI - serial for Keyboard INPUT ? I turned the volume on the monitor to max and could hear sound. Thanks Stanleyella |
||||
Rickard5 Guru Joined: 31/03/2022 Location: United StatesPosts: 328 |
is there anyway to use an FDDI - serial for Keyboard INPUT ? I turned the volume on the monitor to max and could hear sound. Thanks Stanleyella |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8516 |
Check OPTION SERIAL CONSOLE in the manual |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3422 |
It may ease the keyboard control of games (and it may violate your NES controller project, Tom). But it may be worth realizing that Mauro's games all use KEYDOWN for keyboard control. So some form of workaround would be nice before next years programming challenge (*) Volhout (*)=since CMM2 is made from unobtainium, the target will most likely be picomite. And without external hardware (some form of controller) your game must rely on keyboard. Edited 2022-09-27 01:12 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3422 |
Maybe it is as simple as adding MM.LASTKEY that points to a memory adress that contains the last key received. In basic you would Lastkey = peek(MM.LASTKEY) Poke MM.LASTKEY,0 All Peter would have to do is write the last key received into that memory address before adding it to the keyboard buffer. And add the pointer to that address to the structure with MM.xxx Or am I oversimplifying thing...? Edited 2022-09-27 02:57 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1081 |
Quite the dilemma. Many of the games I've written for the CMM2 rely on being able to distinguish 2 simultaneous key presses, usually arrow keys. This made porting to the PicoMite ... interesting. Visit Vegipete's *Mite Library for cool programs. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
@Turbo46 and I have already talked off-TBS about this and I am looking at adapting the work I've been doing on PicoGAME controller support into a more general controller (and keyboard masquerading as controller) framework/library covering CMM2, PicoMite and MMB4W. We could then consider allowing use of that library in next year's programming challenge (assuming there is one) without it counting against the 5K limit - to be discussed closer to the time. I apologise for not opening discussion or details of this library up at this time on TBS (though it's very similar to what I've published previously on the PicoGAME), but historical experience is that discussion of "controller standards" gets nowhere and is soon buried under hardware schematics for various controller schemes. To my mind this is not a hardware problem per se but a software problem concerned with the definition of an API for simple controller "device drivers" (written in MMBasic.) My plan is to run with it solo for a little longer before reporting back. You need a scheme that allows you to read what keys (at least 2) are depressed at (as close as possible) the current time. i.e. not historical data and you need to be able to tell if a key is still being pressed, which INKEY$ can't do, or has been released. I'd prefer to have nothing in the immediate future rather than some "hack" that is then detrimental to have something better later and closer to the CMM2/MMB4W KEYDOWN() functionality. Peter seems to have confirmed it is technically possible so I will take a look myself when I've cleared a couple of other things from the bench, and perhaps either I will succeed (I think I'm capable of working on the PicoMite firmware), or my amateur flailings may cause Peter to take pity on me. Best wishes, Tom Edited 2022-09-27 03:57 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3807 |
You can get part-way there either by reading INKEY$ repeatedly until you've processed all the characters currently in the buffer, or registering an ON KEY interrupt to handle key-presses immediately and set a bitmap which you then read (and clear) when you are ready to handle the input. The problem with both methods (which are basically equivalent) is you can't detect when a key is being held-down and not released. Best wishes, Tom Edited 2022-09-27 03:54 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5645 |
PCs detect key-up messages in order to do n-key rollover. This works well on PS/2 but USB keyboards have a problem as they only handle a small number of simultaneous keys. I have a (virtually) n-key rollover USB keyboard but it achieves it by fooling windows into letting it be two devices. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
hitsware2 Guru Joined: 03/08/2019 Location: United StatesPosts: 705 |
cringe my site |
||||
Print this page |