Jump to content
  • 0
m00dawg

Page Up and Page Down Keycodes?

Question

I noticed that while page up, page down, delete, and a few other keys exist on the mock-up keyboard, these keys don't seem to have valid codes that I can get via the GETIN kernel method and I'm not quite sure what to do about that. Can someone point me in a direction?

Here the test program I use to figure out the keys:

...
main:
  wai
  jsr GETIN  ;keyboard
  jsr graphics::kernal::printhex
  jmp main
...

I also use this PETSCII table (which also doesn't have these keys.

Basically I've been trying to find a way to do page up and page down in my tracker since using the arrow keys can take a while, especially when navigating around a full pattern of 64 rows (or up to 255 orders). I thought about using SHIFT + arrow-keys but, while SHIFT works for the letters, I wasn't getting any different values for the SHIFT-UP for instance. My guess is for that I need to perhaps scan the keyboard directly but I was hoping at least page-up and page-down might be simpler to figure out how to use.

Any ideas?

 

Share this post


Link to post
Share on other sites

5 answers to this question

Recommended Posts

  • 0

Hi,

PageUp and PageDown are simply not supported by the Kernal keyboard routine. As for now, you have no other feasible option than to use some other key or key sequence.

There are also some issues with the GETIN routine inherited from the C64. One problem is that there are overlapping values (for instance ESC is the same value as Ctrl+C). And another is your problem that modifiers don't affect the arrow keys.

In the Kernal, there is in fact a routine to read modifier key status.

That routine is kbdbuf_get_modifiers (call address $ca64 in emulator R38). It returns a value in .A where bits 0 to 4 represents the modifiers as follows:

KBD_MODIFIER_SHIFT = 1 ; C64: Shift
KBD_MODIFIER_ALT = 2 ; C64: Commodore
KBD_MODIFIER_CTRL = 4 ; C64: Ctrl
KBD_MODIFIER_WIN = 8 ; C128: Alt
KBD_MODIFIER_CAPS = 16; C128: Caps

You could use kbdbuf_get_modifiers to catch sequences not distinguishable solely by using GETIN, including I think, Shift+Arrow keys.

kbdbuf_get_modifiers have, however, not yet made it into the public Kernal API, even though there is a comment in the Kernal source saying that it should be. The calling address ($ca64) will probably change for each Kernal upgrade, so using this requires you to update your code when the Kernal changes.

I did register an issue on the Kernal Github page, asking for kbdbuf_get_modifiers to be included in the API with a fixed jump vector. So far there has been no reaction to this.

Link to the issue: https://github.com/commanderx16/x16-rom/issues/182

Finally, on the C64 it was still reasonable (?) to implement your own keyboard scan routines. On the X16 this is a lot more complex, especially with the support for different keyboard layouts.

I have made a pull request on the Github page that would let you intercept the PS/2 scan codes before they are processed by the Kernal. It would work in a way similar to interrupts, letting you change a jump vector that calls your custom keyboard code. If this would make it into the Kernal, you could catch PageUp and PageDown scan codes (or any other scan code) and act on those keys. The beauty is that the rest of the Kernal keyboard routines would not need to be changed. But I haven't got any comments on the pull request either.

Link to the pull request: https://github.com/commanderx16/x16-rom/pull/187

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0

Oh wow that's a lot of great info thanks! Sounds like given where I'm at in the tracker, I'll just have to contend with it for now while I work on the basic functionality bits still. Though seems like I could do ok with the modifiers maybe. At some point I'll want to have some way to do copy/paste of some sort and that's where modifiers could be a lot more important.

Page-Up/Down would certainly also make things faster, but sounds like it's an open issue.

Oddly yeah, I've been meaning to put in a forum post about the open PRs across the github projects. There are now several PRs open for various things.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Your tracker looks very nice by the way.

Another thing. Apart from PageUp and PageDown, the user experience is also affected by the key repeat rate, i.e. the rate at which a key is repeated while held down. In a keyboard controlled program, the user-experience is often better if the repeat rate is fast. Fast repeat decreases the need for other cursor movement options, such as PageUp/PageDown/GotoNextWord and so on.

I recently made a post regarding the key repeat rate. In the C64, this was apparently controlled by the Kernal. Skimming through the X16 Kernal, there seems  to be no mechanism for key repeat control. I think the repeat rate will be controlled by the PS/2 keyboard controller. If you change the key repeat rate in your host system, this will also affect the key repeat rate in the emulator, suggesting that the Kernal is not handling this property.

But then, how can you set the key repeat on a real X16? I have seen that you may send commands from a computer to a PS/2 keyboard to set, for instance, the key repeat rate. As for now there is no function in the Kernal to support that. It would, however, be doable to implement this yourself, if need be.

Edited by Stefan

Share this post


Link to post
Share on other sites
  • 0

This has been a common question for a while now and Stefan explained it perfectly. There are several other keys that can't be detected by standard Kernal routine at this time and I was assured that all the keys on the keyboard will have function in the future. I expect they will also fix some discrepancies like for example not use F4 to switch between 40/80 display when there is a dedicated button for it etc.

Share this post


Link to post
Share on other sites
  • 0

Thanks Stefan! I'm working on it (the tracker) slowly but surely. Pretty amazing to see how small 8-bit assembly programs can be. I'm at 4.8kb in total and that's without really trying super hard to save space. That's pretty wild (of course there is a lot more to add still)!

Good point on the key repeat. That works in the tracker (e.g. SHIFT-BACKSPACE can be held down and it'll delete the channel data all the way down the pattern). It could be a bit faster perhaps though yep. Another issue is TAB vs SHIFT-TAB to easily switch to other channels. Scrolling right in the pattern doesn't work yet but the expectation is to support up to 16 channels on the PSG (though I might double up and make them multi-timbral and/or integrate with Concerto which would make the channels more dynamic) and 8 for the FM. So that's a lot of channels to have to navigate through without a quick way to do so.

Given the keys are available on both keyboards, I would guess some level of support is planned. I guess we'll have to see! For now I can get by with what I have, though it's not ideal. One thing that will probably be an accidental "feature" is wrapping. So for the order list, if you're at 00, you can arrow up to go to FF so you don't have to scroll all the way down (though I've never seen a song 255 orders long and I might lower the amount of orders perhaps). I will probably do that for pattern editing too at least for now (it's less code heh). If/once page-up/down work I might switch to a more conventional UI maybe.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use