Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!jarthur!nntp-server.caltech.edu!piglet!madler
From: madler@piglet.caltech.edu (Mark Adler)
Newsgroups: comp.sys.handhelds
Subject: Re: HP Upgrade (was Re: HP Promo)
Message-ID: <1990Aug19.172055.29160@laguna.ccsf.caltech.edu>
Date: 19 Aug 90 17:20:55 GMT
References: <9008131714.AA20780@hercules.csl.sri.com> <24674@boulder.Colorado.EDU> <32759@cup.portal.com> <10869@accuvax.nwu.edu> <1990Aug18.141645.5958@uwslh.slh.wisc.edu>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology, Pasadena
Lines: 21


Christopher Lishka writes:

>> HP should at least make the ROM chip easy to replace, and then figure on
>> sending a "bug-free" ROM to all owners of early machines.

This may not be the best way, considering the size of a calculator and HP's
very tight packaging.  I think a better and more versatile way is to have some
ROM vectors in RAM that can be patched and replaced with code in RAM to allow
field upgrades of the ROM code.  I'm sure there is already a dispatch table (or
tables) in the ROM somewhere that could simply be copied to RAM on a total
reset.  On the next HP calculator, I'd expect the impact on RAM space to be
small and well worth the investment.  HP dealers could simply get the mods on a
ROM card and download them into customers' calculators from a store calculator.
They could also be distrubuted by HP on floppy disks for IBM's, Macs, and
whatever they choose to support.  This mechanism could be used to provide
speedups to certain potions of the code by converting from RPL to machine code.
And the possibilities for hackers are endless ...

Mark Adler
madler@piglet.caltech.edu