[comp.sys.handhelds] hp48 graphics, timings, terminal emulator and more!

tjb@tadtec.uucp (Tim Bissell) (04/11/90)

Greetings!

It is time for me to stop lurking.  I imported a hp48sx from EduCalc a
couple of weeks ago, and am mightily impressed -- Well done Mr. Wickes et al.

I am busy delving into the graphics capabilities of the 48, with the intention
of writing a "Little Brick Out" program (that's Breakout to everyone who has
not used an apple ][).  An important factor is speed, so I wrote a program
which I use for timing program fragments.  I call it BM (for benchmark,
because it is quick to type if it is not in the current directory) and it
works like this:

< args > 'ProgName' BM

i.e. push any arguments needed on the stack, then quote the name of the
program to be tested, then run BM.  It returns a time in seconds for the
program to run.  Using this I have determined:

A) Word size influences the speed of operations on binary numbers; i.e.
   + takes 8 times longer for 64 bit integers as it does for 8 bit integers.
   For graphics programs, 8 bit integers are perfectly adequate.

B) Using pixel coordinates is considerably quicker than using complex numbers.
   Even though I have had to write a function to add two pixel coordinates
   (PXADD below) while complex numbers can be added with +, graphics
   subprograms are in general around 50% faster.
   (This assumes 8 bit integers).

I have a question for hp48 gurus out there.  For a given keypress I would like
to run a program.  I.e. when the user presses (say) key 25.1 (up-arrow) I
would like to run the UPBAT program to move the bat up on the screen.  I
have got to do this while moving the ball on the screen so I cannot use
USER mode bindings directly.  Is there a SYSEVAL or something that I can
pass a key coordinate and have the program associated with that key run.  It
would save me having a huge (and slow) CASE statement to handle user input.
This would probable help speed up the Terminal Emulator program as well.

Also, the latest version of the terminal emulator posted had a corrupted
line in the file at our site.  The middle string of the three that appeared
to be associated with keymaps had a ^H^I.^K in the middle of it, and appeared
to be considerably shorter than the other two.  The last string also had a
^H where the DEL key should be.  Did anyone else have this problem.  If
not could someone mail me a working version?

Also, is there any chance of the HP-LINK programs being posted?  I have no
FTP capabilities and would love the chance to fill up my memory some more!

-----------------------
@
@ Benchmark program
@ USAGE: arguments... 'Progname' BM --> time (Real number, in seconds)
@
%%HP: T(3)A(D)F(.);
@ Checksum: # 9FD4h
@ Bytes: 80.5		(When stored in a variable called BM)
\<< DEPTH 1 + TICKS
SWAP ROLLD EVAL
TICKS \-> ee
  \<< DEPTH ROLL ee
SWAP - B\->R 8192 /
  \>>
\>>
-----------------------
@
@ Now can anyone do faster than this?  I do not consider machine code
@ cheating ;-)
@
@USAGE: { #x #y } { #x1 #y1 } PXADD --> { #(x+x1) #(y+y1) }
@
%%HP: T(3)A(D)F(.);
@ Checksum: # BA68h
@ Bytes: 57		(When stored in a variable called PXADD)
\<< LIST\-> DROP 3
ROLLD OVER 1 GET +
3 ROLLD 2 GET + 2
\->LIST
\>>

-----------------------

Cheers,

Tim

-- 
Tim Bissell  Tadpole Technology| (tjb@tadtec.UUCP || ...!mcsun!ukc!tadtec!tjb)
Castle Park, Cambridge ENGLAND | "...If you're gonna take off your clothes
 where you gonna put your wallet, 'Cos skin ain't got no tailored pockets..."

madler@piglet.caltech.edu (Mark Adler) (04/11/90)

I use the following benchmark program:

%%HP: T(3)A(R)F(.);
@ TIMR crc #D3C0h length 74
\\<<
  MEM DROP              @ do garbage collection
  TICKS \-> $$$ \<<     @ save current tick count
    EVAL                @ run program with stack contents
    TICKS               @ get tick count when done
    $$$ - B\->R         @ compute ticks elapsed
    86 -                @ adjust for time to assign $$$ and do TICKS
    8192 /              @ convert to seconds
  \>>
\>>

I believe storing the ticks in a local is more appropriate, since the
execution time of the program will depend on how much stuff is on the
stack, so the timing routine should not change that.  Also, the
garbage collection is necessary to get consistent results.  Even with
the MEM DROP, the timing is still dependant on the amount of free
memory, since that determines how often garbage collection is done.
I'll leave how to figure out the "86 -" as an exercise for the reader.

Mark Adler
madler@tybalt.caltech.edu

prestonb@hpcvra.CV.HP.COM (Preston Brown) (04/12/90)

>I have a question for hp48 gurus out there.  For a given keypress I would like
>to run a program.  I.e. when the user presses (say) key 25.1 (up-arrow) I
>would like to run the UPBAT program to move the bat up on the screen.  I
>have got to do this while moving the ball on the screen so I cannot use
>USER mode bindings directly. 

You can check the keyboard directly with the KEY command.  It returns
0 if no key is pressed or the keycode and 1 if a key is pressed.  You
will still need something like a case statement but a good way to do
this is with a list of commands that you index into with the keycode.

The most serious problem with real time code are the garbage collects
which make the timing unpredictable.  If you have a place with extra
time you can execute MEM DROP to force a garbage collect, then you 
will have a little time free from unpredictability.

Preston