Author: [Rick Grevelle]
  Subj: CMACF Fix
  Date: Wed Sep 12 1990 07:57 

Thanks to J"urgen Koslowski for pointing out an error in the create MACF
routine.  However, the fix offered isn't quite right.  The one below is.

CMACF [4152]

%%HP: T(3)A(D)F(.); 
\<<
       # 3174197160731741h
       # 181314E331741607h
       # 4173170EC6A830F8h
       # C808461241731705h
                   ^^^          digits transposed, ought to read 731!
   1  3  START
          # 5193h   SYSEVAL
         NEXT  #2DCCh
          # 5A03h   SYSEVAL
          # 5ACCh   SYSEVAL
\>>
 

In regards to your question concerning the instruction DA; it is a MOVE,
register to register, and is explained in the Processor Notes as follows:
 
-------------------------------------------------------------------------

MOVE Register to Register

               ppz      MOVE.f s,d

                                           pp | f     z | s d
                                          --------   ---------
                                           A8 | P     4 | B A
                                           A9 | WP    5 | C B
                                           AA | XS    6 | A C
                                           AB | X     7 | C D
                                           AC | S     8 | A B
                                           AD | M     9 | B C
                                           AE | B     A | C A
                                           AF | W     B | D C
                                           D  | A     

Examples:

D9     MOVE.A  B,C       ; C gets B   (20 bits)
AE4    MOVE.B  B,A       ; A gets B    (8 bits)
AFB    MOVE.W  D,C       ; C gets D   (64 bits)
DA     MOVE.A  C,A       ; A gets C   (20 bits)


>Another suggestion concerning this program: It seems to me that the
>new HP48 instruction NEWOB can be used to replace "" +, saving 2.5 bytes.

In an effort to keep routines such as these short, it becomes necessary to
use a bit of trickery.  STRING->CODE uses a combination of two tricks; one 
used by Alonzo in his PEEK scheme, and another one that I discovered.  The
point here is that NEWOB will indeed work and save 2.5 bytes in doing so.

However, neither of the two are particularly efficient.  They are merely a
convenient manner in which to compensate for the forementioned lazy trickery.

It should be mentioned that HP does not use trickery of this sorts.  Thanks
to a variable length PEEK routine written for the 28, I was able to isolate 
and disassemble the routines responsible for updating low RAM when new objects
are created.  

A more recent example of how this is done in the 48 can be found in the ->ASC 
and ASC-> routines recently posted by Dr. Wickes.  The details involved here
are numerous, and time required to understand them would be great.  Now that
school is back in full swing, I have no such luxury!

Rick Grevelle