USEND & URECV
Universal IR Send and Receive
Version 2.0, Febuary 1993
by Dan Kirkland


USEND and URECV are fast, all purpose, send and receive
programs for FAST data transfer between two HP48's.
With USEND and URECV, you can send objects directly from the
stack without storing them in a variable.
Try putting a library on stack level one and sending it!
You must use USEND on the sending HP48 and URECV on the send HP48.

                    FAST!  COMPARE!

PACMAN directory from goodies disk #7, 8308.5 bytes.
program used          SEND       TSEND (v2.0)   USEND (v1.0)*
time in seconds     115.026       66.072         28.707

QED.font from QED1.07, 2244 bytes
program used          SEND       TSEND (v2.0)   USEND (v1.0)*
time in seconds      42.273       23.456         6.252

A list of small variables, (unknown bytes).
program used          SEND      TSEND (v2.0)    USEND (v1.0)*
time in seconds      52.114       31.896         10.483

All times were with flag -36 (RECV overwrite active) and
flag -39 (I/O messages suppressed) set to provide the
fastest times for SEND and TSEND.
*USEND, Version 2.0, is a little faster (6% ?) than Version 1.0.

                    
                    USEND  USAGE

USEND will send ANY type object from stack level one.
USEND uses flag #1 (user flag).

   With flag #1 clear (no 1 in the status area).

Defined variables (both global and local variables that have
something 'stored' in them) are sent and stored in the current
directory on the receiving HP48.
Undefined variable names will be sent and left on the stack
of the receiving HP48.

  SENDING LISTS

The objects in a list will be sent separatly and defined
variables in the list will be stored in the current directory.
To send a list as an complete object, either put the list as
an object in another list or set flag #1 (see below).
Defined variable names nested inside two or more list will
be sent as as names in a list. The object stored in the
variable will not be sent.
Only defined variable names are stored in the current
directory, all other objects are left on the stack of the
receiving HP48.

  With flag #1 set (a 1 showing in the status area).

Stack level one object sent as is to stack level one of the
receiving HP48.
This means that all variable names will be sent as variable
names only.
Lists will be sent as one complete object.
The receiving HP48 will receive to stack level one exactly
what was sent from level one of the sending HP48.


                    URECV  USAGE

Just execute URECV on the receiving HP48.
URECV does NOT use any flags (flag #1 only needed for USEND).

                    SAMPLE PROGRAMS

SSTK    (Send Stack)     BYTES: #1332h 34.5
         Arguments:      obj#n ... obj#1 #n  ->
\<<
 \->LIST
 1
 \->LIST 
 USEND
\>>

RSTK    (Recv Stack)     BYTES: #CA2BHh 32
         Arguments:                          ->  obj#n ... obj#1

\<<
 URECV
 OBJ\->
 DROP
\>>

With flag #1 clear, USEND will send the objects in a list
seperately and will store all defined names in the HOME
directory. Set flag #1 or use this next program to send a
list so the receiving HP48 will receive it as the same list.

SLIST   (Send List)      BYTES: #49F1h 33
         Arguments:      { obj#1 ... obj#n } ->
\<<
 1
 \->LIST 
 USEND
\>>

                    COMMENTS

USEND and URECV do not require any setup (except maybe 
flag #1).
USEND and URECV are quiet. They do not display what is
being sent. If the data transfer arrow is blinking, then
everthing is okay.

USEND and URECV do not do packet checks like the built in
SEND program (and TSEND). So, don't move the HP48's once
you start the transfer.

URECV does a checksum check, so any object is sure to be
the same as the object that was sent.

With USEND, there is no longer any need to store a library
in a variable to send it. Just put the library on the stack
and send it. It will be received on the stack of the receiving
HP48 and can then be stored in the proper port with no
variable to purge.

USEND and URECV were written and tested on HP48 version E.
USEND and URECV were written in "system" RPL using supported,
unsupported, and some, as yet, undocumented ROM entry points.

Feel free to use and/or do with these programs what you wish.
I make no guarantees. If you are overly worried that these
programs (or any other program that I write) may cause you
problems, THEN DON'T USE THEM!

Thanks to Detlef Mueller for his RPL and library tools,
without which these programs would not be.
Thanks to James Shirey for the use of his version J hp48;
these programs work okay on version J.

Any comments, questions, or suggestions send email to:

                   kirkland@ee.utah.edu

Dan Kirkland