Installing latest 49g+/50g (emulator) ROM on a 49G
in [HP48]
|
From: James M. Prange on 20 Dec 2006 09:38 John H Meyers wrote: > On Mon, 18 Dec 2006 13:50:38 -0600, James M. Prange wrote: > >> What I find remarkable is that a ROM developed for ARM-based models >> works just fine with an older hardware Saturn model. > > But the whole idea is that there is *no* ARM code > in the HP part of the ROM But there *is* new Saturn+ code in the HP part of the ROM for the actual 49g+/50g, but not in the ROM for Emu48. > -- the new products > are merely vehicles for running an [almost] exact emulator, > just like running an Emu48 clone in your PDA or cell phone; > this is why 49G programs and libraries remain compatible, > and the "system" ROM is, after all, just another set of libraries :) The ARM-based emulator used in the calculators isn't just an Emu48 clone emulating the hardware Saturn processor; it doesn't emulate just the hardware Saturn processor, but an enhanced "Saturn+" processor with additional assembly language instructions and of course corresponding machine language opcodes; for examples, see: http://www.hpcalc.org/search.php?query=%22New+Saturn+Opcodes%22 Note that MASD as built in to the ARM-based calculators can compile the new Saturn+ assembly language mnemonics to machine language or vice versa. Any code designed to run on the 49G or Emu48 should (except for peripheral hardware dependencies) run just fine on an ARM-based model, because the Saturn+ includes everything that the hardware Saturn has, but the ROM for the actual 49g+/50g calculators includes some new Saturn+ code that can't run on the 49G or Emu48. > "Almost" is what imperfectly implements the clock & alarms, > as well as the original keyboard handling, > and also doesn't quite duplicate the display (for grayscale); > Emu48 also doesn't do everything exactly the same, either, > when it comes to hardware, yet it works with any 49G original ROM, > so why wouldn't an ARM-based version of Emu48 > be able to do the same? Indeed, an ARM-based version of Emu48 with a Saturn+ instead of an emulated hardware Saturn should be able to run any 49G code as well as 49g+/50g code, and even HPGCC code. But we don't have an ARM-based version of Emu48. Perhaps someday we will; I suppose that it's possible to emulate the ARM system on a PC, and have that run the Saturn+ emulation; it would have some advantages. But I suppose that one could say that the emulator built-in to the ARM-based models may be considered an ARM-based and enhanced version of Emu48, if that's what you mean. >> the ROM would be suitable for running on the emulator for >> any 49 series, and therefore for transfer to a real 49G. So what's >> left? Add whatever is needed to make it load and run on a real >> ARM-based model, and where it's known that hardware Saturn code >> can be replaced by faster Saturn+ code, make those replacements. > > Kinpo supplies hardware and emulator [no matter who wrote it]; The emulator used on the calculators, that is; I have my doubts that Kinpo has anything to do with Emu48. > HP supplies what runs either on an emulator or on the real thing > that was emulated; these usually come packaged together into one file > for updating the entire new ROM, but occasionally the HP part > is found by itself, especially for use with other emulators. True, but when the HP part is found by itself, it doesn't (at least as far as I've found) have any of the new Saturn+ code, as the package for updating the actual 49g+/50g ROM does. > It all reminds me of an IBM "mainframe" era system called VM/CMS, > which gave each user a "personal [virtual] mainframe," > which was almost indistinguishable from the real thing, > except for one single mysterious CPU instruction called > "diagnose," which had always been declared "model-dependent"; > this one instruction provided a "hook" for some "out of band" > communication between the user's virtual machine and the underlying > real mainframe which time-sliced itself between all users, > in a manner strikingly parallel to how a few originally > "undefined" Saturn codes can now "talk to" > the underlying Kinpo system -- actually, this was already > being done in Emu48, where the "beep" patches invoked > a similar instruction to "fake" the beeping under Windows, > so this idea was around long before the present calcs came to exist. Another analogy is that the DOS version of my text editor allows me to "shell out to DOS" and run the command processor (swapping most of the editor to disk and leaving just a small portion in RAM), allowing me to run DOS commands, batch files, or other programs, and then "exit from DOS", returning to my text editor. If I want, I can write a "macro" (actually, a program written in the editor's language) to "shell out", then execute some "native DOS" commands or invoke another program to do something, and then return to the editor. The above strikes me as similar to what's done with HPGCC. Of course, with the MS Windows version of my text editor, its Shell command instead opens a "DOS window" running the command processor, and leaves the editor running in it own window. > Eventually, the IBM operating systems which usually > ran on dedicated hardware were augmented to allow them > to rely on the "virtual" system (when present) > to do some functions for them, such as memory management, > which the "core" virtual system was able to do better and faster > than the original OS -- quite similarly, a very few things that occupy > some significant fraction of the Saturn's time while interpreting RPL > can now be done much faster by a "little elf" in native ARM code, > provided that one simply recognizes such a sequence in the > original ROM, and replaces it with some elfish new instruction, I suppose that one could say that the new Saturn+ instructions serve the purpose of having the underlying ARM operating system do things that would be relatively difficult or slow in a hardware Saturn, although in a sense, everything done in the emulated Saturn+ is ultimately accomplished in the ARM system. > which I suppose could be done after the complete compilation > of the original ROM, just as JMP suggests. Actually, it seems more reasonable to me that the "hardware Saturn" version of the ROM would be compiled and tested in an emulator first, and then the Saturn+ replacements made to the source code (along with adding the rest of the code needed for loading and running on an actual 49g+/50g), and then the modified source code compiled and tried out on an actual calculator, with minimal testing required. > IBM's VM/CMS: > http://www.economicexpert.com/a/VM:CMS.html > > Is the "IBM mainframe" still around, some 40 years later? > http://www.economicexpert.com/a/Z:OS.htm > http://www-03.ibm.com/servers/eserver/zseries/zos/ > >> "Capes"? > > "FR: HP49, capes" [Dec 13 2006] > http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/5dfba355f8d36aac > http://danny.oz.au/jennifer/visitor/4.teaching.html [in English] > http://www.cidu.de/fr/studieren/abschluesse/capes_agreg_inhalt.html > > If the "2.10" which someone anticipated a while back is delayed at HP, > perhaps you can locate something else to play with meanwhile, > if only you are a French math teacher. Or with the rom.e49 file from http://www-fourier.ujf-grenoble.fr/~parisse/ VERSION returns "Version HP48-G Revision #2.10-7" "Copyright HP 2006", and VER returns 4.20060919. Apparently it contains some fixes intended for the next official HP ROM, although I have my doubts that the next ROM would include such "CAS enhancements" as the Spreadsheet and Geometry enhancements. -- Regards, James
From: James M. Prange on 20 Dec 2006 11:10 Veli-Pekka Nousiainen wrote: > "James M. Prange" <jmprange(a)i-is.com> wrote in message > news:c244e$4586dd05$4267ebc2$30790(a)123.NET... >> Veli-Pekka Nousiainen wrote: >> >>> "Heiko Arnemann" <Heiko.Arnemann(a)gmx.de> wrote in message >>> news:458443dc$0$1120$ba620e4c(a)news.skynet.be... > X >> It occurs to me that it may be better to implement some "extras" >> as external libraries instead of including them in a ROM file. > X > I agree, but not all users ever learn about the libraries > and if the spreadsheet is already there > one can use it in advertizing, too! Okay, I expect that there are many users who aren't aware of the various on-line resources such as this usenet group or hpcalc.org, and aren't aware that additional external libraries can be installed. But such "extra" libraries can be "pre-loaded" as external libraries in port 2 with new calculators (isn't this done with libraries 226 and 227 in the 50g?), and can be packaged as external libraries in the ROM upgrade .ZIP file, as is currently done with ROM 2.09. Even Professor Parisse's files include the equation library and periodic table library as external libraries installed in port 2; perhaps he could've done the same his "Spreadsheet" and "Geometry" applications? Of course it should be clearly documented what the external libraries are there for, and what the implications of purging them would be. Then it would be up to the individual user whether to keep them, or to move them to an SD card or PC for possible future use, or to simply purge them. To be sure, if the built-in ROM requires a routine, then that routine should be built-in as well. But if an application isn't required by built-in ROM, then, in my opinion, it would be better to implement it as an external library. -- Regards, James
From: Veli-Pekka Nousiainen on 20 Dec 2006 14:54 "James M. Prange" <jmprange(a)i-is.com> wrote in message news:ad62a$45896078$4267ebd5$2287(a)123.NET... X > But such "extra" libraries can be "pre-loaded" as external > libraries in port 2 with new calculators (isn't this done with > libraries 226 and 227 in the 50g?), and can be packaged as > external libraries in the ROM upgrade .ZIP file, as is currently > done with ROM 2.09. Even Professor Parisse's files include the > equation library and periodic table library as external libraries > installed in port 2; perhaps he could've done the same his > "Spreadsheet" and "Geometry" applications? X What an excellend idea. You're Hired! <Donald Trumoh's voice with "snake" added>
From: parisse on 20 Dec 2006 15:00 > Even Professor Parisse's files include the > equation library and periodic table library as external libraries > installed in port 2; perhaps he could've done the same his > "Spreadsheet" and "Geometry" applications? No, for some good reasons: 1/ the spreadsheet use the MTRW interface, hence some MTRW must call the spreadsheet which therefore should be in ROM (or you must define a protocol for MTRW/spreadsheet communication which is much more complicated) 2/ the spreadsheet and geometry have fixed addresses in the second CAS bank, that makes calls inside the bank shorter in size and faster. Moreover the geometry is an analytic geometry application, it is therefore a (new) component of the CAS, like e.g. Laplace transform (not for the same users...). The geometry commands might be called from the stack, for example if you want to compute the coordinates of the intersection of a circle and a line, or 2 circles, etc. 3/ the main reason why I programmed these additions was for the 49 to be allowed at the competition for recruituing math teachers in France. Therefore the mandatory addition of a geometry application and of a spreadsheet had to be inside the ROM, not as an additional library that someone might erase by a wrong manipulation.
From: Veli-Pekka Nousiainen on 20 Dec 2006 15:17
<parisse(a)domain.invalid> wrote in message news:45899627$0$5110$ba4acef3(a)news.orange.fr... > > Even Professor Parisse's files include the >> equation library and periodic table library as external libraries >> installed in port 2; perhaps he could've done the same his >> "Spreadsheet" and "Geometry" applications? > > No, for some good reasons: > 1/ the spreadsheet use the MTRW interface, hence some MTRW > must call the spreadsheet which therefore should be in ROM > (or you must define a protocol for MTRW/spreadsheet > communication which is much more complicated) > 2/ the spreadsheet and geometry have fixed addresses in > the second CAS bank, that makes calls inside the bank > shorter in size and faster. Moreover the geometry is an analytic > geometry application, it is therefore a (new) component of > the CAS, like e.g. Laplace transform (not for the same users...). > The geometry commands might be called from the stack, for > example if you want to compute the coordinates of the intersection > of a circle and a line, or 2 circles, etc. > 3/ the main reason why I programmed these additions was for > the 49 to be allowed at the competition for recruituing > math teachers in France. Therefore the mandatory addition > of a geometry application and of a spreadsheet had to be > inside the ROM, not as an additional library that someone > might erase by a wrong manipulation. So they should be on *EVERY ROM* Perhaps we will have a HP 50GS (S for Spreadsheet) with a 4MB Flash ROM, 2MB for OS and 2MB for the user OS could then include in one bank a new extable 3 with also the Spreadsheet & Geometry package supported entry points included :-D |