From helens!shelby!rutgers!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekfdi!videovax!bill Thu Jun 14 13:36:24 PDT 1990 Status: RO Article 1901 of comp.sys.handhelds: Path: helens!shelby!rutgers!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekfdi!videovax!bill >From: bill@videovax.tv.tek.com (William K. McFadden) Newsgroups: comp.sys.handhelds Subject: Re: Assorted HP48 questions Message-ID: <5850@videovax.tv.tek.com> Date: 13 Jun 90 19:24:58 GMT References: <8815@hacgate.UUCP> Reply-To: bill@videovax.tv.tek.com (William K. McFadden) Organization: Tektronix TV Measurement Systems, Beaverton OR Lines: 86 In article <8815@hacgate.UUCP> ferris@tcville.HAC.COM () writes: >I have the distinct impression, and I have a sinking feeling that it is >because it is correct, that for an object to be globally accessable, >it must reside in the HOME directory. If this is indeed true, it is >unfortunate there isn't a path variable the user can create. Some time ago, jc@atcmp.nl (Jan Christiaan van Winkel) posted a method of getting around this. What you do is create a { HOME LIB } directory and use a program called 'SVC' (service call) to call it. The SVC program resides in your home directory. It is true that the LIB directory gets full of lots of programs, but I think it is better than having them cluttering the HOME directory. Anyway, here is the program (with some improvements I've made): SVC (Bytes #1C7Fh 49) << PATH ;get current path SWAP ;get program name in level 1 { HOME LIB } EVAL ;go to LIB directory (HOME LIB by itself also works, ;but bombs in debug mode, i.e., single stepping) RCL ;recall library routine to stack SWAP EVAL ;go back to original directory EVAL ;execute library routine >> To use this routine from a program, you put the library routine's arguments on the stack, followed by the name of the routine in single quotes. Then call SVC. For example: 6.133990 'DOW' SVC Which returns "Wednesday" to the stack. Notice also that SVC returns to the original directory before executing the library routine. Hence it will use that directory's environment. >The situation >in which this creates the most trouble is having a program in a lower >directory assigned to a key. When in another directory and in USER mode, >pressing that key places on the stack the name of the program, which EVALs >to only itself. Instead of assigning 'DOW' to a key, you would assign << 'DOW' SVC >> to the key, making it globally accessible. However, this forces you to put DOW in the LIB directory. If this is not desirable you could instead assign to the key << PATH HOME DIR1 DIR2 .. DIRn DOW EVAL >>, where HOME .. DIRn is the path to the program (DOW in this example). If you wanted the program to reside in the other directory but execute in the current one, you could use << PATH HOME DIR1 DIR2 .. DIRn 'DOW' RCL SWAP EVAL EVAL >>. In effect, you would assign a custom version of the SVC program to the key. These ideas could also be extended to control alarms that execute a program in another directory but leave the calculator in the original directory when finished. >Is there a _system provided_ way to make a key assignment >inactive when not in the directory that the object assigned to that key >resides? What this boils down to is having different key assignments for >each directory. Is this possible? Other than using menu keys, I don't know of a way to unassign a key when you leave the directory. I suppose you could use TYPE or IFERR to detect the existance of a program and evaluate it if it's there or execute the default function if it isn't. For example, << IFERR 'DOW' RCL EVAL THEN DROP SIN END >> would execute DOW if it exists, otherwise would execute SIN (or whatever the default function is for that key). >I have noticed when using the BYTES command, that 100% of the time, the >number of bytes returned is _lower_ than the amount specified either in >the manual or by other people when keying their programs. The checksums >match, but the byte count is lower. I have revision D of the ROMs, and >I've been wondering if HP came up with a different way to store objects >that is less space consuming. Now I certainly won't pass up more >efficient data compactions! This, too, puzzled me at first. I discovered you can get two different answers depending on what you supply to the BYTES command. For example, 'SVC' BYTES returns #1C7Fh 49, but 'SVC' RCL BYTES returns #1C7Fh 41.5. The difference is the first call to BYTES included the program name in its count, and the second didn't. I have seen programs posted to the net both ways, but I believe the HP48 I/O firmware uses the first version. Happy programming! -- Bill McFadden Tektronix, Inc. P.O. Box 500 MS 58-639 Beaverton, OR 97077 bill@videovax.tv.tek.com, {hplabs,uw-beaver,decvax}!tektronix!videovax!bill Phone: (503) 627-6920 "The biggest difference between developing a missle component and a toy is the 'cost constraint.'" -- John Anderson, Engineer, TI