Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
  You are not logged in - nap
Keyboard IO Routine   [2013]

Released by :
Creators [web]

Release Date :
29 July 2013

Type :
C64 Misc.

AKA :
Keyboard Driver

Website :
http://codebase64.org/doku.php?id=base:scanning_the_keyboard_the_correct_and_non_kernal_way

User rating:awaiting 8 votes (8 left)

Credits :
Code .... TWW of Creators

Download :

Look for downloads on external sites:
 Pokefinder.org


User Comment
Submitted by TWW on 30 July 2013
@ Stein: In that case, it should have worked.

Shadowing is when 3 keys form 3 corners of a rectangle in the scan matrix. This will "light up" the 4th corner as well (and in the case of PAL the 4th corner is W). But if you scan the rows and check the bits corresponding to PAL, it should have worked?!

EDIT: The downside is that PAW would also work :-)
User Comment
Submitted by Stone on 30 July 2013
@TWW: My routine checked if P+A+L were pressed and didn't care about any others.
User Comment
Submitted by Hein on 30 July 2013
hmz, my routine says 'pla' is pressed, that's not the same as 'pal'. :)

looking for rom independent keyboard read routine
User Comment
Submitted by TWW on 30 July 2013
Stein: "PAL" gives shadowing (even in vice so no idea how you didn't see this before fireing it up on a real thing).

If you scan the matrix for PAL you will find "PAL". Only difference is that you will find "W" as well. Does this behave differently on the real thing?

however what this routine does is to allow you to press in sequence and hold "P"+"A"+"L" then release the "P" you will correctly get a "L" recognized as soon as the shadow bug is cleared.

For typing (not hidden part detection which is completely out of the scope of this routine) this works how a keyboard scan routine should work IMHO. Now try it on the KERNAL and let me know :-)
User Comment
Submitted by Stone on 30 July 2013
For the hidden end part (tribute to PAL) in Trick and Treat I had implemented a check for the keys P+A+L being pressed simultaneously. Good thing we tested it on real HW, because it works in VICE but not on the real thing. What a total waste it would have been not being able to surprise our dear friend at the X-2012 demo compo... So: What Groepaz said.
User Comment
Submitted by TWW on 30 July 2013
3 keys works for some combinations. For those combinations it doesen't work, you just sith them out (simplest is to check if there are more than 3 indications in the scan matrix). The only thing we can be sure of is that if you have 3 or less indications in the scan matrix, the result is gold. From here it is easy to code a routine which handles this.

If this works in the emulator (which indeed do shadowing and weird stuff to the keyboard (like in real life)) and the routine is not discriminative of specific combinations but instead apply a general policy (which is unversal) it will work fine on the real thing too.

I believe what GPZ is saying is that the definition "3 key rollover" can't exist as there are some cases where this isn't possible. I don't worry too much what the routine is called what I care about is that it does what it is supposed to do as far as technically possible. And ofcourse if this is a source of concern for potentioal users I'll add a warning :-)

The only statment I made was that I believe my routine does this better than the 3-key rollover routine by Bruce Craig and a lot better than KERNAL.

It is easy to reduce the number of keys to 2 which in most human cases will suffice but why not keep it to 3 and allow the routine do the thinking for you when this works or not.
User Comment
Submitted by Hein on 30 July 2013
Interesting, i've written a keyboard scanner that can handle 3 keys (+ shift or c=) at once. At least it does in Vice. What am i missing here? A real c64?
User Comment
Submitted by chatGPZ on 30 July 2013
"I'll agree if you can tell me in which situation 3 detected keys (and only 3 in the whole matrix) is a possible bust."
uhm. thats another way to define the problem - indeed if only 3 keys are detected, then they are correct. thats not what i was saying - what i was saying is that you can not press 3 arbitrary keys and reliably detect them. (meaning "3 key rollover" is not possible)
User Comment
Submitted by TWW on 30 July 2013
"you can NOT reliably detect 3 or more keys. period."

I'll agree if you can tell me in which situation 3 detected keys (and only 3 in the whole matrix) is a possible bust.

From what I've seen so far (If what I see is correct), is that if you can read 1-3 keys out of the matrix, the reading is true. You have 4 or more you can't trust the reading (which is in no small part the methodic I use to get the routine to work as it does). Now it could be a total smeg-up on the real thing but as I said, no way to test.

On the other hand, hitting 2 or more keys down at exatly the same time (one scan - blank, next scan - 2 keys) is that there is no way to figgure out which key was supposed to be first so it will be down to chance. Only way to imrove this would be to call the scan routine more often then once a frame.
User Comment
Submitted by chatGPZ on 30 July 2013
" it won't harm anything unless someone is clever enough to use the key inside their SW for some purpose or another (Muhahha)."
if the feature is there, someone _will_ use it. why would it be there if you cant use it? pointless :)
" Not sure I understand why a warning should be needed as there is, as you elegantly put it, no way to to reliably read more than 3 keys at once. Some times 2 is the limit. "
you contradict yourself there. you can NOT reliably detect 3 or more keys. period. the user should be made aware of when ghosting happens, and why. (and its not just "sometimes" =P)
User Comment
Submitted by TWW on 30 July 2013
Gpz: Thanx for the comments.

- adding shift-lock as a regular key is a bad idea, since it doesnt actually work reliable on all C64s. (on most of mine the behaviour changes depending on how hard i would punch it....)

Wasn't there originally but I figgured it's a cool feature (hehe) Anyhow if it doesen't work on a particular breadbox, it won't harm anything unless someone is clever enough to use the key inside their SW for some purpose or another (Muhahha).

- you shouldnt even consider testing this stuff in emulators. VICE only emulates some of the weirdo effects related to keyboard (and as you found out already, it doesnt emulate joystick+keyboard at the same time correctly). all other emulators i have checked dont emulate these effects at all. on top of that PC keyboards have their quirks aswell, adding more confusion on top.

Yeah. I'll hopefully get some better means of testing soon but meanwhile, it's what I got.

- the code should come with a warning that clearly points out that proper generic detection of 3 (or more) keys at once is infact not possible at all, due to how the keyboard matrix works.

Not sure why anyone would hit 4 keys or more simultaniously but sure.

If more than 3 keys detected, the result is ignored and waits for a new valid scan and validates with old scan buffer to see what is good and what was crap. Not sure I understand why a warning should be needed as there is, as you elegantly put it, no way to to reliably read more than 3 keys at once. Some times 2 is the limit. But the routine makes the best out of it but ofcourse you can always trick a routine like this by going bananas on the keys.

In short: If you find more than 3 keys activated in the matrix, it's a bust. I should perhaps have clarified that on codebase too but I figgured the referance to Mr. Craigs article covered it.

I'll update it when I am done with the V1.1 of the routine (have already made several improvements to the code itself saving some cycles but still keeping it less than 2 pages including tables). Also it's fun to review your own code as there is always some way to do something more elegant.

However I am interested in is the "API" part if someone has good pointers on what a good practice there would be.
User Comment
Submitted by chatGPZ on 30 July 2013
things that come into mind here:
- adding shift-lock as a regular key is a bad idea, since it doesnt actually work reliable on all C64s. (on most of mine the behaviour changes depending on how hard i would punch it....)
- you shouldnt even consider testing this stuff in emulators. VICE only emulates some of the weirdo effects related to keyboard (and as you found out already, it doesnt emulate joystick+keyboard at the same time correctly). all other emulators i have checked dont emulate these effects at all. on top of that PC keyboards have their quirks aswell, adding more confusion on top.
- the code should come with a warning that clearly points out that proper generic detection of 3 (or more) keys at once is infact not possible at all, due to how the keyboard matrix works.
User Comment
Submitted by TWW on 30 July 2013
Found A VERY strange behaviour in VICE. Activate Joystick in port #2.

then press 1, 2 or 3 keys on the keyboard. then start playing around with joystick in Port #2.

On my setup (2.4.27398) the part which scans Control Port #1 actually reads input from Port #2. Unless I've done something very pequilar (which may very well be the case).

Why upload? Coz I'd like some criticism if something is wrong or could be done better (not on the test program but the IO routine itself).
Search CSDb
Advanced
Navigate
Prev - Random - Next
Detailed Info
· Summaries (1)
· User Comments (13)
· Production Notes
Fun Stuff
· Goofs
· Hidden Parts
· Trivia
Forum
· Discuss this release
Support CSDb
Help keep CSDb running:



Funding status:




About this site:
CSDb (Commodore 64 Scene Database) is a website which goal is to gather as much information and material about the scene around the commodore 64 computer - the worlds most popular home computer throughout time. Here you can find almost anything which was ever made for the commodore 64, and more is being added every day. As this website is scene related, you can mostly find demos, music and graphics made by the people who made the scene (the sceners), but you can also find a lot of the old classic games here. Try out the search box in the top right corner, or check out the CSDb main page for the latest additions.
Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.092 sec.