Arrow-key constants

[venomix666]

You mentioned previously somewhere (in a pull request comment I think) that you intended to define constants for the arrow keys. What do you think about using the ASCII-codes for the ctrl-combinations that *nix has used since forever?

Up ctrl+p [0x10]
Down ctrl+n [0x0E]
Left ctrl+b [0x02]
Right ctrl+f [0x06]

Would the best place to add these on the application side be to drivers.inc/screen.h or do you see any use for the arrow keys in tty applications?

[davidgiven]

Those will conflict with control keys --- I ran into this on the ADM3a, which uses ^H, ^J, ^K, ^L and it's actually really annoying that you can't use this keys for anything else. Consider WordStar which uses ^K a lot.

High-bit-set codes are more appropriate here IMO because in the largely 7-bit world of CP/M we know these can't overlap with either printable or control characters. I was vaguely thinking of using the BBC Micro ones, $88/$89/$8a/$8b for this.

[venomix666]

I thought of conflicting with control keys as a good thing, as you can fake the arrow keys if you are using a computer or terminal without them, but I see your point of conflicting with other uses for these key combinations as there are no standard expected functions in most cases (as there are on most unix-like systems).

I agree that using high-bit-set codes is a cleaner way to implement this, letting the bios code handle any odd cases when needed.

[venomix666]

I tried to add arrow key translation to the Apple II bios, but I have not figured out how to distinguish the arrow keys from Ctrl+h/j/k/u.

Does someone know if it is possible to read the raw keycodes somehow, instead of the translated ASCII? 

I tried checking bit 1 of KEYMODREG (0xC025) to see if Ctrl is pressed without any luck. I'm not sure about the expected behavior here, this could perhaps be an emulation promblem?

Apart from this, I think this has been implemented on most platforms with a SCREEN driver, so maybe the issue could be closed?