alonzo@microsoft.UUCP (Alonzo GARIEPY) (09/26/90)
James Donnelly has done it again, but even better. The HP48 Programmer's TookKit is a set of primitive functions and utilities written in native RPL and machine code by one of Hewlett Packard's HP 48SX engineers. My copy arrived with an MS-DOS 5-1/4" floppy diskette containing HP 48 libraries and sample data, and a 124 page manual. You will need a serial cable and IBM-PC or compatible to load the libraries onto your HP 48. The manual is clearly written, but the typesetting looks little better than Donnelly's last effort, The HP 48 Handbook. One of these days I'll convince him to use a better font (lower x-height and serifs, please). It might have been better to call this package the HP 48 String/List Toolkit. It contains all the commands and utilities you need for creating, sorting, editing, searching, and viewing lists. There are many useful primitives for dealing with strings, dates, sets, graphics objects, and something called meta objects. Meta objects are what result when you execute LIST-> on a list. They can be manipulated more efficiently than lists because you work with pointers to list elements instead of the elements themselves. That is the basis of the quicksort speed-up I posted some months back. Meta-objects avoid continual garbage collection when you are manipulating large lists of information. I would have liked to see a more complete set of stack primitives for meta-objects. Among those omitted were MROT, MOVER, MDROP, and MDUP. MDROP is equivalent to DROPN, and MDUP is equivalent to << DUP 1 + DUPN >>, and I suppose you can use SRLL and MDUP to create your own MROT and MOVER. If you want to use the 48 as a personal organizer, this toolkit contains the necessary primitives to handle large amounts of data without tedious programming and time consuming loops of user code. And the built in browsers will satisfy most of your needs without writing much additional code. Below, I have reproduced the back cover and pages 37 to 39 of the manual. A more complete table of contents appears within the manual. There is no index. The HP 48 Programmer's ToolKit Getting Started 1 Character Set Catalog 5 Menu Label Builder 7 Flag Catalog 10 Data Browswer 13 Title Browser 22 Tool Library 26 Command Reference 40 Object Types 116 Character Codes 117 Character Translations 119 Flag 120 Alpha Keyboard 124 Array Operations ---------------- DELCOL Deletes a column from an array DELROW Deletes a row from an array EXCOL Exchanges two columns in an array GETCOL Extracts a column from an array GETROW Extracts a row from an array INSCOL Inserts a column into an array INSROW Inserts a row into an array PUTCOL Replaces a column in an array PUTROW Replaces a row in an array Graphics -------- PX+ Adds two grqaphics pixel coordinates PX- Subtracts two graphics pixel coordinates PXOFF Clears a pixel in an arbitrary graphics object PXON Sets a pixel in an arbitrary graphics object PX? Tests a pixel in an arbitray graphics object PX->R Converts pixel coordinates into two real numbers ROTATE Rotates a graphics object R->PX Converts two real numbers into pixel coordinates List Manipulation ----------------- CAR Returns the first object of a list CDR Returns a list minus its first object CUT Splits a list into the first and remaining objects EXTRACT Returns the mth element from each of a series of lists LSORT Sorts a series of lists based on the mth element NXTOB Returns the next choice from a list of choices PRVOB Returns the previous choice from a list of choices SPLIT Splits a list into two lists REPLACE Replaces all occurences of an object in a list REVERSE Reverses the order of objects in a list ROTATE Rotates the objects in a list ->SET Removes duplicate objects from a list Meta-Object Utilities --------------------- MAH Adds an object to the head of a meta-obj in position 1 MAH2 Adds an object to the head of a meta-obj in position 2 MAM2 Concatenates two meta-objs MAT Adds an object to the tail of a meta-obj in position 1 MAT2 Adds an object to the tail of a meta-obj in position 2 MDH Extracts an element from the head of a meta-obj in pos. 1 MDH2 Extracts an element from the head of a meta-obj in pos. 2 MDT Extracts an element from the tail of a meta-obj in pos. 1 MDT2 Extracts an element from the tail of a meta-obj in pos. 2 ML->M Converts lists in positions 1 and 2 into meta-objs MM->L Converts meta-objs in positions 1 and 2 into lists MREVERSE Reverses the order of the objects in a meta-obj MSWAP Swaps the meta-objs in positions 1 and 2 MZ2 Places an empty meta-obj in meta-stack position 2 Set Utilities ------------- ADJOIN Adds an object to a list if is unique DIFF Returns the set difference of two lists INTERSECT Returns the intersection between two lists SDIFF Returns the set symmetric difference of two lists ->SET Removes the duplicate objects from a list UNION Returns the set union of two lists Stack Manipulation ------------------ KEEP Keeps the bottom n objects on the stack MREVERSE Reverses the order of the first n stack objects NDUP Creates n copies of an object QSORT Sorts n objects on the stack SRLL Rotates n objects on the stack upward m times SRLLD Rotates n objects on the stack downward m times SXCH Exchange objects at levels m and n String Manipulation ------------------- CAR Returns the first character of a string CDR Returns a string minus its first character CUT Splits a string into the first and remaining characters ICAPS Converts the words in a string to initial caps LCASE Converts the characters in a string to lowercase LTRIM Removes leading spaces and tabs from a string PUTCHR Places character code n in a string REPLACE Replaces all occurences of a substring in a string REVERSE Reverses the order of characters in a string ROTATE Rotates the characters in a string RPTSTR Creates a string of n substrings RTRIM Removes trailing spaces and tabs from a string SPLIT Divides a string into two strings ->STDSTR Converts an object to a string in standard display mode STRCON Rapid creation of new character strings STRCTR Centers a string in a specified number of spaces SUBNUM Returns the character code of a string's nth character ->TIO Converts a string to its translated form for I/O TIO-> Converts a string from its translated form for I/O TRIM Removes leading and trailing spaces and tabs from a string UCASE Converts the characters in a string to uppercase ->WORDS Separates a string into individual words Other Commands -------------- DOW Return the day of the week given a date DOY Returns the day of the year given a date EQNVARS Returns a liset of global variables in an equation program VFIND Find all occurences of a variable or object type in user memory XTIME Calculates execution times The HP 48 Programmer's ToolKit, By James Donnely Armstrong Publishing Company 3135 NW Ashwood Drive Corvallis, OR 97330 USA I imagine you could also get the TookKit through Educalc. I have no information on price or availability. Alonzo Gariepy // I have no financial interest in this alonzo@microsoft // product, but I think it is way cool.
madler@piglet.caltech.edu (Mark Adler) (09/27/90)
I saw the advertisement for James Donnely's toolkit in the EduCalc catalog, and it somehow seemed to me unethical. I have not really decided on this yet, since the issue is fuzzy, but allow me to air my thoughts ... I was quite pleased to see his little HP-48 handbook, that others complained about because he is privy to internal HP information. I felt though that he was doing a service by getting information out of HP, to us. Like stuff about the machine level debugger, wslog, etc. The toolkit is a little different though. Here he is using information, but not making it available. He has access to very special tools at HP for constructing machine language programs, not to mention access to commented source for the ROM. If machine source for his tools, and perhaps a description of the instruction set came with the tools, then I would consider it a great service and would have no qualms whatsoever about him making a few bucks off of his special position. But as it is, the tools are magic boxes that are useful, but nonetheless mysterious. On the other hand (I sound like Tevye), the tools are themselves quite useful, and make the calculator all the more powerful. And if HP itself will not provide them, then I suppose it is good that an employee is allowed to on his own time. This is to the benefit of the non-hacker users of the HP who have interest whatsoever in writing similar tools. So am I off base in my initial gut reaction to seeing a member of the HP-48 team selling machine language tools, competing with other after-market software developers for the HP-48? Mark Adler madler@piglet.caltech.edu
jpser@cup.portal.com (John Paul Serafin) (09/27/90)
>I saw the advertisement for James Donnely's toolkit in the EduCalc catalog, >and it somehow seemed to me unethical. I have not really decided on this >yet, since the issue is fuzzy, but allow me to air my thoughts ... > >I was quite pleased to see his little HP-48 handbook, that others complained >about because he is privy to internal HP information. I felt though that he >was doing a service by getting information out of HP, to us. Like stuff >about the machine level debugger, wslog, etc. > >The toolkit is a little different though. Here he is using information, but >not making it available. He has access to very special tools at HP for >constructing machine language programs, not to mention access to commented >source for the ROM. If machine source for his tools, and perhaps a >description of the instruction set came with the tools, then I would consider >it a great service and would have no qualms whatsoever about him making a few >bucks off of his special position. But as it is, the tools are magic boxes >that are useful, but nonetheless mysterious. > >On the other hand (I sound like Tevye), the tools are themselves quite >useful, and make the calculator all the more powerful. And if HP itself >will not provide them, then I suppose it is good that an employee is >allowed to on his own time. This is to the benefit of the non-hacker >users of the HP who have interest whatsoever in writing similar tools. > >So am I off base in my initial gut reaction to seeing a member of the HP-48 >team selling machine language tools, competing with other after-market >software developers for the HP-48? > >Mark Adler >madler@piglet.caltech.edu . Hard to say. It certainly would be nice if there were more support for 48 developers and it would certainly be a shame for powerful tools to not be available. It is begining to look like having only two ports is going to be extremely frustrating. Presumably, the next generation will have a larger address space or fast easy bank switching and also more ports or a next generation of cards which are really drawers with multi user installable chip capacity. . He *should* be soundly thrashed for perpetuating stupid names like "car" and "cdr" then adding to the confusion by applying them to strings instead of lists. Was that some kind of cruel joke? . John Serafin jpser@cup.portal.com
bio_zwbb@jhunix.HCF.JHU.EDU (William Busa) (09/27/90)
In article <1990Sep26.181705.20455@nntp-server.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: > >I saw the advertisement for James Donnely's toolkit in the EduCalc catalog, >and it somehow seemed to me unethical. > >Here he is using information, but >not making it available. He has access to very special tools at HP for >constructing machine language programs, not to mention access to commented >source for the ROM. If machine source for his tools, and perhaps a >description of the instruction set came with the tools, then I would consider >it a great service and would have no qualms whatsoever about him making a few >bucks off of his special position. But as it is, the tools are magic boxes >that are useful, but nonetheless mysterious. > >So am I off base in my initial gut reaction to seeing a member of the HP-48 >team selling machine language tools, competing with other after-market >software developers for the HP-48? > The question, to my mind, is larger (and different!) than that of Donnely's ethics. IMHO, a problem has developed which neither we user/programmers nor HP could have anticipated, and this problem has yet to be addressed directly. As I've suggested in previous postings, the 48 is the first true handheld computer (actually, I might modify that to "the first true handheld computer which any significant number of people are interested in writing software for..." :-) ). As a *computer* (rather than a calculator) its in a nearly unique market position in that it is a completely *closed* system -- we have (officially, at least) no idea how it works! This is *not* due to malevolance on HP's part -- its simply a logical historical progression. HP (Corvallis) is in the business of producing cutting-edge programmable calculators. Because they are pulling the technology along (rather than chasing after it like everybody else) their development costs must be astronomical. Consequently they sell their machines at a premium price (to recoup those development costs and make a decent profit). Further, they are (quite reasonably, IMHO) loathe to give away their hard-earned secrets to competitors who, with the ROM code in hand, could crank out clones quite cheaply. Just look at what happened to the IBM PC. So, it makes perfectly good business sense for HP to withhold their code and development tools. On the other hand, we as programmers of *computers* are quite unused to programming a "black box" -- its hard, its no fun, and we can't do as good a job as someone (like Donnely) who has access to this priviledged information. Thus, its quite understandable that we sometimes howl with outrage about the closed nature of the system we are attempting to program. From *our* point of view, it is a little silly that we have to depend on good folk like Gariepy and Grevelle to "reverse engineer" the system for us, when all the info we need resides in a set of manuals and some computer files in Corvallis. Poor Dr. Wickes simply gets himself in more hot water every time he generously hands out a few SYSEVALs, as these simply whet our appetites for MORE. Consequently, the developement of this fundamentally new kind of machine has inadvertently set HP and its loyalists at odds -- to *everyone's* detriment. We lose because we can't write the kind of software that this machine cries out for. HP loses both because its loyalists' feelings get hurt, *and* because it can't benefit (as the IBM PC has) from an enormous pool of outside-vendor software that would make everyone and his brother want to run out and buy their machine. What's the solution? I really don't know. It would be *great* if HP would sell a software developer's package, consisting of the commented ROM code and whatever development tools they have on hand. But doing so would make it easy for the clone-makers to undercut HP's market position, I would guess, so this seems bloody unlikely. Perhaps there are legal and/or technical means by which HP could release the information *and* protect their position, but I'm neither a lawyer nor an EE, so I can't say. I just hope that people at HP are at least asking themselves these questions. As to the narrower issue of the propriety of Donnely's use of inside information to write the kind of code *we'd* love to write, I see this as a non-issue. At present, that information is HP's to do with as it wishes. By virtue of the fact that Donnely is still employed at HP and isnt getting his pants sued off, I assume that he has HP's blessing to use the information -- but he almost certainly doesn't have HP's blessing to *release* that information, so we can hardly blame him for withholding it. At present, I'm just happy to have Donnely's nifty tools available to me. In the longer term, I hope HP can find a way to make this information available to outside programmers without crippling its unique ability to produce such marvelous machines. *Everyone* will benefit if it can -- and *everyone* will be hurt if it can't. Its an old story: new technologies create damn sticky new ethical problems. Anyone out there with some expertise in business law have any suggestions regarding a way out of this mess?
davisp@skybridge.SCL.CWRU.Edu (Palmer Davis) (09/28/90)
I'll do everyone a favor by not quoting the rather large volume of material
in the thread up to now. To briefly summarize, the Programmer's ToolKit got
flamed for using magic system hacks but not revealing how they worked. A
reply then defended HP's reticence about documenting 48sx internals by
comparing the 48sx to the early IBM PC and postulating that HP would have
clone trouble if the 48sx were more open. (If I've misunderstood anybody's
points, please correct me now....)
Has anybody here ever worked on a Macintosh? Nobody would accuse Apple of
being "open" with Macintosh internals, yet there's an enormous volume of
documentation (Inside Macintosh, et al.) available that gives programmers
enough information to intelligently design non-trivial software. There are
no Macintosh clones on the market today, even though a group of disgruntled
Apple employees gave away commented ROM sources. (Yes, I know about machines
like the Colby; they don't really count as clones since Apple gets royalties
from them.) The 48sx has not only proprietary ROMs but a proprietary
processor as well; nobody's going to be able to even attempt to clone it
without getting mobbed by a swarm of angry lawyers. That's not likely to
change because HP decides to publish the instruction timings or a memory map.
For an even better example, look at the Franklin Ace... and remember that the
Apple II came with a circuit diagram!
-- PTD --
--
Palmer T. Davis | davisp@scl.cwru.edu -OR- ptd2@po.cwru.edu
Case Western Reserve University | {att,sun,decvax,uunet}!cwjcc!skybridge!davisp
------------------------------------------------------+------------------------
Wake up and smell the cat food in your bank account. | Life is short.lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (09/29/90)
bio_zwbb@jhunix.HCF.JHU.EDU (William Busa) writes: > [...] HP (Corvallis) is in the business of producing cutting-edge >programmable calculators. Because they are pulling the technology along >(rather than chasing after it like everybody else) their development costs >must be astronomical. Consequently they sell their machines at a premium >price (to recoup those development costs and make a decent profit). >Further, they are (quite reasonably, IMHO) loathe to give away their >hard-earned secrets to competitors who, with the ROM code in hand, could >crank out clones quite cheaply. Just look at what happened to the IBM PC. >So, it makes perfectly good business sense for HP to withhold their code >and development tools. I am not sure that it makes that much sense. There is a strong parallel here between HP's position and Apple Computer's position. Note that Apple is getting into big trouble because it will not allow others to use its ROM's. Also Apple is selling its computers at high prices because it has a corner on the market. The problem with this is that third-party developers cannot make money this way. Only *nine* (yes, that's *9*) Apple software developers last year made a profit. If this keeps up, the third-party software market for Apple is going to dry up. One difference between Apple and HP is that Apple has documented how to use the procedures available in their software kernel, whereas HP has not. Sure, HP48sx developers can use the well-documented procedures available in RPL, but what is really needed is some HP-blessed machine-language entry points into the kernel software. This would make it easier to develop fast applications (in assembly code) for the HP48sx, and HP would not have to produce a commented ROM disassembly (like some people would like). > [...] > Consequently, the developement of this fundamentally new kind of >machine has inadvertently set HP and its loyalists at odds -- to >*everyone's* detriment. We lose because we can't write the kind of >software that this machine cries out for. HP loses both because its >loyalists' feelings get hurt, *and* because it can't benefit (as the IBM >PC has) from an enormous pool of outside-vendor software that would make >everyone and his brother want to run out and buy their machine. Sometimes risks need to be taken. IBM is certainly making much more money off its PC than if it had kept it under wraps (like Apple is doing). Yes, there *is* a big PC clone market out there, but that is exactly the reason that the PC is a defacto standard in the computer industry. If a company wants to create a computer/handheld that is extremely popular, they will need to open up its guts to the rest of the world. Companies that do not take this risk end up having nice computers that go nowhere. For that matter, the same goes for operating systems (there are few, if any, popular proprietary OS's anymore). Many, many companies have learned this lesson the hard way. To name a few: Apple, Wang, Xerox, Commodore (in some sense), Sinclair. >What's the >solution? I really don't know. It would be *great* if HP would sell a >software developer's package, consisting of the commented ROM code and >whatever development tools they have on hand. But doing so would make it >easy for the clone-makers to undercut HP's market position, I would guess, >so this seems bloody unlikely. I think this is unrealistic. HP does not have to publically release its disassembled and commented ROM code to make the HP48sx more open. HP *should* provide descriptions, calling conventions, and restrictions for its internal kernel routines. Another important point: it is likely that much of HP's development software resides on non-IBM hardware (probably HP workstations). It would be costly to translate this all to the IBM PC, and it seems that HP Corvallis has enough work to do without taking on this extra role. It would most likely be better to let the third-party software companies write development programs. In my opinion, HP should concentrate on the hardware and "operating system" software. Let others write the applications. This is course would require publishing some information on HP48sx internal machine-language procedures (i.e. entry points and functionality). >[...] >In the longer term, I hope HP can find a way to make this information >available to outside programmers without crippling its unique ability to >produce such marvelous machines. *Everyone* will benefit if it can -- and >*everyone* will be hurt if it can't. Its an old story: new technologies >create damn sticky new ethical problems. >[...] Note that HP *has* allowed outside parties to work on some of their programs. For example, they released the source of USRLIB to me so that I could create an Amiga executable of it, which was a good action on their part. I am not sure if they have released HP48sx ROM code to anyone outside of the development team. Personally, I think HP should produce a list of internal ROM routines (i.e. sysevals) and their usage. HP should not make available to the public a commented disassembly. I feel that the only way HP is going to survive in the handheld computer market is to keep pushing the research limits of this technology. By staying one step ahead of the competitors, they should be able to create a profitable product while pushing the state-of-art in handhelds. Note that this is certainly not easy; big companies with great ideas have in the past failed to make a profit with great ideas and research. One need look no further than Xerox (with its object-oriented language and desktop systems) to see this. However, it is a testament to HP's prowess and success that no other handheld computer comes close to the capabilities of the HP48sx at the same price. Disclaimer: much of the information on HP above is conjecture on my part. Some of it may be wrong, although to the best of my knowledge it is accurate. I have no affiliation with HP other than as a happy owner of an HP48sx and as one who has ported one of their programs to the Amiga. .oO Chris Oo. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
tt@euler.jyu.fi (Tapani Tarvainen) (09/30/90)
> bio_zwbb@jhunix.HCF.JHU.EDU (William Busa) writes: > >It would be *great* if HP would sell a > >software developer's package, consisting of the commented ROM code and > >whatever development tools they have on hand. YES! > >But doing so would make it > >easy for the clone-makers to undercut HP's market position, I would guess, I don't think that's the main reason. More likely they consider the required support &c not worth the effort: they tried it with HP71B and it didn't work (or that's what I'd guess the penny-counters at HP are saying, of course WE know that the real reason for 71's (commercial) failure lies elsewhere). lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: > Another important point: it is likely that much of HP's development > software resides on non-IBM hardware (probably HP workstations). It > would be costly to translate this all to the IBM PC, and it seems that > HP Corvallis has enough work to do without taking on this extra role. Quite. They cannot simply take whatever tools they're using and start selling them, they very least they'd have to re-package them and provide some sort of technical support. One possibility to avoid this would be to release the stuff like the 41 internals were, on NOMAS basis (NOt MAnufacturer Supported), if suitable means of distribution could be found (alas, there is no world-wide users' club anymore such as PPC then was; perhaps we should establish a joint organization of various local/national clubs to handle this kind of things?). I at least would be happy to get the development tools even if they only run on HP workstations :-). (Hey, HP, haven't you considered how that could boost your workstation sales?!) > Personally, I think HP should produce a list of internal ROM routines > (i.e. sysevals) and their usage. Even that would be nice, although I doubt if it would be substantially harder for them to give the ROM listings as well (sold as a separate item, perhaps, for there is _a lot_ of it), unless they really are worried about clones (which I doubt, considering the proprietary processor &c). If we really want to get something done about this we'd have to convince HP that it would be in their interest, moneywise, i.e., that it'd bring in more money in increased sales than it'd cost in support &c---i.e., that there are enough of us who'd want it. How about everybody writing a letter to HP about it? (MUCH more efficient than posting here.) -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
rustw@yvax.byu.edu (10/03/90)
I would like to comment on the fact of HP not releasing information about the internal workings of the HP-48. I recently helped to release a product for a company. On purpose we did not document many interesting and helpful features of the calculator. Some of these may or may not be similar to HPs reasoning. 1. Time - Just not enough time for extensive documentation. 2. Technical Support - Support for low level features requires an inordinate amount of support. Each feature must be 'completely' tested and bug free and the tech support staff must be intamately involved with each one. Since most of these features are low level, they require extra knowledge on the programmers part (something that most programmers want HP to give them also). 3. Upward Compatability - If a programmer programms using the SYSEVAL commands then there is no guarantee that these would be compatible with future versions. I have noticed this in my programming on PCs. If I want to exploit a feature of a processor I must programm it in assembly rather than C. Porting this to another system becomes very awkward. I have written many programs in both RPL and MCODE on the 28s and 48s. All 28s programs have ported across with ease with the exception of the MCODE programs. If HP were to change the ROM in some major way the user should not notice any significant difference. 4. Programming in a high level language with few tricks (no SYSEVALS for example) allows easy modification and readability for others. 5. With access to a group like this (in the case of my company a good BBS and tech support staff) any good programmer has access to all the information that is needed. Communication between peers is much better for learning something anyway. Good Luck, Wayne Rust
alonzo@microsoft.UUCP (Alonzo GARIEPY) (10/03/90)
madler@piglet.caltech.edu (Mark Adler) writes: > So am I off base in my initial gut reaction to seeing a member of the HP-48 > team selling machine language tools, competing with other after-market > software developers for the HP-48? I don't really understand the whole concept of unfair competition in a free market economy. Perhaps you would do better to think of this product as coming from HP, who happen to give its author a royalty. The effort required to educate the world at large to Mr. Donnelly's level of expertise would be enormous. Using that as an excuse to deprive us of his extracurricular contributions to the 48 is counterproductive. It isn't that unusual for a manufacturer to have special relationships with certain OEMs or developers. It may not be in the best interests of the manufacturer, but I wasn't aware of any moral imperative. It seems rather silly for any after-market software developer to compete in selling machine language tools when there is no official support. Mind you, the eventual fate of closed architecture machines is usually bad.
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (10/07/90)
tech.edu> <6527@jhunix.HCF.JHU.EDU> <1990Sep29.142702.20060@uwslh.slh.wis .edu> <TT.90Sep30083526@euler.jyu.fi> Sender: Reply-To: ebergman@isis.UUCP (Eric Bergman-Terrell) Followup-To: Distribution: Organization: Math/CS, University of Denver Keywords: