Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Last 5 nibs in RAM

8 views
Skip to first unread message

Joe Horn

unread,
Feb 14, 2006, 1:00:58 PM2/14/06
to
What is the meaning/purpose of the final 5 nibbles in RAM (hex
addresses FFFFB-FFFFF)?

They seem to stay the same, even through a Memory Clear, but if poked
with another value, everything seems to keep working just fine. The
only way I've seen the machine change their value is by leaving all the
batteries out overnight.

I've checked three 49g+'s and one 49g, and all have different "default"
values... but apparently unrelated to the serial number.

Anybody know? (Sorry if this is an old topic; I searched but didn't
find where it's discussed).

-Joe-

Jean-Yves Avenard

unread,
Feb 14, 2006, 2:30:48 PM2/14/06
to
Joe Horn wrote:
> What is the meaning/purpose of the final 5 nibbles in RAM (hex
> addresses FFFFB-FFFFF)?

I don't think they have any.

RAM is defined to stop in FFFFB

JY

Charles M. Patton

unread,
Feb 16, 2006, 1:20:35 PM2/16/06
to
Jean-Yves Avenard wrote:

As I recall, I needed a safe base marker location on which to base the
recursive routine to reconstruct memeory in "recover ram". I believe it
only gets used (and initialized) there.

CP

John H Meyers

unread,
Feb 16, 2006, 3:09:35 PM2/16/06
to
On Thu, 16 Feb 2006 12:20:35 -0600, Charles M. Patton...

That's Charlie Patton of the original HP48 team,
who wrote the original "recover memory," and so much more:
see http://www.hpcalc.org/hp48/docs/faq/48faq-4.html#ss4.2
and "Recover.doc" in http://www.hpcalc.org/details.php?id=240 [GD#9]

> As I recall, I needed a safe base marker location

> on which to base the recursive routine to reconstruct memory


> in "recover ram". I believe it only gets used (and initialized) there.

As I recall, my HP48G/GX could be counted on to "recover memory"
very reliably -- in fact, I would periodically force that to occur with
ON+A+F Yes, just to ascertain that no memory corruption had occurred,
and after a successful, complete recovery, only variables
having null names ("hider" variables and the "hidden directory")
would be found eliminated or re-initialized.

I have never yet seen my 49G perform the same feat, however;
occasionally it will recover several fragments
(directories named 'D.nn') or (more often) never complete
(I've been very patient on my emulator,
where the batteries never run down :)

Inasmuch as "recover memory" is not a normal, everyday task,
however, and that we now have lots of extra RAM ports
and flash in which to store backups,
plus more universal PC connectivity,
it's never mattered much to me that the 49G doesn't seem
to do that once vital task as well as the 48 series --
the good old 48 series had major surgery
to turn it into the 49 series,
and things were both gained and lost in the process.

Not long ago, the first ROM version I used in my 49G+
produced a corrupted copied file whenever the first object in HOME
was copied to flash -- I wonder whether that related to
bumping into the "end of memory," as JKH seems to have noted:
http://groups.google.com/group/comp.sys.hp48/msg/ca4c9bd060c887da

Thanks very much, CMP, for your major contributions to HP calculators,
and for still taking interest in what they have evolved [?] into.

[r->] [OFF]

Message has been deleted

Jean-Yves Avenard

unread,
Feb 16, 2006, 6:47:15 PM2/16/06
to
John H Meyers wrote:
> Not long ago, the first ROM version I used in my 49G+
> produced a corrupted copied file whenever the first object in HOME
> was copied to flash -- I wonder whether that related to
> bumping into the "end of memory," as JKH seems to have noted:
> http://groups.google.com/group/comp.sys.hp48/msg/ca4c9bd060c887da
It's not that.

The offset inside the backup was incorrectly calculated.
Something was added in version 2.0 to make sure that all files stored in
Flash would be at a 16bits address.
So the size of the backup copied didn't record the right size.

JY

0 new messages