search

kierenj / 0x10c-DevKit

0x10c DevKit
http://0x10c-devkit.com/
39 stars 4 forks source link

Generic keyboard not responding to arrow keys #108

Closed tsiemens closed 12 years ago

tsiemens commented 12 years ago

When an arrow key has been pressed, HWI with A = 1 returns 0x0, when it should return 0x80 - 0x83

kierenj commented 12 years ago

Hi - I do not believe that is the expected behaviour. "Store next key typed in C register, or 0 if the buffer is empty" - arrow keys are not typed (they are not ASCII printable), they are pressed and released. I did base the keyboard emulation code on the official emulator - have you experienced something different to DevKit in the official emulator, or do you have any other evidence that arrow keys should be enqueued?

Acruid commented 12 years ago

http://dcpu.com/highnerd/rc_1/keyboard.txt

The arrow keys should be returning the hex numbers shown in the spec. 0x80 is outside the ascii range of keys so you are right in that they should not be printed. I'm also going to note that the shift key and the control key also return 0x0 in the emulator, when they should be returning 0x90 and 0x91 respectively.

tsiemens commented 12 years ago

Hi,

No, I suppose not. I was just going through an old program I had
written in DCPU studio, and the program was based on reading the arrow
keys from the buffer. I suppose I should be reading them from an
interrupt now? Is that where the keys are read?

On May 5, 2012, at 10:17 AM, Kieren Johnstone wrote:

Hi - I do not believe that is the expected behaviour. "Store next
key typed in C register, or 0 if the buffer is empty" - arrow keys
are not typed (they are not ASCII printable), they are pressed and
released. I did base the keyboard emulation code on the official
emulator - have you experienced something different to DevKit in the
official emulator, or do you have any other evidence that arrow keys
should be enqueued?

Reply to this email directly or view it on GitHub: https://github.com/kierenj/0x10c-DevKit/issues/ 108#issuecomment-5528788

kierenj commented 12 years ago

Acruid - my interpretation of the spec and the RC1 emulator is that only ASCII-printable keys are queued for reading back with interrupt 1. Only regular keys and backspace, return, insert and delete are queued up: the others (anything > 0x13, according to the RC1 code) is not queued up. Unless you can point me at a program running in the official emu returning 0x80 or above from that interrupt call, this is not a bug..

Acruid commented 12 years ago

After looking into this further, you are correct. Feel free to close this.