keyboard I/O using system calls

[DamageX]

Hey, my login still works. (And my old thread is still on the front page!?!?!?)

I want to write a more substantial program using this compiler and it's my understanding that 68K Amiga programs can also run on PPC systems when abstaining from direct hardware access in favor of using OS functions. So in the interest of cross-platform goodness, I'm looking for some help with keyboard I/O using input.device.

The code posted in my old thread has a section which appears to install an input handler. I tried to repurpose this code but the call to "DoIO" causes a freeze in this context.

I saw this documentation but unfortunately it is full of Amiga OS jargon like signals, message ports, and such, and it refers to header files that I don't have.

Three primary steps are required to open the input device:

    Create a message port using AllocSysObject() and ASOT_PORT type. Reply messages from the device must be directed to a message port.
    Create an extended I/O request structure of type IOStdReq or TimeRequest using AllocSysObject() and ASOT_IOREQUEST type. The I/O request created by the AllocSysObject() function will be used to pass commands and data to the input device.
    Open the Input device. Call OpenDevice(), passing the I/O request.

I don't see AllocSysObject in my listing of exec functions.

If anyone can point me to assembly language source for a simple WB program that accepts keyboard input it would be enlightening.

P.S. apologies to anyone who sent me a PM during the last five years. I just noticed a bunch of them.

[DamageX]

I got something to work. It seems that createmsgport and createiorequest are the proper system calls.

Code: [Select]

        asm
        move [4].d,a6

        ; create msgport
        jsr [a6-666]
        tst d0.d
        beq fail5
        move d0,[msgport].d

        ; createiorequest
        move [msgport].d,a0
        move $30,d0.d
        jsr [a6-654]
        tst d0.d
        beq fail6
        move d0,[ioreq].d

        ; open input.device
        move inputname,a0.d
        move [ioreq],a1.d
        move 0,d0.d
        move 0,d1.d
        jsr [a6-444]            ; opendevice
        tst d0.b
        bne fail7

        ; install input handler
        move [ioreq],a1.d
        move 9,[a1+$1C].w
        move ihheader.a,[a1+$28].d
        jsr [a6-456]            ; doio
Also need this goofy thing and an input routine.

Code: [Select]

ihheader:
        dd 0,0
        db 2,127
        dd ihname.a
        dd 0
        dd ihcode.a
ihname:
        db "great input handler",0


Code: [Select]

        ; input handler
        asm
ihcode:
        move a0.d,[a7-]

ihloop:
        move [a0+4].w,d0
        cmp $0100,d0                   ; keyboard event?
        bne ihnotkey       

        move [a0+6].w,d0
        move $7F,d1.d
        and d0,d1.w
        add keytable,d1
        move d1,a1.d
        move d0.b,[a1]

;        move 0,[a0+4].b                ; clear event
ihnotkey:
        move [a0].d,a0
        move a0.d,d0
        bne ihloop

        move [a7+],d0.d
        rts
        endasm
This receives all input though even if its window is not in focus. That's a bit awkward.

[guest11527]

If anyone can point me to assembly language source for a simple WB program that accepts keyboard input it would be enlightening.

Well, AmigaOs does not quite work that way. Generally, you do not want "any keyboard input", but "keyboard input that goes into your application", and typically "keyboard input that goes into your window".

There are essentially two methods: If you "just want to print text and receive keystrokes", the easiest is to Open() a RAW: window, such as "Open("RAW:////Title",MODE_NEWFILE)" (this is Open from dos.library) and then perform WaitForChar(), Read() and Write() from the dos.library, and Close() when you are done. This is single-character I/O. WaitForChar() waits for a while (or not at all) until a character is available from the keyboard. Read() returns it, and Write() prints text.

Typically, however, you want to use intuition. In this case, you can draw graphics into the window, and react on events going into the window. For that, look up "OpenWindow", "struct NewWindow", "CloseWindow" to open and close a window. Also, "OpenWindowTagList" which recommended under 2.0 and up.

For receiving keyboard events, use "ModifyIDCMP" on the window, and either ask for "VANILLAKEY" to receive ASCII character for all those keys that have a single-character binding (e.g. alphanumeric, and *not* the cursor keys and other control keys) or "RAWKEY" for raw key codes which you would have to translate yourself. You then GetMsg() on the "window Port" (see struct Window in intuition/intuition.h) and receive there IDCMP-Events (see also intuition/intuition.h) you can react upon.

The input.device is the *wrong* track. That is a global dispatcher mechanism for piping all types of events through the system, and it is not window-specific, i.e. it cannot identify where the input goes, and in particular, whether it goes into your application or some other place. It is only the source for events where intuition generates IDCMP messages from.

[DamageX]

Thanks for the input (no pun intended). Does IDCMP work with a custom screen instead of a window? Or do I have to open some kind of dummy window first?

Currently my test program opens a window or a screen (according to command line option) and then only uses writechunkypixels to update it in either case.

WaitForChar doesn't sound adequate in this instance, since I want key up/down events rather than characters.

[guest11527]

Thanks for the input (no pun intended). Does IDCMP work with a custom screen instead of a window? Or do I have to open some kind of dummy window first?

A screen does not have an IDCMP port. You need to open a window on the screen first. Which is recommended anyhow as the window will include a layer and as such perform clipping. But you can always create a backdrop-borderless window on the screen, so the result will look like a blank screen in first place.

WaitForChar doesn't sound adequate in this instance, since I want key up/down events rather than characters.

Not that I would recommend this in your case, but there is no problem here either. The RAW handler just sends you a CSI sequence for cursor movement, so there certainly is the possibility to interpret cursor keys. However, it is "one additional layer of indicrection" you probably do not need.

[DamageX]

Everything seems to be working. An example program is here. This only uses the keyboard to stop decoding and close the window, but I am using similar code in a game engine I'm working on to move sprites around and whatnot. My A2000 doesn't feel like booting today but I tested in winuae and amazingly, I dug up my old Efika with morphos 2.1 demo and it worked there as well.