Installing latest 49g+/50g (emulator) ROM on a 49G
James M. Prange
threads.
It's possible to use ROM revision 2.09, or perhaps I should say
the emulator ROM revision 2.09, on a 49G.
A question that might come up could be, why would anyone want to
use a ROM intended for the 49g+/50g on a calculator that it
apparently wasn't intended to be used on?
For me, the principal advantage is simply that several bugs have
been fixed from ROM revision 1.19-6 to revision 2.09. For
examples, see:
http://bugs.hpcalc.org/query.cgi
and the "readme" files included with some of the "unofficial"
revisions. My guess is that there have been various undocumented
bug fixes as well.
Another possible advantage is that some of the earlier ROM
revisions (I don't, offhand, recall exactly which revisions) have
the equation library built-in, with the library using
"unsupported" revision-dependent code. Starting with revision 2.08
(the 50g's initial revision), the equation library (and, more
recently, the periodic table) are optional external libraries
using only "supported" entry points and work with all ROM
revisions back to at least 1.18. If you want these libraries, you
can install them, but if you don't want them, you don't have to
install them, thus saving some room in your ports. These libraries
are available at:
http://www.hydrix.com/Download/Hp/4950Libraries/
file name: EquationLibrary.zip. To "install" them, simply unzip
the downloaded file and move a copy of EqnData.lib and EquLib.lib
(for the equation library), or PerTbl.lib (for the periodic table
library), to port 0, 1, or 2.
Note that the documentation for the equation library and periodic
table may be a bit sketchy in the current manuals. For better
documentation, you could use the "HP 82211A HP Solve Equation
Library Application Card Owner's Manual (for HP-48SX)" and "HP
82211B HP Solve Equation Library Application Card Manual Update
(for HP-48SX)", both available on the current Museum of HP
Calculators CD ROM set / DVD. See:
http://www.hpmuseum.org/cd/cddesc.htm
The only "glitch" that I've found with using revision 2.09 on a
49G is with the VERSION command. The 2.09 VERSION first uses
IsBigApple_ to check whether the hardware is a "BigApple" (49g+ or
50g), and if so, then uses IsAppleV2_ to check whether it's a 50g.
If it's not a "BigApple", then it "must" be running on a 48gII
(since revision 2.09 was never intended to be used on the 49G).
But the 49G isn't a "BigApple", so VERSION returns "Version HP48-C
Revision #2.09" where we might expect to see "Version HP49-C
Revision #2.09". I consider this to be a very minor and harmless
glitch.
Notably, the I/O input forms seem to "know" that IR isn't
available on the 49G, and the "Baud" choices are appropriate for
the 49G.
Another question might be how is it possible to use a ROM written
for the 49g+ or 50g on a 49G? Well, the "hardware Saturn"
processor of the 48 series and 49G has been replaced by a
"Saturn+" processor emulated in the underlying ARM operating
system of the ARM-based models. The Saturn+ processor can use all
of the opcodes of the hardware Saturn, and in addition has several
new opcodes that can be used to work around some of the
difficulties of working with the hardware Saturn. The ROMs for the
49g+/50g replace certain "legacy" hardware Saturn code with faster
Saturn+ code, but note that the PC-based emulator (Emu48) emulates
the hardware Saturn, not the ARM operating system or Saturn+, so
the 49G+/50g ROM for the emulator uses only pure hardware Saturn
instructions. By removing any patches (used for differences
between a PC's hardware and the calculator's hardware) from the
emulator's KML files, a 49g+ or 50g emulator ROM can be loaded as
the ROM for the 49G emulator, and from there, the ROMUPLOAD
command can transfer the ROM to a real 49G. I now have a 49G with
ROM revision 2.09, the latest revision for the 49g+/50g.
Of course a 49g+ or 50g ROM could be used with the 49G emulator on
a regular basis if one really wanted to, in which case any patches
should be left in.
No, I don't know which hardware Saturn code is replaced with
Saturn+ code, or how to go about replacing the code. I'm just glad
that someone does, and I prefer to leave such matters to those who
really know what they're doing.
The ROMG+.49G file for the emulator is time-stamped (last write)
2006-06-03 03:01:16, and the 4950_92.bin file for the 49g+/50g is
time-stamped 2006-06-03 05:24:00, so as far as I know, whether the
4950_92.bin file was developed first and "tweaked back" to using
pure hardware Saturn code for the ROMG+.49G file, or the ROMG+.49G
file was developed first and "tweaked ahead" to using some Saturn+
code for the 4950_92.bin file, is an open question. Of course the
developers would know, but I haven't seen this question addressed.
Of course we can't really expect anyone to support using revision
2.09 with a 49G, but it ought to work the same on a real 49G as it
does in the PC-based emulator, and hopefully, except for hardware
differences, the same as on a real 49g+ or 50g.
But given how easy it is to get the current 49g+/50g ROM to run on
the 49G, I'd think that it wouldn't be all that difficult for HP
to support an updated ROM for the 49G, if any corporate red tape
could be worked through. After all, I'd expect that there are
quite a few 49Gs out there that still work as good as when they
were new.
If anyone cares to upgrade their 49G to ROM revision 2.09, first
download, unzip, and install the latest version of Debug4x
(currently Version 2.2, Build 104) from:
http://www.debug4x.com/]http://www.debug4x.com/
(about a 7.5MB download).
Now pick a 49G .kml file to use; I used:
C:\Program Files\Hewlett-Packard\Debug4x\Emu\R49G1024.kml
but adjust the path and file name as appropriate. Make a copy of
the .kml file and rename the copy; for example, I renamed the copy
to R49G1024r209.kml. Open the renamed .kml file with a text
editor. Mine starts out with:
Global
Title "HP49G 1024*768 (256 colors) for Emu48"
Author "Hewlett Packard, Eric Rechlin and Christoph Giesselink"
Model "X"
Rom "ROM.49G"
Patch "BEEP.49G"
Bitmap "R49G1024.BMP"
Debug 0
End
with the leading spaces being actually a physical tab character
(ASCII 009) (leaving it out or changing it to any "whitespace"
should be okay).
Edit this to:
Global
# Title "HP49G 1024*768 (256 colors) for Emu48"
Title "HP49G special 2.09 ROM 1024*768 (256 colors) for Emu48"
Author "Hewlett Packard, Eric Rechlin and Christoph Giesselink"
Model "X"
# Rom "ROM.49G"
Rom "ROMG+.49G"
# Patch "BEEP.49G"
Bitmap "R49G1024.BMP"
Debug 0
End
That is, remark out (or remove) the old "Title", "Patch", and
"Rom" lines, and insert a new title and the 49g+/50g ROM file
name, and save the edited file.
Now open EMU-49; it should be in your Start menu as:
Start\programs\HP 49 & 48 Development Kit\EMU-49 If needed, in the
"View" menu, click on "Change KML script...", and choose your
modified .kml file. Enter the VERSION command and verify that it
really is "Version HP48-C Revision #2.09".
Now it's just a matter of transferring the ROM from the emulator
to the physical 49G, much like transferring a ROM from one 49G to
another, and not too different from using a ".flash" file to
upgrade the 49G ROM from a PC. Of course, it's best to start with
a fresh battery in the 49G.
To cancel out of any test mode, hold down ON, press and release C
(F3), and release ON to force a warmstart. In case a warmstart
can't be forced from the keyboard, insert a partially straightened
small paper-clip (or something similar) straight into the hardware
reset hole in the back of the 49G. I suppose that you could force
a warmstart while a ROM download is in progress, but in that case,
the calculator would be rather useless until you completed a ROM
download.
In case of any difficulties with upgrading the 49G ROM, see the
"If it fails:" instructions at:
http://etud.epita.fr/~avenar_j/hp/49.html
or:
http://www.hpcalc.org/hp49/pc/rom/
You can always go back to using an earlier ROM revision.
In the emulator's "File" menu, choose "Settings...", and then
under "Serial Ports", change the "Wire:" setting to whatever COM
port you normally use for connecting your 49G, and click OK.
Physically connect the 49G to the COM port, then enter ROMUPLOAD
on the emulator; you should have some instructions displayed on
the emulator. On the 49G, hold down ON, press and release D (F4),
and release ON; you should now have a "Tests" menu. On the 49G,
hold down ENTER and the + key, press and release ON, and release
ENTER and +; you should now have the "No System or +/ENTER
pressed" menu. Press 4 (Terminal Mode) on the 49G, and then press
any key on the emulator. The emulator should now be at "Xmodem
Server Waiting for command" and the 49G at the "Download" menu. On
the 49G, press 1 (Download System) to commence the download; the
emulator should display "Xmodem Server" with various messages
showing the progress, and the 49G should show various messages
showing the progress. The download should take about 20-25
minutes.... Eventually the emulator will display "Xmodem Server
Waiting for command" and the 49G will display "The system may not
be installed. Please go to 'Download Pack' Menu"; at this point
press any key on the 49G, which should get you to the "Download"
menu, and then press 2 (Download Packs). After a few seconds, the
49G should display "System present Press Q twice to reboot". The
first press of Q takes you back to the "Download" menu, and the
second press reboots the 49G with the new ROM. On the emulator,
press CANCEL to exit Xmodem Server mode, and close the emulator.
Run some tests on the 49G to verify correct operation. In
particular, with the HoldDown ON and D tests, run 5 (FastROM), 6
(FastRAM), 7 (FullROM), 8 (FullRAM), and 9 (FROM Format), and run
the HoldDown ON and E repeating test. All tests should pass.
--
Regards,
James
Heiko Arnemann
thanks a lot for your detailed information and instructions, how to
update HP 49G to ROM 2.09
news:8495b$45833e29$4267ea90$49...@123.NET...
I made the ROM-update just after the post from Andreas Moeller
news:1156233631.5...@74g2000cwt.googlegroups.com...
in August this year.
It is maybe requirred to call the PINIT command ones and loose some
files in the flash? I canot remember well, but it was nothing dramatic
and
for me it was required to re-load the new EQ-library (mentioned in your
post).
The ROM's have obviously been updated, taking care for the HP 49G,
and I can understand HP, giving not an official release of the ROM for
HP 49G because of missing documentation for some bugfixes and missing
effort
to test it.
Up to now, I did not found any negative impact to my HP 49G due to ROM
update
to 2.09. I would say, it is the best ROM, available for the HP 49G.
Best regards
Heiko
Veli-Pekka Nousiainen
"Heiko Arnemann" <Heiko.A...@gmx.de> wrote in message
news:458443dc$0$1120$ba62...@news.skynet.be...
Is it?
You can use the same ROMUPLOAD from Emulator procedure
and Parisse's ROM where there is the Spreadsheet extension, too
It is!
Because
there exists a better library, which handles columns up to ZZ
and it also includes a nice stack handling super-command
:-D
John H Meyers
> a calculator that it apparently wasn't intended to be used on
It looks to me as though compatibility was thought of throughout
the entire development (which included development on an emulator),
which may be why it is in fact compatible still,
both with emulator and the real thing that is emulated,
and continues to work with Prof. Parisse's
recently mentioned "capes" project,
containing even more recently modified components.
Your time-stamp sleuthing is very interesting;
I would take a guess that it correctly indicates
which is the "master," and which other is derived from it,
as in the following ending to the classic story
"Farewell to the Master," by Harry Bates,
which later inspired the film "The Day the Earth Stood Still"
["spoiler" below -- better to read the complete story,
http://thenostalgialeague.com/olmag/bates.html
if you have never heard it from the beginning]
"I want you to tell your master -- the master yet to come --
that what happened to the first Klaatu was an accident,
for which all Earth is immeasurably sorry. Will you do that?"
"I have known it," the robot answered gently.
"But will you promise to tell your master -- just those words --
as soon as he is arrived?"
"You misunderstand," said Gnut, still gently,
and quietly spoke four more words.
As Cliff heard them a mist passed over his eyes and his body went numb.
As he recovered and his eyes came back to focus
he saw the great ship disappear.
It just suddenly was not there anymore.
He fell back a step or two.
In his ears, like great bells, rang Gnut's last words.
Never, never was he to disclose them until the day he came to die.
"You misunderstand," the mighty robot had said,
"_I_ am the master."
Veli-Pekka Nousiainen
news:8495b$45833e29$4267ea90$49...@123.NET...
X
> pressed" menu. Press 4 (Terminal Mode) on the 49G, and then press
> any key on the emulator. The emulator should now be at "Xmodem
> Server Waiting for command" and the 49G at the "Download" menu. On
> the 49G, press 1 (Download System) to commence the download; the
> emulator should display "Xmodem Server" with various messages
After 4 Terminal mode I only get a blank screen
whether the (right type of) cable is plugged or not
--
Veli-Pekka
James M. Prange
Same here; when you get that blank screen, click on a key (I
normally use SPC for "any key") on the emulator; that should get
you to the Download menu on the emulator.
Other than that, I've seen some strange communication problems
from a loose DB9 connection; apparently okay from the calculator
to the PC, but not from the PC to the calculator.
--
Regards,
James
James M. Prange
Heiko Arnemann wrote:
> Hello James,
> thanks a lot for your detailed information and instructions, how to
> update HP 49G to ROM 2.09
> news:8495b$45833e29$4267ea90$49...@123.NET...
>
> I made the ROM-update just after the post from Andreas Moeller
> news:1156233631.5...@74g2000cwt.googlegroups.com...
> in August this year.
Your link doesn't work for me, but I expect that you mean this
post:
http://groups.google.com/group/comp.sys.hp48/browse_frm/thread/b20c66cdf6c2a524/b5e2ed54f9f9ea44?
For other newsreaders, it may be possible to find Andreas's post
by a search for this header:
Message-ID: <1156233631.5...@74g2000cwt.googlegroups.com>
Yes, that's when I first upgraded my 49G to 2.09 too.
I mentioned that it was possible in the Museum of HP Calculators
forum, and when a question was asked I went into detail, and then
it was suggested that I post the information to this newsgroup, so
I started this new thread on the subject. I'm hoping that many who
have a 49G will give it a try; if it doesn't work out, it's always
possible to revert to an earlier ROM revision.
> It is maybe requirred to call the PINIT command ones and loose some
> files in the flash? I canot remember well, but it was nothing dramatic
I didn't lose anything from the user flash banks or have to
execute PINIT after the upgrade. Thomas Rast's pfree program shows
me that I still have various objects (and objects marked as
"deleted") in banks 8 through F after upgrading to 2.09, with no
CRC errors. For pfree (Port Browser), see:
http://www.hpcalc.org/details.php?id=5439
Has anyone who's tried 2.09 on a 49G experienced such problems?
> and
> for me it was required to re-load the new EQ-library (mentioned in your
> post).
Quite so. With some of the previous ROMs (I don't recall exactly
which ones) the equation library was built-in; in revisions 2.08
and 2.09, if you want it, then you have to install it as external
libraries.
> The ROM's have obviously been updated, taking care for the HP 49G,
Well, at least we have an "unofficial" 2.09 ROM that seems to work
just as well on the 49G as it does on the 49g+, except of course
being slower. Why not "officially" support it? Okay, I suppose
that there could be concern that some wouldn't purchase a current
model if the 49G works well enough, but I really don't think that
it would cut into their sales very much, and I expect that it
would result in some customer goodwill and restore some confidence
in HP calculators.
> and I can understand HP, giving not an official release of the ROM for
> HP 49G because of missing documentation for some bugfixes and missing
> effort
> to test it.
For the missing user documentation, why not combine the on-line
documentation for the entire 49 series (49G, 48gII, 49g+, and
50g)? The AUR for the 48gII and 49g+ is already combined; it seems
to me that adding the 49G (using the same ROM revision as the
49g+) and 50g wouldn't require all that much extra effort.
Including information on the differences between the models
shouldn't be that difficult. My guess is that they could get
trusted members of the user community to do it for free. Maybe
they could make the 49 series documentation some sort of "Wiki"
project?
Of course documentation of the added Saturn+ instructions for the
ARM-based models would be a separate project. For what's available
so far, see:
http://www.hpcalc.org/details.php?id=6259
As for the effort to test it, it seems to me that the 49g+/50g ROM
is basically a 49G ROM, with some added hardware dependent code
(such as for external I/O, SD card, display size, and keyboard)
and some replacements of hardware Saturn code by faster Saturn+
code. If it's been verified that the hardware dependencies are
implemented correctly, and that those code replacements actually
do accomplish the same thing, then won't testing in one model
effectively test the other model? Other than that, how thoroughly
has any 49 series ROM been tested before it's been released? I
expect that the developers do make a real effort to test any
changes that they make, but it seems to me that much of the
testing has been by the user community.
But yes, I do understand your points; those are the sort of things
that I meant by "corporate red tape".
> Up to now, I did not found any negative impact to my HP 49G due to ROM
> update
> to 2.09. I would say, it is the best ROM, available for the HP 49G.
Agreed, and certainly much better than 1.18, the last official
ROM revision for the 49G.
--
Regards,
James
James M. Prange
> "Heiko Arnemann" <Heiko.A...@gmx.de> wrote in message
> news:458443dc$0$1120$ba62...@news.skynet.be...
<snip>
>> Up to now, I did not found any negative impact to my HP 49G due to ROM
>> update
>> to 2.09. I would say, it is the best ROM, available for the HP 49G.
>
> Is it?
> You can use the same ROMUPLOAD from Emulator procedure
> and Parisse's ROM where there is the Spreadsheet extension, too
>
> It is!
> Because
> there exists a better library, which handles columns up to ZZ
> and it also includes a nice stack handling super-command
It occurs to me that it may be better to implement some "extras"
as external libraries instead of including them in a ROM file.
--
Regards,
James
James M. Prange
> On Fri, 15 Dec 2006 18:30:25 -0600, James M. Prange wrote:
>
>> a calculator that it apparently wasn't intended to be used on
>
> It looks to me as though compatibility was thought of throughout
> the entire development
It's always been a strong point with the RPL models that each new
ROM usually works with programs developed for a previous ROMs,
provided that the program uses only supported entry points. What I
find remarkable is that a ROM developed for ARM-based models works
just fine with an older hardware Saturn model.
> (which included development on an emulator),
> which may be why it is in fact compatible still,
> both with emulator and the real thing that is emulated,
I think that that would indeed explain a lot. It would make sense
to use an emulator during development, and since it's the hardware
Saturn that being emulated, that would mean using "pure hardware
Saturn" code during development. And there's a lot to be said for
developing just one ROM for all current models, with some
conditional code depending on the hardware detected (I'm assuming
that the new ROM is used in new production of the 48gII, and
perhaps planned for possible future models). Presumably, it's easy
enough to leave code needed for the 49G in place. So at that
point, 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.
> and continues to work with Prof. Parisse's
> recently mentioned "capes" project,
> containing even more recently modified components.
"Capes"?
I haven't been following the CAS, although certain changes to its
behaviour would be very welcome. But I see that he has more recent
49 series ROMs at his site; maybe I'll give it a try.
For anyone interested, see:
http://www-fourier.ujf-grenoble.fr/~parisse/
(If you prefer, click on "English version" at upper left corner.)
<snip>
--
Regards,
James
Veli-Pekka Nousiainen
> Veli-Pekka Nousiainen wrote:
>
>> "Heiko Arnemann" <Heiko.A...@gmx.de> wrote in message
>> news:458443dc$0$1120$ba62...@news.skynet.be...
> It occurs to me that it may be better to implement some "extras"
> as external libraries instead of including them in a ROM file.
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!
:-D
Veli-Pekka Nousiainen
> Veli-Pekka Nousiainen wrote:
>> "James M. Prange" <jmpr...@i-is.com> wrote in message
>> news:8495b$45833e29$4267ea90$49...@123.NET...
>> X
>>> pressed" menu. Press 4 (Terminal Mode) on the 49G, and then press
>>> any key on the emulator. The emulator should now be at "Xmodem
>>> Server Waiting for command" and the 49G at the "Download" menu. On
>>> the 49G, press 1 (Download System) to commence the download; the
>>> emulator should display "Xmodem Server" with various messages
>> X
>> After 4 Terminal mode I only get a blank screen
>> whether the (right type of) cable is plugged or not
>
> Same here; when you get that blank screen, click on a key (I
> normally use SPC for "any key") on the emulator; that should get
> you to the Download menu on the emulator.
I mean my real calculator display blank after Terminal Mode
I can not choose 1 - I tried with two calculators
and I tired with two serial cables
and I tried with two serial ports
8 tries if you can count binary exponents
)/(&%()/"#
> Other than that, I've seen some strange communication problems
> from a loose DB9 connection; apparently okay from the calculator
> to the PC, but not from the PC to the calculator.
I have to try on another PC
> --
> Regards,
> James
>
John H Meyers
> my real [49G] calculator displays blank after Terminal Mode
As http://www.hpcalc.org/hp49/pc/rom/ says:
"Press [4] to select terminal mode. A blank screen appears."
This may be where the 49G awaits receipt of
an initial "four special bytes" on the serial port,
which signifies a proper source from which to accept ROM;
the FDP program (or ROMUPLOAD command) sends these
when told to start the transmission.
Have you first tried any plain old serial file transfer,
to see whether serial communications is working at all?
(if not, then neither will ROM transfer).
[r->] [OFF]
John H Meyers
> 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 -- 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 :)
"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?
> 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];
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.
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.
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,
which I suppose could be done after the complete compilation
of the original ROM, just as JMP suggests.
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.
-[ ]-
Veli-Pekka Nousiainen
"John H Meyers" <jhme...@nomail.invalid> wrote in message
news:op.tkr7u...@isdept23.ia.mum.edu...
> On Mon, 18 Dec 2006 16:12:32 -0600, VPN wrote:
>
>> my real [49G] calculator displays blank after Terminal Mode
>
> As http://www.hpcalc.org/hp49/pc/rom/ says:
> "Press [4] to select terminal mode. A blank screen appears."
>
> This may be where the 49G awaits receipt of
> an initial "four special bytes" on the serial port,
> which signifies a proper source from which to accept ROM;
> the FDP program (or ROMUPLOAD command) sends these
> when told to start the transmission.
OK
> Have you first tried any plain old serial file transfer,
> to see whether serial communications is working at all?
> (if not, then neither will ROM transfer).
Thanks!
Veli-Pekka Nousiainen
"Veli-Pekka Nousiainen" <DROP...@dlc.fi> wrote in message
news:XWKhh.4730$8p6....@reader1.news.saunalahti.fi...
>
> "John H Meyers" <jhme...@nomail.invalid> wrote in message
> news:op.tkr7u...@isdept23.ia.mum.edu...
>> On Mon, 18 Dec 2006 16:12:32 -0600, VPN wrote:
>>
>>> my real [49G] calculator displays blank after Terminal Mode
>>
>> As http://www.hpcalc.org/hp49/pc/rom/ says:
>> "Press [4] to select terminal mode. A blank screen appears."
>>
>> This may be where the 49G awaits receipt of
>> an initial "four special bytes" on the serial port,
>> which signifies a proper source from which to accept ROM;
>> the FDP program (or ROMUPLOAD command) sends these
>> when told to start the transmission.
>
> OK
Now it suddenly worked!
Thanks for the "four special bytes" -tip
John the Great!
James M. Prange
> 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
James M. Prange
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
Veli-Pekka Nousiainen
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?
What an excellend idea.
You're Hired! <Donald Trumoh's voice with "snake" added>
par...@domain.invalid
> 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.
Veli-Pekka Nousiainen
news:45899627$0$5110$ba4a...@news.orange.fr...
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
manjo
> 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
There you go VPN
-again with lagrer Flash and RAM :-)
Hehe
is it your whish, your dream or a nightmare ? :-)
manjo
Veli-Pekka Nousiainen
news:emc99b$lts$1...@ss408.t-com.hr...
The product clearly needs several upgrades
They can be also gradual since the component prices decline differently
Flash is cheap so I do wonder why not design a new "motherboard"
SRAM is more expensive so care is needed for the upgrade moment
and also a study if it really is needed
The options always need a view of the market as a whole
One can't just support a bunch of enthusiastics
but a leadership is also needed (since HP *is* the best - after all)
I just pray the God Allmighty that I could do something about it
--
Happy Chrustmas!
manjo
> They can be also gradual since the component prices decline differently
> Flash is cheap so I do wonder why not design a new "motherboard"
> SRAM is more expensive so care is needed for the upgrade moment
> and also a study if it really is needed
> The options always need a view of the market as a whole
> One can't just support a bunch of enthusiastics
> but a leadership is also needed (since HP *is* the best - after all)
> I just pray the God Allmighty that I could do something about it
> --
> Happy Chrustmas!
Actualy...
no need for major changes in motherboard.
RAM and FLASH can be expanded by soldering second chip on top of the
existing one and feeding new set of CE and OE signals
(address and data lines are shared anyways)
Main concern would be to lead out all those usefull signals out of processor
and make them
accessible like test pods or something.
You would solder more ram and/or more flash, lead corresponding CE, OE, RW
signals
and everything could be doubled in notime.
Maybe in future versions soldering pads for RAM to be for 1 MB chip
(one could solder full size 1 MB or adopt 512 kB to it)
Intelligent keyboard overlay ?
-front faceplate would come off as a single (or 2) modules similar to some
cell phone skins (keys may be separate from faceplate)
-then you would attach for example QWERTY overlay with apropriate face cover
and keys
-by means of contacts / switches (or optics) calculator would recognise the
type of overlay and adjust accordingly
-there would be 4 major overlay types:
1. standard (like it is now)
2. oldfashion (with large enter key -two nearby keys would act as one)
3. developer/querty-like
(not realy a querty keyboard, but keyboard with key arrangement optimised
for text and numbers entry rather than calculator operations)
(or maybe landscape-oriented screen and qwerty keyboard)
4. user defined
I'm i dreaming or what :-) ?
manjo
John H Meyers
> 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.
How do you see that? Are you using the "Nosy" library?
Have you compared ROM byte by byte between emulator
and hardware, and found that no code has been relocated
by even a single nibble between these platforms,
but only a couple of bytes have here and there been altered?
According to your time-stamp research, this must mean
that any such changes (such as overlaying the start of
extremely common ML "Loop" code by one such instruction
that is *interpreted* by the ARM emulator as meaning
to do this particular whole sequence faster)
are applied *afterwards*, while making a file to be used
for an ARM calc ROM update (which combines ARM OS and Calc OS).
IIRC, the extremely commonly used supported ML return point
GETPTRLOOP (at 05143 in both 48 and 49 series),
whose "Loop" part at 05149 is one of those very frequent
code snippets that can be accelerated,
as was detailed in a newsgroup post not too long ago,
didn't actually get accelerated at all in 2.09 --
anyone curious can compare with "Nosy"
in emulator vs. hardware for the same ROM version,
and see whether any particular "Loop" code
got accelerated or not,
but no harm occurs if any were missed,
except for a little less than maximum warp speed :)
Evidently the Calc OS compiler/assembler is fed only
a language that it's always known,
and outputs what has always run on emulators
(or on what's being emulated),
as might be expected by the fact that the ARM OS
is just another emulator, doing a good job
of making an identical environment
that runs the original ROM code,
this being the entire basis of the almost complete
compatibility, preserving and lengthening the
profitable lifetime of the original product line,
and the massive collection of third party software
which also enhances its value.
But of course this is of only academic interest,
for people who want to play with emulators,
and has nothing to do with the mouse who lived under a granary,
under a small hole, until the widening of the hole
attracted the attention of the farmer,
who then permanently boarded it up.
-[ ]-
James M. Prange
> On Wed, 20 Dec 2006 08:38:11 -0600, James M. Prange wrote:
>
>> 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.
>
> How do you see that? Are you using the "Nosy" library?
No, at least not yet, but anyone is welcome to do some research
with Nosy.
> Have you compared ROM byte by byte between emulator
> and hardware, and found that no code has been relocated
> by even a single nibble between these platforms,
> but only a couple of bytes have here and there been altered?
Well, I've now had a better look, but please understand that I've
been using a *text* editor with some limited binary/hex editing
capability added in, not an editor designed "from the ground up"
mostly for working with binary/hex files, so there's some doubt as
to the thoroughness and even the accuracy of this. Working with
nibbles instead of bytes is rather difficult in any PC-based
editor that I've ever tried, and ROMG+.49G seems to consist of
bytes with values from 00 through 0F. I surmise that nibbles have
been expanded into bytes for ROM+.49G, which would make sense for
using it with a PC.
My process was to expand the nibbles in a copy of the 1264KiB
4950_92.bin to bytes, resulting in a 2528KiB file. Comparing this
modified file with a copy of the ROMG+.49G, it turns out that the
first 480KiB isn't present in the ROMG+.49G file; I suppose that
it's for loading the file on the calculator and running the
Saturn+ emulator. Editing out that first 480KiB gave me a 2048KiB
(2MiB) file. ROM+.49G is 4MiB, but the last 2MiB (and then some)
appears to be padding, so I edited that out. Now both 2MiB
modified files have some padding, but it turns out that they're
*mostly* the same, with a few bytes "here and there" different.
The other bytes aren't "shifted"; they have the same offsets into
the modified files.
From here on, I'll refer to the bytes in the files as "nibbles",
as it's more convenient and the high-order nibble in each byte is
always 0.
The most frequent difference is that in several (but far from all)
places, the nibble sequence 142 in the Emu48 file has replaced by
81B in the calculator file. To put this into context, 142 isn't
replaced except where it's the beginning of 142164808C or
142164131, and not always even there. Of the 412 occurrences of
142164808C, 393 have been replaced by 81B164808C, and the other 19
have been left as is.
17 other changes, 1 place each:
80A203400100805340 -> 80B040100100805340 (1 of 2 places)
8AE4003D -> 80B2401D
340000C80580580580 -> 80B140180580580580 (1 of 2 places)
427D91 -> 81BE91
13706D90620D18718 -> 81BA6D90620D18718
142164131 -> 81B864131
8ADAC -> 81B9C
146132C21345B -> 81BB32C21345B
D214EC6132C2134161 -> 81BCEC6132C2134161 (1 of 2 places)
D9136184142132D8E7 -> 81BD6184142132D8E7 (1 of 3 places)
CF43D1 -> 80B301
CE4C480 -> 80B7001
CE49480 -> 80B6001
20818F2 -> 80B8001
7F40152 -> 80B2001
808240CE -> 80B1001E
20340CA30D -> 80B40CA30D
Some of the above replacement sequences already exist elsewhere in
ROMG+.49G.
8 changes (1 place each) that come just before what looks like
padding -- ends of blocks? CRCs?
87640FFF... -> A74D0FFF...
7788FFFFFF000... -> 0836FFFFFF000...
E58100FF000... -> BDD300FF000...
079200FFF... -> 175C00FFF...
F4290FFF... -> 1F670FFF...
F77FFF... -> C81FFF...
C40FFF... -> 3BFFFF...
9FCF00FFF... -> 572600FFF...
I haven't researched what all of these changes accomplish, but it
seems to me that a reasonable guess would be faster execution.
I suppose that some of them might not make much sense without
analyzing what the contiguous code does. It may be that some of
the potential replacements that seem to fit the (limited) pattern
but weren't done wouldn't actually work.
> According to your time-stamp research, this must mean
> that any such changes (such as overlaying the start of
> extremely common ML "Loop" code by one such instruction
> that is *interpreted* by the ARM emulator as meaning
> to do this particular whole sequence faster)
> are applied *afterwards*, while making a file to be used
> for an ARM calc ROM update (which combines ARM OS and Calc OS).
Well, I wouldn't call it "research"; I just happened to notice
that the time-stamp on the calculator ROM is a little later than
the time-stamp on the Emu48 ROM. This suggests to me that maybe
the calculator ROM was made from the Emu48 ROM, or perhaps both
from shared source code, but of course there could be many other
reasons for those time-stamps. Based on my "closer look", it
looks to me as if it was a matter of replacing certain sequences
of nibbles (I guess still expanded to bytes) in the compiled
version of ROMG+.49G.
My guess is that these changes were easy to make to a copy of
ROMG+.49G and resulted in some improved performance.
> IIRC, the extremely commonly used supported ML return point
> GETPTRLOOP (at 05143 in both 48 and 49 series),
> whose "Loop" part at 05149 is one of those very frequent
> code snippets that can be accelerated,
> as was detailed in a newsgroup post not too long ago,
> didn't actually get accelerated at all in 2.09 --
> anyone curious can compare with "Nosy"
> in emulator vs. hardware for the same ROM version,
> and see whether any particular "Loop" code
> got accelerated or not,
Okay, some potential "accelerations" weren't done; I don't know
why. Perhaps they would've required shifting other code, or making
changes elsewhere, or maybe the developers just didn't bother.
After all, sometimes "good enough" really is good enough, and
there's are lot to be said for a "don't fix what ain't broke"
policy.
> but no harm occurs if any were missed,
> except for a little less than maximum warp speed :)
Indeed, all hardware Saturn (or Emu48) code should run on the
emulated Saturn+ processor in the ARM-based models.
> Evidently the Calc OS compiler/assembler is fed only
> a language that it's always known,
> and outputs what has always run on emulators
> (or on what's being emulated),
> as might be expected by the fact that the ARM OS
> is just another emulator, doing a good job
> of making an identical environment
> that runs the original ROM code,
Feel free to follow my procedure for finding the changes, and then
modify a copy of ROMG+.49G to match, and try it out on Emu48 or a
real 49G.
> this being the entire basis of the almost complete
> compatibility, preserving and lengthening the
> profitable lifetime of the original product line,
> and the massive collection of third party software
> which also enhances its value.
>
> But of course this is of only academic interest,
> for people who want to play with emulators,
> and has nothing to do with the mouse who lived under a granary,
> under a small hole, until the widening of the hole
> attracted the attention of the farmer,
> who then permanently boarded it up.
--
Merry Christmas!
James
James M. Prange
Fair enough, and thanks for the reply.
I note that you added these without taking away a user bank, as
the equation library did with some ROM revisions, so that's fine.
Any thoughts on whether we'll be seeing these in a future official
HP ROM?
--
Merry Christmas,
James
John H Meyers
[extensive comparison of ROM files :]
Well, I had been thinking to compare what you can see with Nosy,
on an ARM calc vs. on an emulator, but you've gone very far
with analyzing files instead :)
> It may be that some of the potential replacements
> that seem to fit the (limited) pattern
> but weren't done wouldn't actually work.
Why not?
I haven't looked, but I wonder what you'd find
if you tried the "French math teachers test" version,
which I believe has something for calc and something for emulator;
being even more recent, it might have more updates in it
(what VERSION and VER does it say it is?)
> Well, I wouldn't call it "research"; I just happened to notice
> that the time-stamp on the calculator ROM is a little later than
> the time-stamp on the Emu48 ROM. This suggests to me that maybe
> the calculator ROM was made from the Emu48 ROM
Well, it certainly wasn't the reverse :)
> Indeed, all hardware Saturn (or Emu48) code should run
> on the emulated Saturn+ processor in the ARM-based models.
But not vice versa, except for something which tests
whether it's executing on "Saturn" vs. "Saturn+"
(which was designed to work on original Saturn,
as either emulated or the real thing).
Well, I have to go park this reindeer sled which just drove in.
I think you discovered something interesting, and Happy New Year.
[r->] [OFF]
John H Meyers
> I note that [BP] added [Geometry/Spreadsheet]
> without taking away a user bank, as the equation library did
> with some ROM revisions.
It didn't "take away" a user bank (meaning that it
didn't enlarge ROM and reduce the number of user banks,
as did 49G version 1.19), but it did *overwrite*
the first user bank during each ROM update 2.0 thru thru 2.06,
which was a very crude way of *installing* the equation library
*into* the first user bank (while annoyingly purging any user files
which had the misfortune to have been sharing that same first bank).
It was done that way to force a simultaneous update of the formerly
version-dependent equation library with each ROM update,
but at the cost of sacrificing any confidence
in flash being reliable for permanent user backup and storage;
not a serious problem for anyone who prudently obtained
and used an SD/MMC card as independent secondary backup,
but potentially nerve-wracking for anyone lacking a card
(and possibly also lacking computer file transfer,
which HP officially supports only via a USB driver
and a transfer application for certain Windows versions).
All this is no longer an issue, however, since ROM updates
for 2.08 and later versions confine themselves to overwriting
only the actual ROM banks, and supply the Equation Library
(now version-independent) in the traditional form of separate files,
which you can now optionally install or ignore.
[r->] [OFF]
Bernard Parisse
>
> I note that you added these without taking away a user bank, as
> the equation library did with some ROM revisions, so that's fine.
>
> Any thoughts on whether we'll be seeing these in a future official
> HP ROM?
>
I don't know, it depends on HP.
Veli-Pekka Nousiainen
news:45923a07$0$27404$ba4a...@news.orange.fr...
I wish I were the Future Product Manager