The Sinclair QL Forum

Posted: **Tue Feb 22, 2022 2:56 pm**

how can we get keyrow values from assembly? it seems to be by only "peeking" i/o addresses, isn't it?
(btw, is there any i/o ports/memory arrangement documentation around that you could reccommend? unexpanded QL only, please...)

Posted: **Tue Feb 22, 2022 3:04 pm**

Call TRAP #1 with MT.IPCOM is a way!

Posted: **Tue Feb 22, 2022 3:09 pm**

Oh and the bibles

The Sinclair QDOS Companion
Andrew Pennell

https://www.goodreads.com/book/show/211 ... -companion

And the Sinclair Technical Manual.

http://www.dilwyn.me.uk/docs/manuals/qltm.pdf

Posted: **Tue Feb 22, 2022 4:13 pm**

The problem I have found calling KEYROW from S*BASIC or Assembler, C68 etc, is that even if the program doing the scanning isn't the one currently with focus, the scan will pick up the keys pressed for any other program that is accepting input. This is a minor pain in the bum on a multi -tasking system.

Also, I know you mentioned the original unexpanded QL only, but on QPC2 V5.0x, under Wine on Linux, having KEYROW calls in a loop, absolutely hammers the CPU! Probably a Linux/Wine things which is why I'm not complaining, merely mentioning what I have observed.

Cheers,
Norm.

Posted: **Tue Feb 22, 2022 4:37 pm**

NormanDunbar wrote:The problem I have found calling KEYROW from S*BASIC or Assembler, C68 etc, is that even if the program doing the scanning isn't the one currently with focus, the scan will pick up the keys pressed for any other program that is accepting input. This is a minor pain in the bum on a multi -tasking system.

There's not much you can do about this because there is no way to find out if a job is owning the console atm. (On the other hand, you can scan for keypresses even if your job isn't, which is a good thing, for screen savers or spellcheckers, for example)

NormanDunbar wrote: Also, I know you mentioned the original unexpanded QL only, but on QPC2 V5.0x, under Wine on Linux, having KEYROW calls in a loop, absolutely hammers the CPU! Probably a Linux/Wine things which is why I'm not complaining, merely mentioning what I have observed.

On original QLs, tight loops with keyrow scans are slowed down by the system call having to wait for IPC responses and thus leave CPU for other tasks. On most SMSQ/E systems, however, KEYROW simply looks into a buffer (where the host OS stores the pressed keys), which obviously results in a much tighter loop with no wait-time. I don't think what you're seeing is a Wine-only phenomenom.

Posted: **Tue Feb 22, 2022 4:53 pm**

Thanks Tofro, I appreciate the info, but as I mentioned, I wasn't complaining, merely advising (because I love sticking my nose in, uninvited!) about a potential problem or two, with KEYROW.

But, it's always useful to be better informed, and I'm definitely t hat now. Thanks again.

Cheers,
Norm.

Posted: **Tue Feb 22, 2022 5:27 pm**

when trying to know better about a hardware, i normally use mame/mess sources as reference - https://raw.githubusercontent.com/mamed ... ers/ql.cpp (some info about the keyboard seems used as ipc_port1_w there), but i have no idea which i/o port are, how to access them, and even more, i have no idea at all what is that trap thing about... xD (as comparison, i read zx-spectrum "keyrow" from i/o, so i expected reading from ql in the same way somehow )

Posted: **Tue Feb 22, 2022 5:44 pm**

nitrofurano wrote:when trying to know better about a hardware, i normally use mame/mess sources as reference - https://raw.githubusercontent.com/mamed ... ers/ql.cpp (some info about the keyboard seems used as ipc_port1_w there), but i have no idea which i/o port are, how to access them, and even more, i have no idea at all what is that trap thing about... xD (as comparison, i read zx-spectrum "keyrow" from i/o, so i expected reading from ql in the same way somehow )

TRAP #1 is a 68000 instruction.

QL has standard ones, one of the standard ones is to read/write to IPC.

Posted: **Tue Feb 22, 2022 5:46 pm**

If you go here:
https://github.com/NormanDunbar/QLAssem ... ns_ant.asm

At line 79ish, there's the date for an IPC COMMAND to read KEYROW(3) of the keyboard, which gets ENTER, ESC, The arrow keys and backslash, I think!

Code: Select all

;--------------------------------------------------------------------
; Check ESC key pressed IPC command string.
;--------------------------------------------------------------------
ipc_command
           dc.b    9,1,0,0,0,0,1,2

That address is loaded into register A5 for safe keeping.

At line 408 onwards, is a routine "hadEnough" which sets up the call to MT_IPCOM as it was known back then, to call a KEYROW(3) read.

Code: Select all

;--------------------------------------------------------------------
; Read the keyboard and check on the ESC key. If pressed, we are done 
; here. If not pressed, go around again after suspending for a few
; frames.
;--------------------------------------------------------------------
hadEnough
           move.w  d5,-(a7)            ; Direction gets corrupted
           exg     a3,a5               ; We need the IPC command in A3
           moveq   #mt_ipcom,d0        ; IPC command coming up
           bsr     doTrap1             ; Dies on error
           move.w  (a7)+,d5            ; Restore direction
           exg     a3,a5               ; Cells address in A3 again
           btst    #esc,d1             ; ESC pressed?
           beq     hangAbout           ; No, go around
           moveq   #0,d0               ; Yes, show no errors
           bra     suicide             ; Kill myself

The call to doTrap1 is this:

Code: Select all

doTrap1
      trap #1
      tst.l d0
      bne.s suicide
      rts

So, basically, set up the command for the KEYROW, set up the registers to call it, call doTrap1 and return if no errors were detected.

On return, from the trap, bit 3 of the register D1.B is set if the ESC key was pressed.

HTH

Cheers,
Norm.

Posted: **Tue Feb 22, 2022 5:56 pm**

nitrofurano wrote:when trying to know better about a hardware, i normally use mame/mess sources as reference - https://raw.githubusercontent.com/mamed ... ers/ql.cpp (some info about the keyboard seems used as ipc_port1_w there), but i have no idea which i/o port are, how to access them, and even more, i have no idea at all what is that trap thing about... xD (as comparison, i read zx-spectrum "keyrow" from i/o, so i expected reading from ql in the same way somehow )

With regards to keyboard handling, the QL is very different from the ZX Spectrum. While the keyboard is handled by the main CPU in an interrupt service routine that fills a system variable in the ZX Spectrum, the main CPU in the QL is not involved in keyboard handling at all - That's done by the second CPU, the 8049 IPC. Comms between the main CPU and the IPC is two-wire serial and not something you want to mess with directly.

Here's a short piece of code that uses the QDOS MT.IPCOM call to ask the IPC for a specific keyrow value (row 1 in this example):

Code: Select all


***************************************************************************************
* keyScan
* Check keyboard row 1 (cursor keys, ESC, Enter and Space)
* return result in d1.b
* trashes d5 and d7!
***************************************************************************************
keyScan 
                lea.l   IPC_Cmd,a3
                move.w  #$11,d0
                trap 	#1
                ; (QDOSMT$ MT.IPCOM)
                rts 

IPC_Cmd         dc.l    $09010000               ;IPC command 
                dc.l    $00000102               ;9=kbd,1=4bits in,2=8bits out (set to read row 1 in here)

The Sinclair QL Forum

keyrow from assembly

keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly

Re: keyrow from assembly