billw@hpcvra.CV.HP.COM (William C Wickes) (09/18/90)
Eric Toonen recently posted a list of HP 48 bugs, and others have asked me various questions about the list. So here are some comments on those bugs. Also, many people have questioned my use of the term "version 1E", thinking that the "1" must mean something. It doesn't. In R&D we have always referred to the various HP 48 code versions as 1A, 1B, etc. I just forgot that the "1" hasn't been used "in public." Generally, a letter change represents a new version that has various defect fixes but no design functionality changes. A number change is associated with a major redesign, not defect fixes. For example, the HP 28C had versions 1BB and 1CC--two ROM's, two letters (There were 1AA prototypes built, but never sold.) The HP 28S did have functionality changes relative to the HP 28C, so its code was version 2BB. Since you never know when a revision will be necessary, the revision codes only work backwards. That is, a version 1E implies that there was a version 1D, but not that there will be a 1F--or a 2A. * Regarding the bugs in Version D: > [1] (This one was documented by HP) (X,\<)Y) in the equationwriter > has X and Y interchanged. Fixed in E. > [2] (This one was documented on the net) ARCHIVE crashes when done if the > clock is in the display. Fixed in E. Note that it doesn't always crash, and when it does it waits until the archive is finished. > [3] SST\|v recalls a directory rather than entering it. Side note: > it is made into a new object. (Solution: Use NEXT to check whether or > not the next is an unquoted directory name, and use SST if it is) Not changed in E. What SSTv is doing is recalling a stored object, then if it is a program it gets single-stepped, otherwise it gets executed. The 48 manual does not mention that this behavior is different from SST for directories. > [4] The evaluation of undefined local names does not function > properly. For example, try the following program. The 1 and 2 can be > any value. > > 1 2 > \<< \-> x > \<< > \<< \-> y 'x' > \>> > \>> > \>> > EVAL EVAL > > This program leaves an 'External' after giving the error "Undefined > Local Name" (This bug is in both HP28C's, the HP28S and HP48's A > through D !) Not fixed in E. This does not have anything to do with evaluating local names, but is a defect in ->, which forgets to mark the stack for error recovery. If the first object in an algebraic following -> is an undefined local name (an unresolved XLIB name would probably do the same), then as many "bad" objects are returned to the stack as -> took off. This bug is the new champion for longest undiscovered RPL bug. Fortunately, it doesn't really have any bad practical consequences, as long as you discard the system objects if you ever do run into this error. > [5] When you enter a command line (without starting PRG entry > mode), and you go to the PTYPE menu, select a plot-type, the command > line is evaluated, but left in the display, and you can start a new > command line underneath. Not fixed in E. Only cosmetic. > [6] You cannot enter a GROB of size 0 x 0 unless it is the last > thing on the command line. A syntax error occurs on the thing after > the "GROB 0 0". (Solution: You can type #0 #0 BLANK) Not changed in E. > [7] The calculator can be made to recurse by defining a unit in > terms of itself. (Press ON and C to exit the recursion.) Not changed in E, and not worth the performance penalty and complications to try to change. Solution: Don't Do That. > [8] The parser does not check enough in an edited Directory > object. With some holes resulting: > > [8a] Resulting from [8], the calculator can be made to recurse by > editing a Directory object, defining a variable as itself. (Press ON > and C to exit the recursion.) Not a bug. You can do the same with STO or by VISITing a variable, and you definitely would not want the calculator to prevent it. There are many circumstances in which it is desirable to store a variable's name in the variable. > [8b] Resulting from [8], you can 'hide' a variable, by editing a > Directory object, and name a variable the same. Then you have a > directory containing variables with the same name, of which only the > first can be evaluated, recalled or stored in. There are labels for > every entry, but only the first one determines whether or not a > directory overscore is displayed for (all) the labels. Never said you couldn't do this. Not a bug. > [8c] With [8b] in effect, if one of these (named-the-same) > variables is a directory, you can see the first (even if that one > isn't the directory!) in the plot-catalog. Ditto. > [9] When you VISIT a directory, it recalls and edits correctly, > but the edited directory cannot be stored back. Not a bug. This is part of the general rule that you can't store into a non-empty directory. > [10] When you strike any key, and quickly thereafter hit [ON], you > will go to the HOME directory. All flags are left intact, you can even > continue with your command line (if you had one). Fixed in E. > [11] While typing an equation in the equationwriter with implicit > () off, and then turn the implicit () on, when typing a backspace, the > equation changes as if implicit () were on all the time (losing the > correct equation). You cannot restore your original equation, because > if you reverse these actions, it inserts parentheses. (Bill Wickes > says this is not a bug, but STORC considers this a bug, because you > can not reverse this action.) He still says it's not a bug. > [12] Some kermit error messages have carriage-return and line-feed > characters at the end. This results in blocks on the screen. They > occur (at least) after the messages "Transfer failed" and > "Interrupted". Not changed in E. > [13] This is not really a bug, but it is weird. When you type CLUSR > (preferably in a list or a program :-), it is displayed as CLVAR. The > history of this fact is that CLUSR was the HP28 command, and CLVAR is > the HP48SX command. CLUSR is an alias for CLVAR, to help with execution of HP 28 programs. > [14] The keys STO and PURGE don't have correct string descriptors > inside. This is because the LASTARG work-around is in the key > descriptor, rather than in the command itself. This results in the > following facts: > > [14a] When you type STO or PURGE with too few arguments, you get > "Error:". When you type STO or PURGE with enough, but wrong type > arguments (reals, for example,) you get "STO Error:" (Yeah, or "PURGE > Error:") (Solution: (This disables the LASTARG work-around.) When Usr > mode is on, explicitly re-assign PURGE and STO to the PURGE and STO > keys. You can do this with the following command: { STO 32 PURGE 54.2 > } STOKEYS) > > [14b] \GbENTER (with vectored enter in effect) gets an empty string > when you pressed the STO or PURGE keys. (Solution: (This disables the > LASTARG work-around.) explicitly re-assign PURGE and STO to the PURGE > and STO keys. You can do this with the following command: { STO 32 > PURGE 54.2 } STOKEYS) The LASTARG recovery associated with the STO and PURGE keys is a feature, not a bug. > [15] \|vMATCH and \|^MATCH don't check for equations or > expressions. This results in the fact that you can get multiple equal > signs in a single symbolic. (You can do this with EXSUB on the HP28S > and HP28C.) Example: > > 'A=A' > { 'A' '7=8' } > \|vMATCH > > resulting in '7=8=7=8'. > > (Recalling this in the equation writer correctly results in an > "Invalid Syntax" error.) Not a bug. You wouldn't want MATCH to have to reparse an expression upon every substitution. If you don't like it, don't do it. > [16] If the custom menu is your current menu, and you enter a > directory of which the variable 'CST' does not contain a list (or a > name of a variable that does), you will cause a system halt. > (Solution: do not use bad values in 'CST' to disable the CST button.) Not fixed in E. Note that this is not a system halt--it's like the reset done in [10] above. The stack remains intact. > [17] TRNC and RND allow for an array in level 2 and a symbolic in > level 1 of the stack. This allows you to put an array in a symbolic. > Example: > [ 2 3 ] > '7/8' > RND > > returning 'RND(UNKNOWN,7/8)' Fixed in E.
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (09/18/90)
Ok, the $2^6 K question is...what is HP's policy on ROM upgrades under warranty? I just bought my HP48SX Saturday and it's a version D. I mailed my warranty card in this morning. -- John M. Adams --**-- Professional Student on the six-year plan! /// Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// "We'll always be together, together in electric dreams" Tangerine Dream \\V// Cosysop of BBS:42; Amiga BBS FIDOnet 1:3612/42. 904-438-4803 (Florida) \X/
madler@piglet.caltech.edu (Mark Adler) (09/18/90)
>> Ok, the $2^6 K question is...what is HP's policy on ROM upgrades >> under warranty? Call HP calculator support ((503)757-2004) and tell them you want to get on the upgrade reservation list. They will ask if you've experienced any problems with the calculator. Say "Yes, entry of a symbolic complex number in polar form returns the incorrect result." They'll say fine, get your calculator serial number and your address, and send you a letter confirming that your "unit" has been approved for replacement, and that the replacement units will begin shipping in "early 1991", and that you will be notified where to send the calculator prior this time (you pay for postage to send it back, they pay for the postage on the new one). Mark Adler madler@piglet.caltech.edu
bio_zwbb@jhunix.HCF.JHU.EDU (William Busa) (09/18/90)
An unfriendly behavior of the 48 which I have run afoul of several
times, but have never seen listed as a bug, involves INPUT (by the by, I
have a Revision D ROM). Try the following:
\<< "" "" INPUT
DO
UNTIL 0
END
\>>
INPUT puts the 48 into Program Entry Mode, but PROGRAM ENTRY MODE IS NOT
EXITED once INPUT has done its job! The command line, with an ugly frozen
cursor, is still displayed while the DO loop runs. Dr. Wickes, is this a
bug? It seems to me that INPUT should leave the machine in the same state
it found it in -- i.e., Program Entry Mode should be cleared.
I originally became aware of this while playing with Rick
Grevelle's SYSEVALed keys. I wrote a short program employing INPUT to
permit me to input a SYSEVAL number to execute. The "alpha" SYSEVALs
behave in an interesting fashion when called while Program Entry Mode is
active -- a program won't terminate until it receives alpha input. But if
the same SYSEVAL is called when the computer is NOT in Program Entry Mode,
the program will terminate normally even WITHOUT alpha input.
I realize that nothing can be guaranteed to function correctly
when you start messing with SYSEVALS, so I mention this only as a
for-instance. However, I DO maintain that INPUT should leave the 48 in the
same state in which it found it! billw@hpcvra.CV.HP.COM (William C Wickes) (09/19/90)
a) This has nothing to do with INPUT, and b) no, it's not a bug. The display is never updated when a program starts running, whether it's a built-in program or a user program. The program itself may choose to update the display, but the ENTER code doesn't presume to do that. Not only will you see frozen cursors and PRG annunciators, but frozen clocks and anything else that was in the display when you let 'er rip. Program entry mode is automatically cleared by ENTER (if the command line parsing succeeds).
rrd@hpfinote.HP.COM (Ray Depew x2419) (09/19/90)
> An unfriendly behavior of the 48 which I have run afoul of several >times, but have never seen listed as a bug, involves INPUT (by the by, I >have a Revision D ROM). Try the following: > \<< "" "" INPUT > DO > UNTIL 0 > END > \>> >INPUT puts the 48 into Program Entry Mode, but PROGRAM ENTRY MODE IS NOT >EXITED once INPUT has done its job! The command line, with an ugly frozen >cursor, is still displayed while the DO loop runs. Dr. Wickes, is this a >bug? It seems to me that INPUT should leave the machine in the same state >it found it in -- i.e., Program Entry Mode should be cleared. Don't worry; your SYSEVALS had nothing to do with it. It's not a bug, either. The computer -- oops, sorry, the machine -- is doing just what you told it to do. Your << ... "" "" INPUT ... >> line obviously prompted for a command-line input, which of course you keyed in and then pressed [ENTER]. Then you entered an endless loop: << ... DO UNTIL 0 END ... >> which the 48 obediently executed. It ran through the loop, checking every time to see if the zero had become a one yet. Now, the problem is that you *expected* the 48 to update the display immediately after executing the INPUT and before executing the DO-UNTIL. It doesn't. I don't know why; I haven't figured that part out yet. However, I think that to enhance computation speed, the 48's designers choose to "freeze" the display during program execution, except for commands which obviously affect the display (e.g. PVIEW or DISP). You can see this if you run a l-o-n-g program which modifies the stack at the beginning. For example, try the program << SWAP 1 1000 FOR j 1 STEP >> You would *expect* to see the Level 1 & 2 arguments swapped immediately, but they don't*appear* to be swapped until the program ends. (You can change the number 1000 to anything else, to enhance the effect. 1E99 is too big, though. :-) And yet, you and I KNOW that the swap occurred at the start of the program. This is not, repeat NOT, a bug. It belongs there. It makes for some remarkably professional-looking, seamless routines. Consider it a descendant of the programmable VIEW command of HP-41 days (ah, the wonders of yesteryear!). And remember Funky Winkerbean's Third Axiom of Computer Programming: A computer doesn't do what you WANT it to do, only what you TELL it to do. ---------- Regards Ray Depew HP Colorado IC Division rrd@hpfitst1.hp.com just another satisfied etc.