f



Installing latest 49g+/50g (emulator) ROM on a 49G

First off, this is a rehash of information available in previous
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

0
jmprange (9)
12/16/2006 12:30:25 AM
comp.sys.hp48 9763 articles. 1 followers. fbarbaise (60) is leader. Post Follow

29 Replies
3511 Views

Similar Articles

[PageSpeed] 19

Hello James,
thanks a lot for your detailed information and instructions, how to
update HP 49G to ROM 2.09
 news:8495b$45833e29$4267ea90$4917@123.NET...

I made the ROM-update just after the post from Andreas Moeller
news:1156233631.510946.151880@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 


0
Heiko
12/16/2006 6:25:25 PM
"Heiko Arnemann" <Heiko.Arnemann@gmx.de> wrote in message 
news:458443dc$0$1120$ba620e4c@news.skynet.be...
> Hello James,
> thanks a lot for your detailed information and instructions, how to
> update HP 49G to ROM 2.09
> news:8495b$45833e29$4267ea90$4917@123.NET...
>
> I made the ROM-update just after the post from Andreas Moeller
> news:1156233631.510946.151880@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.

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


0
Veli
12/16/2006 7:28:37 PM
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 (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."

http://en.wikipedia.org/wiki/The_Day_the_Earth_Stood_Still
0
John
12/16/2006 10:45:33 PM
"James M. Prange" <jmprange@i-is.com> wrote in message 
news:8495b$45833e29$4267ea90$4917@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
-- 
Veli-Pekka


0
Veli
12/18/2006 3:00:19 PM
Veli-Pekka Nousiainen wrote:
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:8495b$45833e29$4267ea90$4917@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.

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

0
James
12/18/2006 5:21:21 PM
Hello Heiko,

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$4917@123.NET...
>
> I made the ROM-update just after the post from Andreas Moeller
> news:1156233631.510946.151880@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.510946.151880@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

0
James
12/18/2006 5:51:52 PM
Veli-Pekka Nousiainen wrote:

> "Heiko Arnemann" <Heiko.Arnemann@gmx.de> wrote in message
> news:458443dc$0$1120$ba620e4c@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

0
James
12/18/2006 6:24:59 PM
John H Meyers wrote:
> 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

0
James
12/18/2006 7:50:38 PM
"James M. Prange" <jmprange@i-is.com> wrote in message 
news:c244e$4586dd05$4267ebc2$30790@123.NET...
> Veli-Pekka Nousiainen wrote:
>
>> "Heiko Arnemann" <Heiko.Arnemann@gmx.de> wrote in message
>> news:458443dc$0$1120$ba620e4c@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!
:-D 


0
Veli
12/18/2006 10:06:16 PM
"James M. Prange" <jmprange@i-is.com> wrote in message 
news:2720c$4586ce19$4267ebc2$27951@123.NET...
> Veli-Pekka Nousiainen wrote:
>> "James M. Prange" <jmprange@i-is.com> wrote in message
>> news:8495b$45833e29$4267ea90$4917@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
> 


0
Veli
12/18/2006 10:12:32 PM
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.

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]
0
John
12/19/2006 1:02:54 AM
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 -- 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.

-[ ]-
0
John
12/19/2006 3:53:45 AM
"John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
news:op.tkr7u4gknn735j@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! 


0
Veli
12/19/2006 5:38:56 AM
"Veli-Pekka Nousiainen" <DROP_vpn@dlc.fi> wrote in message 
news:XWKhh.4730$8p6.4541@reader1.news.saunalahti.fi...
>
> "John H Meyers" <jhmeyers@nomail.invalid> wrote in message 
> news:op.tkr7u4gknn735j@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!


0
Veli
12/19/2006 6:32:33 PM
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

0
James
12/20/2006 2:38:11 PM
Veli-Pekka Nousiainen wrote:
> "James M. Prange" <jmprange@i-is.com> wrote in message
> news:c244e$4586dd05$4267ebc2$30790@123.NET...
>> Veli-Pekka Nousiainen wrote:
>>
>>> "Heiko Arnemann" <Heiko.Arnemann@gmx.de> wrote in message
>>> news:458443dc$0$1120$ba620e4c@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

0
James
12/20/2006 4:10:27 PM
"James M. Prange" <jmprange@i-is.com> wrote in message 
news:ad62a$45896078$4267ebd5$2287@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>


0
Veli
12/20/2006 7:54:37 PM
 > 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.
0
parisse
12/20/2006 8:00:14 PM
<parisse@domain.invalid> wrote in message 
news:45899627$0$5110$ba4acef3@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


0
Veli
12/20/2006 8:17:05 PM
> 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

There you go VPN
-again with lagrer Flash and RAM :-)

Hehe
is it your whish, your dream or a nightmare ? :-)

manjo


0
manjo
12/20/2006 9:20:50 PM
"manjo" <not-available-spam@rocketmail.com> wrote in message 
news:emc99b$lts$1@ss408.t-com.hr...
>> 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
>
> There you go VPN
> -again with lagrer Flash and RAM :-)
>
> Hehe
> is it your whish, your dream or a nightmare ? :-)

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!


0
Veli
12/20/2006 9:59:10 PM
> 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!

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


0
manjo
12/20/2006 11:01:24 PM
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?
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.

-[ ]-
0
John
12/21/2006 2:34:02 AM
John H Meyers wrote:
> 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

0
James
12/25/2006 3:52:12 AM
parisse@domain.invalid wrote:
>  > 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.

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

0
James
12/25/2006 6:08:44 PM
On Sun, 24 Dec 2006 21:52:12 -0600, James M. Prange wrote:

[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]
0
John
12/26/2006 3:18:43 AM
On Mon, 25 Dec 2006 12:08:44 -0600:

> 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]
0
John
12/26/2006 5:15:36 AM
> 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?
> 

I don't know, it depends on HP.
0
Bernard
12/27/2006 9:17:34 AM
"Bernard Parisse" <parisse@domain.invalid.fr> wrote in message 
news:45923a07$0$27404$ba4acef3@news.orange.fr...
>> 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?
>>
>
> I don't know, it depends on HP.

I wish I were the Future Product Manager


0
Veli
12/27/2006 4:45:08 PM
Reply:

Similar Artilces:

installing 49g+ rom on the 49g
Hello, I have an hp 49 running rom 1.9.6 beta. I just read about the hp 49g+ on hpcalc.org and found a link to download the hp 49g+'s rom (v.1.2.2). Thus, I am just wondering if its safe to put the new rom on my 49g. I don't have a lot of stored info on my 49g, but as a Math major, I do use the calc all the time so I need something stable. However, I would really appreciate any extended functionality with the new rom. So can you please offer your suggestions as to whether it is safe for me to upgrade to 1.2.2. Thanks for the help. Serge I would seriously doubt it would be OK sinc...

49G+ ROM on the 49G
I saw a 1.22 ROM for the 49G+ on hpcalc.org. (I believe this question has been asked before but never properly answered) Can I install this ROM on my 49G? If I can what are the advantages/disadvantages and is it any different from installing a normal 49G ROM on the 49G? Thanxz in Advance CID > I saw a 1.22 ROM for the 49G+ on hpcalc.org. (I believe this question > has been asked before but never properly answered) Can I install this > ROM on my 49G? No, the 49g+ ROM won't work on the 49G. Tom Lake CID wrote: > I saw a 1.22 ROM for the 49G+ on hpcalc.org. > (I believ...

ROMs for 49G and 49G+
Will the 49G be able to download and use the ROMs for the 49G+? Has any one tried this yet? Is there a site for the 49G+ ROM? Since the 49G+ has the user manual and guide, are there appreciable differences to the manuals for the 49G? thx. -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =----- "howard" <erickson@codenet.net> writes: > Will the 49G be able to download and use the ROMs for the 49G+? Has any one > tried this yet? ...

HP 49G/49G+/50G ROM programming language
What is (are) the language(s) used for programming the ROM of these calculators ? Assembler ? SYSRPL ? Mix of both ? other ? and what is (are) the tool(s) used ? On Aug 13, 8:28=A0am, lary <lar...@hotmail.fr> wrote: > What is (are) the language(s) used for programming the ROM of these > calculators ? Assembler ? SYSRPL ? Mix of both ? other ? and what is > (are) the tool(s) used ? Many of the lower-level routines are done in Saturn assembler. Then on top of those, you've got SysRPL routines that call other SysRPL routines as well as the assembler routines. I think most of ...

To 49g+ or not to 49g+
Like many of you, I've owned several HP calcs over the years. A 33C, 41C (not V or X), and a 48sx. Unfortunately, I sold the first two when progressing up the chain (I was a hungry student), and then the 48sx developed a bad display in the lower portion (which made it mostly useless from not being able to see the leftmost characters on the bottom line). A couple of years ago the 48 was stolen from my house along with lots of other things -- the only good that came of that was my knowledge that the thief got a broken calculator. So for a couple of years now I have watched (and la...

Emulating the 49G+: Lies my 49g+ told me...
Greetings All! In continuing my quest to emulate the 49G+ I have begun the process of attempting to figure out the inner workings of the 80B(BUSCC) and 81B series of opcodes that are peppered throughout the Saturn-based ROM code. Thanks to the generous help of Laurent Desnogues I now have a dissassembly of the ARM portion of the 49g+ code for ROM version 1.22. I'm posting this table of BUSCC information so that others can help fill it in. It's fairly useless in it's current form, but hopefully with the help of others in this forum it can be fleshed out into something useful... ------------------------ HP49G+ BUSCC implementation details: ROM v1.22 ---------------------------------------------- The implementation of the 0x80B opcode on the 49G+ is somewhat different than on previous generations of Saturn-based calculators. This opcode is now being used as a method of calling various ARM-based subroutines that perform accelerated RPL functions as well as emulator specific tasks. The format of the opcode has also been changed to support additional nibbles after the 80B prefix. This table is only a preliminary attempt to document some of the functions of this opcode and is neither complete nor accurate - it's just a start... BUSCC opcode format: 80Bxx(y...) where xx = a two nibble function code, and (y...) indicates a variable number of function-specific nibbles (from 0 to ??). BUSCC CODE | EXTRA NIBS | TOTAL LENGTH | DESCRIPTION -----------+------------...

49g+ rom for emulator
I installed emu48 last night on my laptop, but I'm having trouble getting a recent version of the ROM to work. I downloaded the last several revision 2.x ROMs from hpcalc.org, but couldn't get the convert.exe in emu48 to be happy with them. I did manage to find a revision 1.x ROM somewher on the Internet which was already in the form that emu48 was happy with. Is it possible to get a 2.x 49g+ ROM to work with emu48? If so, what do I need to do with the .bin file from the .zip file? Thanks. Normal ROMs will not work because of the ARM processor code in them. Download the special ...

48Gii/49G/49G+/50G software compatibility
Hello, This program returns for: 48Gii : 0 49G : 1 49G+ : 2 50G : 3 :: CK0NOLASTWD CODE * Developed by GaaK * 48Gii : #0 * 49G : #1 * 49G+ : #2 * 50G : #3 GOSBVL =3DSAVPTR * Save Pointers A=3D0 A * Register used Aa (5 nibbles) SR=3D0 BUSCC * $80B ?SR=3D0 * If 49G?, GOYES A+1 * then A=3D1 * * if not, is ARM (48Gii/49G+/50G) isARM GOSUB 48Gii? * If 48Gii? GOC A+0 * then A=3D0 * * if not, is 49G+/50G GOSUB 50G? * If 50G? GONC A+2 * if not, is 49G+ (A=3D2) * * if yes, is 50G (A=3D3) A+3 A=3DA+1 A A+2 A=3DA+1 A A+1 A=3DA+1 A A+0 GOVLNG =3DPUSH#ALOOP * Push Aa and exit 48Gii? NIBHEX 80BB2 * 48Gii? RTN * Return 50G? NIBHEX 80BE2 * 50G? RTN * Return ENDCODE UNCOERCE ; HEX-Data (use H->): D9D2029262CCD20240008FB9760D082480B8344177104F07710540E4E4E48DC753080BB2018= 0BE2016F262B2130 ..=2E. Store it (i.e. 'CheckModel' STO) UsrRPL example: =AB CheckModel CASE DUP 0 =3D=3D THEN DROP "48Gii" END DUP 1 =3D=3D THEN DROP "49G" END DUP 2 =3D=3D THEN DROP "49G+" END 3 =3D=3D THEN "50G" END ...

Filers for the 49G and 49G+
I recently have been working with Wolfgang Rautenbergs great application 'filers'. It provides an excellent extension to the built-in filer. Great port memory management tool! And, for all of you lucky enough to already own a 49G+, a version of filers (filer5) will run on the 49G+ (can read the SD card). I highly recommend it. Get the very latest version at: http://page.mi.fu-berlin.de/~raut/WR49/index.htm Steve > Get the very > latest version at: > > http://page.mi.fu-berlin.de/~raut/WR49/index.htm > > Steve Thanks for the alert ! Regards, Yoann. ...

hp 49g/49g+
does have both possibility of step by step matricials(like autovalori and autovettori) calculous? the hp 49g standard(the blu one) has, and the new gray one? "Hierro" <chiedete@ng.invalid> wrote in message news:zHRkc.129555$hc5.5677689@news3.tin.it... > does have both possibility of step by step matricials(like autovalori and > autovettori) calculous? > the hp 49g standard(the blu one) has, and the new gray one? > The new one (it is gold not grey) has the same functionalities as the old blue one. I believe that you are interested in the EGVL and EGV commands Ar...

Logplot for 49G and 49G+
Gentlemen, Logplot is now available in hpcalc.org, which was coded by "Taka" in Japanese user's society. Refer to http://www.hpcalc.org/hp49/graphics/plotting/. Kenji Yokohama, Japan ...

conect 49g and 49g+?
Can someone explain me how to make a cable to connect a HP 49 g+ and a 49g. > Can someone explain me how to make a cable to connect a HP 49 g+ and a 49g. Since the hp49g+ uses USB and the HP49G uses RS232, this is not possible by any simple mean (like Eric would say). BUT you may take advantage of the IrDA -> RS232 adaptor that someone used and mentionned here, connected to the IR port of the 49g+, in order to then use the HP49/HP49 link cable. Regards, Yoann. ...

Ditch 49G for 49G+ ?
I have preordered a 49G+ to replace my dear 49G. Is there any reason (aside from sentimental) to keep the original 49G? I notice that the price they fetch on eBay is currently quite good, and I am considering parting with the original one to offset the price of the new one. Any reason that this would be a bad idea? I also have an older 48G and a nearly unused TI-89. I'd love to keep them all, but my wife isn't warmly acceptant of my calculator compulsiveness. I enjoy having a spare calculator around, but I am thinking that I can sell all three older models and purchase two of the...

Migrating from 49G to 49G+
Hi Everybody Iv'e been trucking through Europe for about two months, which was a great experience being a South African. I lost touch with this group since I didn't have affordable internet access, so I did not follow all the developments on views and opinions about the 49G+. I'm back in South Africa for a few weeks doing contract work at the engineering company where I used to work as a student during holidays, and will then return to Europe. I will then have to decide either to buy myself a 49G+ or a plane ticket for my girlfriend to come and visit. Easy choice. What I would l...

HP 49G ROM questions: downgrading, space usage, and experimental usage of HP 50g ROMs
Currently, I have ROM 1.10 in my HP 49G. I am planning to upgrade to ROM 1.19-6, then using Emu48, upgrade to 2.15. My questions are: 1. If I upgrade to 1.19-6 or 2.15, can I go back to 1.10? 2. I have heard that ROM versions 1.19-5 and later use an additional 64KB bank. If I downgrade, can I reclaim this block for user use? 3. ROM 2.15 in the 50g uses an additional ~250KB in Flash ROM for the emulator. If I flash it with ROMUPLOAD through Emu48, will it still consume the space? Can it be reclaimed if I downgrade? 4. In ROM 1.19-6, are there press-and-hold USER key assignments? (Fo...

49G upgrade to 49G+?
I've owned a 49G for a few years now, I use it lightly for various purposes (mostly simple numeric and matrix calculations, and smallish UserRPL programs), and I'm weighing the pros and cons of upgrading to a 49G+. I am seeking other people's opinions on whether or not the upgrade is worth it: Pros: Plastic vs rubber keys Faster computation (2-4x on average) Brighter screen, better overall appearence "new toy" value Cons: No new math functions Much worse battery life (my first set of 49g batteries lasted over 1 year) Poor compatibility with older programs. USB tra...

Software or 49g with 49g+?
Hi all, Question: can I use software written for 49g with 49g+ without porting it? I am almost sure the answer is yes, but I want be absolutely sure. Thanks for the answers. Regards manjo wrote: > Hello Dimo, > > there is no absolutely sure answer for this, but > most of the programs will work. > Especialy if program is userRPL, sysRPL programs will have to be recopiled. > Um. I thought the story was that in general, SysRPL (and even most machine language) progs would run without modification/recompiling? Certainly I've got a considerable number of 49G programs on m...

49G Libraries on the 49G+?
I have just been browsing the libraries on hpcalc.org for my newly acquired 49G+. I presently see very few libraries listed there that explicitly support the 49G+. I have downloaded a couple of libraries, organizer 1.1 and scribe 1.1, and attempted to install them on ports 0, 1, and 2 (I would prefer 2). There were no errors when I ran STO on the library. However, there were no LIB menus created for them either. Are these libraries compatible with the 49G+? If they are, I suspect that I have an understanding fault. Regards, Jon Trauntvein Did you shut the calculator off or warm start ...

49G+, 50G ROM development
I've been wondering for a while about the relationship between unofficial ROM releases and official ones. Unofficial releases seem to track with the bugzilla on hpcalc.org, but aren't done by HP (is that right?). So who's doing the unofficial releases, and how dothose udpates get fed back to official HP? I'm simply curious as a fan of HP calculators (mind you I haven't bought one since my 41C except for the 50G I'm expecting to arrive any day) because this model of ROM development seems interesting. Thanks. ...

I want to purchase a 49G+ with the latest ROM
Hello, I want to purchase a 49G+ with the latest ROM version and recent production to hopefully take advantage of any improvements in the product. Those who have purchased a new 49G+ with the new ROM update, where did you find it? Could you give me an idea of the serial numbers to look for? Thank you, Dale Richmond It isn't that hard to update it. Just get one. Toby "Dale Richmond" <dalerich@ncweb.com> wrote in message news:10188e8dskaqa55@corp.supernews.com... > Hello, > I want to purchase a 49G+ with the latest ROM version and recent > production ...

Possible bug in latest 49G+/HP50G ROM
Within the last few days I installed the latest ROM into several HP50G and HP49G+calculators. Everything seems to be running OK in the 50G's but there is something strange going on the 49G+s. When one presses ON F1 F6 on the 50G both Try to Recover Memory { YES and NO} selections behave the way they should. However when the same thing is done on the G+ the Yes selection works but there is no response to the NO selection. The F6 key is OK because it works in applications, etc. I reinstalled the ROM and it still does this. The previous ROM works OK. BTW I put in brand new batt...

New 49g+ training aid available: Using SD cards with the 49g+ ROM 1.22
http://www.hp.com/calculators/graphing/49gplus/scientists.html It is the second training aid in the list on each of the five category web pages. Hopefully this is a good resource for questions about the use of SD cards in the HP49G+. Please email any corrections, suggested additions, etc., to me at the email address: Genewright143 --- at --- hotmail Or, you can certainly feel free to post anything here as well. Enjoy! Gene Wright -- * These statements and opinions are mine alone and do not reflect my employer's views. * GREAT idea !! "Gene Wright" <genewright143@hotma...

49g grayscale games on 49g+
Did anyone try to run 49g grayscale games (like Treize, Dune, Columns+) on the 49g+? On my calculator these three seem to run, but they flicker and set the lcd display to an almost unreadably dim state. And they don't allow me to modify the contrast. Is there a way to run these (and other) games normally? Thanks: Peter Juhasz I believe the flickering problem is fixed in ROM 1.23 -dave <peti314@ludens.elte.hu> wrote in message news:g8eHsizUNuab@ludens... > Did anyone try to run 49g grayscale games (like Treize, Dune, Columns+) > on the 49g+? > > On my calculator these three seem to run, but they flicker and set the lcd > display to an almost unreadably dim state. > And they don't allow me to modify the contrast. > > Is there a way to run these (and other) games normally? > > Thanks: Peter Juhasz > "rue_stir13" <nojunk13@hotmail.com> wrote in message news:fKU_b.2317$tX.302@newssvr27.news.prodigy.com... > I believe the flickering problem is fixed in ROM 1.23 > But that is not the case for greyscale flickering. I wonder if it has to do with the way the screen is refreshed and if we can ever do something about it: maybe it is HW related. Arnaud > > I believe the flickering problem is fixed in ROM 1.23 > > > But that is not the case for greyscale flickering. I wonder if it has to do > with the way the screen is refreshed and if we can ever do something about > it: maybe it...

SysRPL differences between 49g and 49g+
Does they have any difference, for example different entries , etc. I have programs developed to the HP48GX in system. I migrate them to 49G with little changes in the code and recompiling it. Can I think that the changes to migrate the 49g+ will be so easy Where can i find information about SysRPL programing to the 49g+, entries archives, etc. Thank you in advance Maurizio Faccio Maurizio Faccio wrote: > Does they have any difference, for example different entries , etc. > I have programs developed to the HP48GX in system. I migrate them to > 49G with little changes in the code a...

Web resources about - Installing latest 49g+/50g (emulator) ROM on a 49G - comp.sys.hp48

Help:Installing Japanese character sets - Wikipedia, the free encyclopedia
This help page will help you install Japanese character sets so that your computer will display them properly on the internet in your web browser ...

Earn Free Facebook Credits For Installing Apps — Of Course, There’s A Catch
This looks pretty cool at first: Earn free Facebook Credits for installing applications on your iPhone or Android device. AppDog offers this ...

Rooting and installing Android 1.5 JesusFreke - Flickr - Photo Sharing!
More information at: android.noisepages.com/2009/05/rooting-pics/

Installing ClearCal Anti-Glare Film for Glossy Displays - YouTube
Demonstration of how to install a RadTech ClearCal Anti-Glare Film on a MacBook Pro. ClearCal eliminates glare on glossy displays like Apple's ...

Fatal unit fire: Builder Ray Finianos reduced height of building to avoid installing fire sprinklers ...
The builder of&nbsp;a south-west Sydney unit block where a young woman plunged to her death during a ferocious fire told a certifier to reduce ...

'Green' light bulb moment for councils installing LED street lights
Nine Sydney councils are getting ready to turn off the lights &ndash; 13,000 of them &ndash; to save more than $20 million.

Iran installing new nuclear equipment
Sky News is Australia's leader in 24-hour news. Iran has begun installing next-generation equipment at one of its main nuclear plants, a new ...

Peter Garrett believed installing insulation batts 'not that hard', royal commission told
Former environment minister Peter Garrett believed installing insulation batts was ''not that hard'' based on his own personal experience, an ...

Gillard defends installing Slipper
BBC News Gillard defends installing Slipper Sydney Morning Herald Prime Minister Julia Gillard has defended her decision to install Peter ...

CSIRO says installing solar panels on roofs of businesses could take pressure off the electricity grid ...
Installing more solar panels on the roofs of businesses would help Australia's energy grid cope with increased demand.

Resources last updated: 3/10/2016 4:07:11 PM