Path: funic!news.funet.fi!sunic!mcsun!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!samsung!cs.utexas.edu!usc!snorkelwacker.mit.edu!ai-lab!rice-chex!bson
From: bson@rice-chex.ai.mit.edu (Jan Brittenson)
Newsgroups: comp.sys.handhelds
Subject: Re: Becoming an official HP48SX developer????
Message-ID: <14293@life.ai.mit.edu>
Date: 23 Mar 91 00:55:29 GMT
References: <981@sousa.enet.dec.com>
Sender: news@ai.mit.edu
Organization: nil
Lines: 97

In a posting of [20 Mar 91 17:33:22 GMT]
   ervin@pinbot.enet.dec.com (Joseph James Ervin) writes:

 > After completing my screen dissolver, it has occured to me to start
 > writing some more general audience stuff for the HP48 that can utilize
 > the power of machine language code.

   Then it may be of interest to you that I'm in the final phase of my
MLDL (Machine Language Development Library - I hope no one objects to
my use of this classic acronym), which will contain an ML debugger and
a disassembler, both use AG mnemonics. I will soon post a beta
version.


 > Specifically, it is difficult to implement animated graphics without
 > access to a hardware timer.  I know there is one in the 48SX, but I
 > have no information regarding how to access it.

Did you examine chip-48?


 > Furthermore, direct access to the IO registers which control/sample
 > the keyboard would be a must, it seems to me.  You'd want to be able
 > to do things like test for "key pressed and held" for things like
 > rotating your galactic meanie-destroyer, or changing your speed, etc..

   Hum. I tried this, and it didn't work too well. The problem is that
the keyboard interrupts, and you have to keep playing with both
interrupts and the 0xf bit of the ST register. I found out that
instead of polling the keyboard (which is done by IN/OUT instructions,
and beware! the keyboard is somewhat oddly wired) it's much simpler to
poll the system keyboard buffer. Appended at the end is a piece of
code which will both poll the keyboard and wait for a key to get
pressed. The key is removed from the buffer. So you should combine
this with a manual scan: poll the system buffer until you have a key
and then scan the keyboard it's pressed. When it's released you go
back to checking the system keyboard buffer.


						-- Jan Brittenson
						   bson@ai.mit.edu


 O  /
  \/
  /\  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 O  \

;; kb.star -- keyboard interface

	radix	0x10

keybuf = 704ea

;; Poll keyboard. System-based version. Returns the scan code in A.A.
;; Trashes C.A, B.B, and D0. The C bit is set if a key was pressed,
;; otherwise it's cleared.
;;
;; This is a mutation of the ROM prefixed machine code routine to
;; get/peek the next entry in the keyboard buffer.


kb_poll:
	move.5	keybuf+1, d0	; KB Put ptr
	move.s	@d0, a		; A.S = put ctr
	dec	d0
	move.s	@d0, c		; C.S = get ctr
	breq.s	c, a, $100	; Ctrs are equal - buffer empty

	move	c.15, p		; P = get ctr
	inc.s	c		; Remove key
	move.s	c, @d0

	swap	c, d0
	add	p+1, c
	add	p+1, c		; C += get ctr, in bytes
	clr	p
	move	c, d0		; D0 = &next key
	clr.a	a
	move.b	@d0, a		; A.A = key
	retsetc
$100:
	clr.a	a
	retclrc


;; Wait for a key to become pressed, then return the scan code in A.A.

kb_get:
	call	kb_poll			; Get key, if any
	brcc	kb_get			; Keep trying until we get something
	ret				; Return with scan code in A.B

	end

						-- Jan Brittenson
						   bson@ai.mit.edu