Bug in ROM 2.14 regarding Port 2
Jacob Wall
Today I visited hpcalc.org and noticed ROM 2.14 was just added, so of
course I had to download it and install it. The update itself went
smoothly, but then when I tried to install EqnData.lib the problem
appeared. The calculator just hung there for a really long time so I
reset it. The EqnLib.lib (~11KB) worked just fine so I tried the
EqnData.lib (~58KB) again, same problem again, then I noticed that the
File Manager now showed only 7KB available in Port 2, and some of my
libraries that I had installed in Port 2 where gone. Weird, then
further all of a sudden when pressing the ON key, the calculator would
warmstart, this eventually went away, no idea what the deal was
there.
Anyways so I PURGEd extable from Port 2 to free some space to test
further. I then tried to install another library, ~47KB in size, same
procedure as always, RCL library to stack, put 2. on stack, press STO,
well now the entire screen flickered and the hourglass was on, this
time I just put it aside and let it flicker, eventually it stopped,
now I checked and the file manager shows 0KB available for Port 2, and
NO ENTRIES. So at this point it appears to me that when installing
larger libraries, something goes very wrong, as the smaller EqnLib.lib
installed just fine.
Ok, that was on my backup 49g+, should have known to stop there but
curiosity prevailed and I got out the 50g. Surprise surprise, same
problem, however with a new twist, during a trial STO to port 2, the
Display Area 2 and 3 pixels turned on (black) while Display Area 1
pixels were off. After resetting the calculator, nothing changes,
partially black screen is all I see.
So now I have a 49g+ with a missing Port 2, and a 50g with a black
screen when I turn it on.
PINIT does nothing, the same library installs fine to Port 1, what is
going on?
Anyone else experience the same problem? I suggest DO NOT INSTALL ROM
2.14, but maybe its just my 2 calculators out of all of them.
Also when pressing any 2 keys on the 49g+ simultaneously the
calculator just warmstarts now, so I have not been able to revert to
ROM 2.09 but will keep trying.
Jacob
Jacob Wall
screen, everything works again regarding Port 2, however there's only
196KB available, where previously I had about 550KB or something like
that.
Dale and Cyndie Richmond
Thanks for the warning regarding the ROM upgrade!!!
Dale R
"Jacob Wall" <j8w...@hotmail.com> wrote in message
news:6782c044-1143-40fe...@x29g2000prf.googlegroups.com...
timwe...@gmail.com
> course I had to download it and install it. The update itself went
> smoothly, but then when I tried to install EqnData.lib the problem
> appeared. The calculator just hung there for a really long time so I
> reset it. The EqnLib.lib (~11KB) worked just fine so I tried the
> EqnData.lib (~58KB) again, same problem again, then I noticed that the
> File Manager now showed only 7KB available in Port 2, and some of my
> libraries that I had installed in Port 2 where gone. Weird, then
> further all of a sudden when pressing the ON key, the calculator would
> warmstart, this eventually went away, no idea what the deal was
> there.
Strange. It works perfectly on my systems here (3 at least so far).
What rom were you running before the upgrade?
I have seen ROM updates go strange before. I fixed it by installing
one of those 2MB roms that wipes all of port 2 clean. Try using the
2MB -u rom in the zip file here: ftp://ftp-fourier.ujf-grenoble.fr/xcas/hpcas/hp49g.zip
TW
Jacob Wall
Tim, good to hear it's working for you, very bizarre that it messed up
both of my calculators. I upgraded from ROM 2.09, on both
calculators. I'll try the -u ROM, thanks for the link.
Jacob
Veli-Pekka Nousiainen
viestissä:b5a975dc-29ee-4d16...@p2g2000prf.googlegroups.com...
After wipe-out do you dare to try again
Since you are already experimenting
just continue, please
We will all benefit
I may want to wait for HPGCC 3.0 support ROM...
Khanh-Dang
> Today I visited hpcalc.org and noticed ROM 2.14 was just added
Great news. My HP50 is only 2.09. But I don't feel upgrading it if I
don't know what the improvements are. I wish there were a changelog
file in the .zip archive...
Jacob Wall
get the 49g+ to not warmstart when I press 2 keys simultaneously,
which is sort of a requirement for the upgrade ( + and - ).
So after "fixing" the 50g with the -u ROM, I then installed ROM 2.14
again. Of course the problem I'm having is storing libraries in Port
2, so instead I tried using the File Manager, browsing the SD,
locating the library, and copying it directly to Port 2. Amazingly
enough it worked just as expected, however when I do the RCL library
from SD, 2. STO, the calculator just hangs indefinitely, ON+C, results
in "Try To Recover Memory?" screen. Has STO been revised?
Tim, are you able to put a library on the Stack, then performing 2.
STO on the calculators you have upgraded? Also from my trials it
appears that STO only fails with larger libraries, EqnLib.lib at 11308
Bytes works fine, but EqnData.lib does not work for me, neither does
my ~47KB library.
Jacob
Veli-Pekka Nousiainen
"Jacob Wall" <j8w...@hotmail.com> kirjoitti
viestissä:0f54e41b-7c5b-4dc9...@d36g2000prf.googlegroups.com...
> The -u ROM worked like a charm on the 50g, thanks Tim, still unable to
> get the 49g+ to not warmstart when I press 2 keys simultaneously,
> which is sort of a requirement for the upgrade ( + and - ).
>
> So after "fixing" the 50g with the -u ROM, I then installed ROM 2.14
> again. Of course the problem I'm having is storing libraries in Port
> 2, so instead I tried using the File Manager, browsing the SD,
> locating the library, and copying it directly to Port 2. Amazingly
> enough it worked just as expected, however when I do the RCL library
> from SD, 2. STO, the calculator just hangs indefinitely, ON+C, results
> in "Try To Recover Memory?" screen. Has STO been revised?
#"#/&(&/¤%¤&%¤
seems to be a buggy release
unless others test it will dissimilar experience
Where are all the Beta-testers?
I used to be one...but no one asked me now ???
Khanh-Dang
> seems to be a buggy release
> unless others test it will dissimilar experience
I successfully installed 2.14 on my hp50g.
I found a "13. StreamSmart" entry in the APPS menu...
Jacob Wall
essentially the same thing as what I'm doing on the calculator, it
works. For example in UserRPL:
<< :2:226. PURGE :3:EQNLIB.LIB RCL 2. STO >>
This works for me when I run it from the SD, but not if it's stored on
the calculator.
timwe...@gmail.com
> STO on the calculators you have upgraded? Also from my trials it
> appears that STO only fails with larger libraries, EqnLib.lib at 11308
> Bytes works fine, but EqnData.lib does not work for me, neither does
> my ~47KB library.
That works fine here. My testing consists of installing and running
the surveying software which is about as stressful a test there is,
being how it uses calls from all sides of the system and also HPGCC
stuff. Nothing is funny on what I've seen.
TW
timwe...@gmail.com
> I used to be one...but no one asked me now ???
Perhaps its comments like that, and general randomness, that gets one
disqualified?
TW
Jacob Wall
Odd, well as I stated earlier when running the
<< :2:226. PURGE :3:EQNLIB.LIB RCL 2. STO >>
from the SD everything works fine, just not when running it from on
the calculator. Tim, I would imagine you have everything streamlined
with your installations, and are not entering each time 2. STO to
store a library to Port 2. Have you or anyone else tried installing
the new EqnLib.lib file using the method I was using? Would like a
confirmation as to whether the issue is on all calculators, or only on
some, or if there's something specific that triggers it.
After some more trials I decided to press ON+C after what I thought
was roughly the right time that it should take to perform the job, and
well, the library had installed correctly, but when I don't interrupt,
the hourglass remains on and something is happening that eventually
wipes out or corrupts Port 2 completely.
I know what triggers the problem on my calculators and I now have both
my 49g+ and 50g back to the state they were in before this oddity,
although I did keep ROM 2.14 on both calculators for now anyways, I
just have to remember not to do the 2. STO thing.
Jacob
Veli-Pekka Nousiainen
viestissä:59270d4a-5f56-438c...@y13g2000yqn.googlegroups.com...
Comments like what?
While you care to write, please also educate:
Please analyze what is wrong with my comment above.
Thank you!
------------------------------
What general randomness?
Writing to a newsgroup differs from testing.
I think your business depends on understanding the difference.
My claim is that style of writing in a newsgroup
does not necessarily reflect testing skills
If my writing annoys some people,
so do other writings also annoy people (including me)
timwe...@gmail.com
> store a library to Port 2. Have you or anyone else tried installing
> the new EqnLib.lib file using the method I was using?
Ok. I did get it to hang. The program to install it works just fine
for me whether run from the SD card or in the calculator, but a manual
STO on the stack does seem to hang. However, only on one of my units
(the empty one). The others that have about 500kb in port 2 had no
problem. Strange.
TW
Jacob Wall
Hey, I believe I have found the problem. I completely wiped out my 49G
+, factory settings, except RPN mode set and the 2. STO worked!!!!
So I went down the list of flags, matching it to my 50g, and the
problem seems to be dependent on Flag 40 Show Clock, If flag 40 is
set, my calculators hang everytime, however when I clear flag 40, no
problems. Weird.
Jacob
Veli-Pekka Nousiainen
So I'll wait for the next ROM to be released
where this bug is fixed
It should be easy to locate now
that you have found that flag -40 is involved
Thanks!
VPN
PS: Since your comments are always so perfect
you should be a beta-tester
=> one more pair of eyes to find those nasty bugs that creep in...
"Jacob Wall" <j8w...@hotmail.com> kirjoitti
viestissä:c461dfd8-1e47-4262...@w1g2000prk.googlegroups.com...
timwe...@gmail.com
> +, factory settings, except RPN mode set and the 2. STO worked!!!!
My clock was off all the time. :-(
TW
schlie
in various combination with normal numbers, complex numbers, #based-
numbers, symbols/characters, exact rational results, and textbook
equations on the stack; as I don't recall the odd results I'm now
seeing. Normal numbers now seems to be tied to checking
EqW:small_stack_disp while others like #based-numbers, and char/
symbols seem to be tied to stack:small?
adr.ra...@gmail.com
No problems sofar, clock not displayed.
John H Meyers
> Today I visited hpcalc.org and noticed ROM 2.14 was just added
To echo Bill Graves, it's invisible from here, as of right now,
neither in http://www.hpcalc.org/hp49/pc/rom/
nor in the "additions" section.
http://www.hpcalc.org/search.php?query=2.14 is also not very productive.
Is there a Cheshire cat in the house?
[r->] [OFF]
Patrick Legrand
release.
works fine, except a
:2:bkup archive
blew pretty spectacularly. can easily be repeated.
fortunately I had a backup on SD...
My 49G+ has a SN of 51505372
> http://www.hpcalc.org/search.php?query=2.14 is also not very productive.
today I learn that tis release got renamed to BETA.
Hopefully it gets fixed soon, otherwise I have to go back to 2.09 in the
meantime
All the best
Patrick
schlie
Strange, not me: (in R= mode)
If I place 0 'X' #1h x^3 on the stack, then set:
only Stack:Small => everything small, as expected.
add Stack:Textbook => 0 and x^3 both become enlarged?
add EqN:Small_Stack_Disp => everything small again?
del Stack:Textbook => everything still small, as expected.
del Stack:Small => everything large, as expected.
add Stack:Textbook => 0 and x^3 become small, 'X' and #1h remain
large?
This is very strange.
I expect:
Stack:Textbook => to enable display of Textbook EqW's on stack.
Stack:Small => everything on the stack small, except Textbook EqW's.
EqW:Small_Stack_Disp => make TextBook EqW's on stack small.
EqW:Small => make edit display of TextBook EqW's small.
(this is no longer the case, as I recalled it had been)
schlie
meant exclusively to control the size of Textbook EqW's.
(regardless of clock display it seems)
pleased...@isp.com
Nothing to do with the clock, or flags. Flash banks have been
renumbered. The odd behavior described throughout this thread is
consistent with symptoms that could happen as side effects of this.
You need to flash that "-u" rom, but use a hex editor to increase by
one the flash bank number that's at offset 0x101 at all user flash
banks, starting from bank 8 and up. Do that for all user banks and
flash it. Then flash 2.14 and it should work fine.
The best would be to generate a new rom image with the full flash,
similar to the "-u" rom but with the proper bank numbers for rom 2.14.
Of course, if you want to go back to 2.09, you need to do a full
reflash with an older '-u' rom in order to restore the original
numbering scheme.
So, it's not a bug in the rom, just a "new feature" that should've
been documented before release. It is unfortunate that this rom was
released (perhaps accidentally?) without a full flash image and a big
warning for all users.
This new feature should also break compatibility with the ARMToolbox
and therefore all HPGCC 2.0 programs (anyone cares to test this?). And
FlashTools will most likely get very confused by the new numbering
scheme, so don't use with this rom (you've been warned).
Claudio
andreas_mo...@gmx.de
> This new feature should also break compatibility with the ARMToolbox
> and therefore all HPGCC 2.0 programs (anyone cares to test this?). And
> FlashTools will most likely get very confused by the new numbering
> scheme, so don't use with this rom (you've been warned).
A lot more programs will be affected if they really release a ROM with
renumbered FlashBanks.
Maybe we might get an explanation for this but IMHO they should keep
compatibility with the old numbering even if this would mean that they
would have to take away another FlashBank for the user.
What does the user community gains if they break compatibility with a
lot of already existing programs ?
Regards,
Andreas
http://www.software49g.gmxhome.de
pleased...@isp.com
On Mar 16, 6:40 pm, andreas_moellerNOS...@gmx.de wrote:
> A lot more programs will be affected if they really release a ROM with
> renumbered FlashBanks.
I'm not sure that would be the case. I'd say only programs doing very
low-level management of flash memory will break. Most programs should
work without a problem using the API provided by the calculator. The
ones I mentioned are simply because I wrote them and I know they'll
have trouble. I'm not aware of any other programs out there that
access flash banks at such low level. It's a bad practice, though
necessary in very rare cases like ARMToolbox and FlashTools for
obvious reasons.
Are there really that many programs dealing with flash memory banks
out there?
Claudio
timwe...@gmail.com
> necessary in very rare cases like ARMToolbox and FlashTools for
> obvious reasons.
I know for certaain that the arm toolbox works fine, as well as HPGCC
code. At least it did here.
It looks after poking around in there that the streamsmart software
has been placed in the area where the 49G bootloader was located
previously (and hence Gaak's picture viewer didn't work). There also
appears to be some additional stuff that almost looks like ARM code in
there as well. Either way, it appears that the 49G support is, or will
be, no more. Considering how JYA was always saying the ROM was
completely full in most banks, that doesn't surprise me.
TW
Veli-Pekka Nousiainen
viestissä:84e7cced-74ae-4f31...@j8g2000yql.googlegroups.com...
I will not mind if one more bank goes to new features
OR
perhaps HP releases new features as libraries?
--
VPN
pleased...@isp.com
If the Toolbox works, then my theory is simply wrong. Flash banks must
then have the correct numbering scheme. There must be a real bug in
there, then. I just wanted to believe that wasn't the case, but...
Claudio
JYA
On 2009-03-16 08:57:54 +1100, Jacob Wall <j8w...@hotmail.com> said:
> reset it. The EqnLib.lib (~11KB) worked just fine so I tried the
> EqnData.lib (~58KB) again, same problem again, then I noticed that the
> File Manager now showed only 7KB available in Port 2, and some of my
> libraries that I had installed in Port 2 where gone. Weird, then
> further all of a sudden when pressing the ON key, the calculator would
> warmstart, this eventually went away, no idea what the deal was
> there.
Looks like someone forgot to check that entry points didn't move ...
Jean-Yves
John H Meyers
If the entire "supported" OS entry points list is not eternally
"frozen" in all ROM versions for a given calculator series,
then all third party software (and even official HP add-on software)
is at risk of failing (with possible memory corruption or wipeout),
when used with any non-complying ROMs.
Many of the "supported" entries are in tables (or are ROMPTRs
or FLASHPTRs), which are easiest to maintain without change,
but there are also regions of memory which remained unchanged
since even the HP48[S/G][X/+] series, and these very basic
functions must also be "frozen" in the exact same positions,
to make it safe to use all existing separate SysRPL/ML software
(and even UserRPL if, heaven forbid, any of those entries moved).
Major issue here, so take care.
---
JYA was one of the key developers and project managers for HP's
HP49G/49G+/50G and other series of calculators, which are in part
based on JYA's "Metakernel," and other HP projects
(one or two newcomers may not have heard this :)
Then he and Ray Suryn (and...) went on to found a more innovative company
( http://www.hydrix.com ) while HP remained stuck in the mud :)
"If you are holding a leading-brand high-end graphing calculator
anywhere in the world, it is highly likely
that some Hydrix software and design resides in that product"
http://www3.hydrix.com/service/index.php?id=33
--
schlie
> Many of the "supported" entries are in tables (or are ROMPTRs
> or FLASHPTRs), which are easiest to maintain without change,
- presumably why they're indirectly accessed through such tables.
> but there are also regions of memory which remained unchanged
> since even the HP48[S/G][X/+] series, and these very basic
> functions must also be "frozen" in the exact same positions,
- doesn't seem practical, nor should likely be expected. As such
entry points are most typically inherently specific to an particular
implementation, and obviously not intended to used as fixed API
entries.
> to make it safe to use all existing separate SysRPL/ML software
> (and even UserRPL if, heaven forbid, any of those entries moved).
- which will itself need to be updated with what ever non-portable
entry points it may have been used. (although do agree that if it
were easy to maintain these otherwise non-portable entry points
while still being able to refine the implementation as may be
desired,
it makes sense to do so)
> Major issue here, so take care.
(Overall, I don't believe it makes sense to limit HP's ability to
refine
their implementation, in order to preserve entries obviously never
meant to be officially supported. Especially as any SW using such
entries may itself be updated without limiting HP's ability to update
theirs.) IMHO.
John H Meyers
JHM:
>> there are also regions of memory which remained unchanged
>> since even the HP48[S/G][X/+] series, and these very basic
>> functions must also be "frozen" in the exact same positions,
> doesn't seem practical, nor should likely be expected.
> As such entry points are most typically inherently specific
> to a particular implementation, and obviously not intended
> to used as fixed API entries.
But they are in fact so intended, and always have been.
> Overall, I don't believe it makes sense to limit HP's ability
> to refine their implementation, in order to preserve entries
> obviously never meant to be officially supported.
But they are in fact meant to be officially supported,
and always have been. The very existence of a huge base
of third party software heavily depends upon it.
You can not even compile a SysRPL or assembly language program
which uses symbols for the standard operating system functions,
without using a permanent symbol table library which defines
the unchanging values for all of those symbols.
Anyone who wants to chuck it all, however,
and start over with re-developing everything in "C"
need not mind, and may go ahead with updating ROM
to any version which no longer supports the original OS
(if this is in fact what happened, and wasn't by mistake).
When just arriving on the scene, one may think that the basic
design should have been based on a purely "interpreted" system,
but it is in fact based on creating the most efficient possible
system, in terms of execution time, using modest hardware,
in terms of a specially designed original processor.
Every object which the calculator can "interpret" even begins with
the 20-bit actual memory address of the ROM code which interprets it,
and if any of those were to move, "the game would really be over" :)
Even those basic addresses are intimately bound
to the instruction opcodes of the original processor,
for reasons of "indirect execution," which can be understood
only by a thorough acquaintance with the original design concepts,
some of which may be found here:
RPLMan from Goodies Disk 4
http://www.hpcalc.org/details.php?id=1743
RPLMan in PDF format
http://www.hpcalc.org/details.php?id=1745
HP 48 Goodies Disk, Vol. 4 (with additional documents)
http://www.hpcalc.org/details.php?id=235
So what has been stated just happens to be true,
and is just one more thing to be accepted
about the fundamental underpinnings of this series of calculators.
The principles which you espouse may, however,
be profitably applied to the next series, if any,
now that technology has so much changed in the intervening 20 years,
and the new series need no longer be compatible with the old.
[r->] [OFF]
schlie
>
> HP 48 Goodies Disk, Vol. 4 (with additional documents)http://www.hpcalc.org/details.php?id=235
>
> So what has been stated just happens to be true,
> and is just one more thing to be accepted
> about the fundamental underpinnings of this series of calculators.
>
> The principles which you espouse may, however,
> be profitably applied to the next series, if any,
> now that technology has so much changed in the intervening 20 years,
> and the new series need no longer be compatible with the old.
>
> [r->] [OFF]
I presume you're referring to the use of mapping file ENTRIES.A?
(which unless I misunderstand, need only be updated to reflect any
newly defined mappings, and then recompiled/assemble any
correspondingly dependent programs; if the mappings were necessary to
modify for some hopefully good reason).
It seems, presuming one has access to a program's source code.
John H Meyers
> I presume you're referring to the use of mapping file ENTRIES.A?
http://www.hpcalc.org/details.php?id=3245
> (which unless I misunderstand, need only be updated to reflect
> any newly defined mappings, and then recompiled/assemble any
> correspondingly dependent programs; if the mappings were necessary
> to modify for some hopefully good reason).
> It seems, presuming one has access to a program's source code.
One does NOT have source code for many programs and libraries
(recompiling libraries is also much more effort than simpler program files),
and even if one did, this would put the obligation upon every user
to re-compile every program and library for himself,
which is commonly called a PITA,
as well as having to decide whether or not it is safe to use
any program or library ever posted in binary form.
If the 2000 or so "supported" OS functions were to remain in existence at all,
the sensible thing to do would be to maintain their current binary values,
and to add any new functions via brand new entries.
Besides this, the fact is that binary programs are exchanged
between calculators all the time, or conveyed on SD cards, etc.
The only safeguard against inadvertently installing a program
that is incompatible with one's current ROM version
is a "series header" which permits free interchange of all binaries
for an entire calculator series, and rejects all others.
This is how, for example, the original HP48[S/G][X/+] series
all freely interchange binary program files,
and the HP49G/49G+/50G/48Gii series does likewise,
but the two incompatible series can not accidentally
exchange binary programs with each other,
which otherwise could readily crash them,
and/or wipe out everything that a user has stored.
One could of course change the series header, to create a new series,
and then the entire archive of existing software for the latter series
becomes invalid, just as the entire archive of the former series
was invalid for transfer to the latter series,
requiring "porting" of every existing older program and library.
Apparently this has not yet been done, or else no one would have been
able to accidentally crash a calculator flashed with this new ROM
by trying to use any other existing software.
The point of these last few notes of mine has been to
elaborate and "display a caution flag" on the racetrack,
for whoever didn't catch the significance of JYA's
one-sentence remark, which if accurate means that
people should not rush out and install the new ROM,
before learning what the outcome might be,
or whether it simply has a serious "bug" that might get fixed,
or else it might cause them some trouble.
It's not hard to go back and re-flash a former ROM,
but it isn't always as easy to recover one's lost entire user memory,
if one has not taken the precaution to always keep it backed up.
If one also has to sacrifice any more flash banks,
converting them from "user" to "system" banks
(I have not followed whether one does, but just in case),
it would be a good idea to first provide a program
to recover anything already stored there,
just as was provided on a previous such occasion, by JYA,
and included with the first ROM update that required it.
I do not know exactly what was meant or not meant to be changed,
but at least I know to wait for more information,
before installing any new ROM, which is primarily
for a feature which I never use anyway,
and probably does not improve any existing feature.
"If it ain't broke, don't rush to fix it" :)
[r->] [OFF]
JYA
On 2009-03-20 09:01:49 +1100, "John H Meyers" <jhme...@nomail.invalid> said:
>
> If the entire "supported" OS entry points list is not eternally
> "frozen" in all ROM versions for a given calculator series,
> then all third party software (and even official HP add-on software)
> is at risk of failing (with possible memory corruption or wipeout),
> when used with any non-complying ROMs.
There are plenty of entry points located in areas that aren't stable.
Change one line of code and entry points will shift.
In my experience, with the current state of the ROM that is so full, if
you quickly modify code to fix something, it could take hours to
reorganise the ROM to make sure no entry point would move.
A big portion of the supported entry points is located in an area that
can't move (they use a jump table) but there are plenty that do move
unfortunately.
>
> Many of the "supported" entries are in tables (or are ROMPTRs
> or FLASHPTRs), which are easiest to maintain without change,
> but there are also regions of memory which remained unchanged
> since even the HP48[S/G][X/+] series, and these very basic
> functions must also be "frozen" in the exact same positions,
Unfortunately, not all code can be moved to using flashptr because it
wouldn't work in covered memory...
>
> "If you are holding a leading-brand high-end graphing calculator
> anywhere in the world, it is highly likely
> that some Hydrix software and design resides in that product"
> http://www3.hydrix.com/service/index.php?id=33
>
> --
Unfortunately, I had nothing to do with the latest ROMs, I would have
loved to help. But for that I would need to be asked :)
I only discovered new ROMs were released by checking this newsgroup
Looking at some bugs reporting on the HP40 new ROM, it looks like they
didn't use my latest code base :(
Jean-Yves
--
They who would give up an essential liberty for temporary security,
deserve neither liberty or security (Benjamin Franklin)
John H Meyers
> I only discovered new ROMs were released by checking this newsgroup.
> Looking at some bugs reporting on the HP40 new ROM,
> it looks like they didn't use my latest code base :(
One might feel like someone re-visiting New Orleans after Katrina,
and finding no old neighborhood (or neighbors) present.
I have one more comment, for "schlie" and anyone else not quite
perceiving the relationship of past, present and future developments,
from a perspective of any longer term experience.
If the calculator series were to undergo a metamorphosis,
in which HPGCC execution is built in and more accessible,
but in a manner somewhat like the evolution of the HP48[S/G][X/+]
series into the HP49G/49G+/50G/48Gii series, involving
a significant reorganization of ROM, then it might be best
to consider the new version a new calculator series
(e.g. with a binary object header "HPHP50-x" in place of "HPHP49-x"),
so that incompatible binary programs and libraries
could not accidentally be interchanged,
and start to build a new, independent line of software for it.
If a series of new ROM versions were not at least to stabilize
its own series of "supported" fixed entries and functions, however,
then the result would be chaotic, with no two ROM versions
being able to host common binary programs and libraries,
unless they were perhaps all written afresh,
using only new OS features whose "hooks" into the OS do not change.
There are some computer operating systems which can themselves
host other operating systems, however, so if much more flash memory
(for ROM) were to be added, and the clock speed boosted,
perhaps one could run all three calculator series at the same time,
in the same box, under emulation for the Saturn-based series.
With this much change, however, you might as well add a few more things
and call it a "phone/hPod/calculator/computer" or whatever new all-in-one name.
I think I'll dig out my old pair of Intermec WinCE machines,
which run CG's Emu48 and can be either an HP48 or HP49/50;
maybe a bit retro, but it runs all the software on www.hpcalc.org,
and fits into a shirt pocket at the same time :)
Come to think of it, I also picked them up for only about US$15 each.
[r->] [OFF]
schlie
I understand and respect your desire that all existing sw remain
compatible with previous rom versions regardless of which entry points
may have been used; however simply don't believe that inhibiting the
practical ability to implement rom improvements, especially when such
sw may be re-complied/assembled to remain compatible, is sensible. As
just my opinion, nothing more.
(Just as the use of inherently non-portable physical entry points
within OS kernels, etc. may not warranted to remain stable from
release to release; and thereby why some sw is dependent on a
particular version of OS implementation; although it's host hw remains
the same; as I'm sure you know, although also wish otherwise.)
Obviously in a perfect world, everything remains fully backward
compatible; however in a practical world, this may often only be
achieved within some bounds of reason, dependent upon what one is
willing to sacrifice.
I'm admittedly not qualified to make this delicate judgment, although
suspect/hope others may be.
John H Meyers
> I understand and respect your desire that all existing sw remain
> compatible with previous rom versions...
You may misunderstand me; I am pointing out what others need to know,
and certain precautions and decisions which need to be made,
as well as correcting blind assertions such as
"obviously not intended to used as fixed API entries"
and "obviously never meant to be officially supported,"
which can only be made by someone who doesn't know
the entire history and current situation of the product,
and of all the third-party software which exists for it.
> I simply don't believe that inhibiting the practical ability
> to implement rom improvements, especially when such
> sw may be re-complied/assembled to remain compatible, is sensible.
It has twenty years of sense behind it, backed by
two consecutive generations of actual HP developers and management.
In addition, you have no idea
of how much or how little may be required -- it appears that
you imagine a situation more like that of the original HP48 series,
where the entry points were scattered all over ROM,
and where it was much more difficult to work around them,
whereas currently, the fixed area of which I spoke,
which constitutes a "core" group of fundamental functions
which really never change, nor need to,
is concentrated into a compact area of lower memory,
while the greater number of "supported" entries
were cleverly moved (by JYA) into tables,
where they are mapped indirectly into jumps to
other areas which now can freely move.
For all I know, any current "slip" may simply have been
an oversight, a mistake which can be corrected,
but that's up to someone else to determine,
neither you nor me -- I just point out what may not be known
to casual users or readers here, so that they may better understand
the meaning of what's been noted in this thread,
and the potential implications of rushing off and updating
their ROM, just in case it may interfere with what they
normally depend on, which may be the use of existing other software.
> As just my opinion, nothing more.
> I'm admittedly not qualified to make this delicate judgment.
You came on "like gang busters," however, asserting that you did know
("obviously never meant to be officially supported"), rather than
phrasing your remarks as questions, seeking information,
which would be less likely to confuse others
to whom the issues are not obvious.
> although suspect/hope others may be
Have you noticed anyone who seems to be well informed,
from whom you might pick up some useful background information,
and have you been offered any references where you can go to get more of it?
JYA certainly knows all about everything, having written
major independent OS enhancements way back in HP48 series days,
and then having been a primary developer of the HP49/50 series,
which now embeds those very same enhancements,
and at the same time has remained a stable platform
for the development of a large body of useful software,
which may be an important element to the marketability of the product,
so at least there's one person to whom you might pay attention
(had he time to write at length, but he has a company to run).
Seeing this little matter of small significance play out,
it may be no surprise that "revolutions" replacing long-established
governments do not always produce sparkling and spectacular
immediate improvements to the life of the people,
for their discontinuity of history abandons whatever of the past
was of value, as well as what was not, and sometimes simply repeats
the same poor course that they thought they would correct.
[r->] [OFF]
schlie
> "obviously not intended to used as fixed API entries"
> and "obviously never meant to be officially supported,"
> which can only be made by someone who doesn't know
> the entire history and current situation of the product,
> and of all the third-party software which exists for it.
JYA wrote:
> There are plenty of entry points located in areas that
> aren't stable. Change one line of code and entry points
> will shift.
>
> In my experience, with the current state of the ROM that
> is so full, if you quickly modify code to fix something, it
> could take hours to reorganise the ROM to make sure no
> entry point would move.
>
> A big portion of the supported entry points is located in
> an area that can't move (they use a jump table) but there
> are plenty that do move unfortunately.
Obviously entry points which are an inherent artifact of a
particular implementation, are only preservable as long as
it's underlying code base coincidently, or may be artificially
massaged to, preserve its prior apparent form. Anyone with
any lower level sw experience, knows this implicitly; and
correspondingly knows use of such entry points are at best
risky; and all risks have have worst case consequences.
(Sometimes one can't have their cake and eat it too.)
Please try to temper your emotion.
schlie
firmware to be improved in both functionality and ease of use to
everyone's benefit.
If I've inhibited this process, I apologize to all.
Jacob Wall
Well after roughly a week of moderate use of the much beloved 50g with
ROM 2.14, I have had no other issues other than the initial hiccup
with Port 2. I have cleared flag 40, which still without fail
triggers the initial problems and never triggers them if said flag is
cleared, not sure if I actually used the time anyways... So, other
than the strange behavior I experienced right off the get go, has
anyone had any other real issues?
Jacob
schlie
small_stack_disp of textbook equations, which renders the exclusive
display of small formatted equations, with otherwise normal display of
values, symbols, etc.; incapable of being achieved. (but haven't yet
identified other apparent problems, or improvements).
JYA
On 2009-03-21 06:27:57 +1100, schlie <sch...@comcast.net> said:
>
> I understand and respect your desire that all existing sw remain
> compatible with previous rom versions regardless of which entry points
> may have been used; however simply don't believe that inhibiting the
> practical ability to implement rom improvements, especially when such
> sw may be re-complied/assembled to remain compatible, is sensible. As
> just my opinion, nothing more.
I don't think you realise the implications of what you saying should it
work as you describe.
If entry points move, it means that even a UserRPL program isn't
guarantee to work from one version to another.
How would that be acceptable ?
There are over 5000 supported entry points. Should any of them changes
and you will get serious crashes. From User RPL program not working
anymore to some libraries: like the Equation Library.
>
> (Just as the use of inherently non-portable physical entry points
> within OS kernels, etc. may not warranted to remain stable from
> release to release; and thereby why some sw is dependent on a
> particular version of OS implementation; although it's host hw remains
> the same; as I'm sure you know, although also wish otherwise.)
Windows Vista still manages to run progams from Windows 95 days ...
>
> Obviously in a perfect world, everything remains fully backward
> compatible; however in a practical world, this may often only be
> achieved within some bounds of reason, dependent upon what one is
> willing to sacrifice.
Not keeping backward compatibility between different calculator series
is one thing, not keeping backward compatibility between firmware
update on the same model is another ...
JY
Dave Hayden
contexts, so I just wanted to add my 2 cents worth.
It's largely an issue of binary compatibility vs. source code
compatibility.
To maintain binary compatibility, HP needs to maintain the entry
points. Ideally, one does this by making them entries in one or more
jump tables and it sounds like that's been done for some of the
calculator entry points. For the others, if the implementation
becomes too large, then you have to code it to jump to another area of
memory before it overruns the allocated space. It sounds like space
is tight in the ROMs so this might be hard to do. I have no idea.
Also, I think HP would be wise to prevent other areas of the OS that
are NOT intended to be supported entry points by deliberately moving
that code around from one ROM release to the next. Please note that
I'm not talking about any of the entry points in entries.a here. I'm
talking about entries that are not supported and are not intended to
be supported. The reason to poison such entry points is to prevent
them from becoming defacto standards.
Then there's source code compatibility. If HP breaks binary
compatibility is a significant way then they should call the results a
new calculator, indicate as a new series in the binary files etc. But
at the same time, they should probably try to maintain source code
compatibility so developers can recompile their software to get it
working on the new system.
Breaking source code compatibility is a big step and HP would need a
very good reason to do this.
If I were ruler of the universe, I'd maintain binary compatibility as
long as the calculators are running the emulated Saturn, but I'd be
working hard right now on an ARM-based RPL engine. Port the OS to so
it's running all ARM code (whether assembly or ARM RPL). Make a bunch
of enhancements and release the new beast as a new series. You'd lose
binary compatibility but hopefully maintain path for converting source
code to the new platform.
Dave
schlie
> Hi
>
> On 2009-03-21 06:27:57 +1100, schlie <sch...@comcast.net> said:
>
>
>
> > I understand and respect your desire that all existing sw remain
> > compatible with previous rom versions regardless of which entry points
> > may have been used; however simply don't believe that inhibiting the
> > practical ability to implement rom improvements, especially when such
> > sw may be re-complied/assembled to remain compatible, is sensible. As
> > just my opinion, nothing more.
>
> I don't think you realise the implications of what you saying should it
> work as you describe.
>
> If entry points move, it means that even a UserRPL program isn't
> guarantee to work from one version to another.
>
> How would that be acceptable ?
I merely presume (quite possibly naively) that a large majority of
user code which may have relied on unstable entry points, may be
effectively decompiled to text and re-compiled with the newer mappings
if absolutely necessary (as is my understanding of how code may be
transferred from the 48 to 50 for example). I understand that this is
minimally potentially a pain ...; and should be avoided if at all
reasonably possible while attempting to achieve other goals. (it's
just not clear to me that it should be avoided at all costs.)
Veli-Pekka Nousiainen
viestissä:95f6aa4e-03c8-4476...@h5g2000yqh.googlegroups.com...
> I've had some experience looking at compatibility issues in other
> contexts, so I just wanted to add my 2 cents worth.
>
> It's largely an issue of binary compatibility vs. source code
> compatibility.
> If I were ruler of the universe, I'd maintain binary compatibility as
> long as the calculators are running the emulated Saturn, but I'd be
> working hard right now on an ARM-based RPL engine. Port the OS to so
> it's running all ARM code (whether assembly or ARM RPL). Make a bunch
> of enhancements and release the new beast as a new series. You'd lose
> binary compatibility but hopefully maintain path for converting source
> code to the new platform.
>
> Dave
releasing WinCE machine with emulator
(like they are almost doing today)
and giving UserRPL as RPL/2 + xCAS
with full RAM & ARM support, no SRAM
but 256MB DRAM
Use Mobile Phone Edition (or Linux or Symbian)
and thus a student could have
a) dedicated slide-in calculatrice keyboard
with Saturn Emulation (as now)
b) full RAM new system xCAS + RPL/2
c) a mobile phone
d) PIM software
people are used to charge overnight
so Lion and color LCD + HW 3D is used
New Xplorer II is born! (Qonos II ?)
--
VPN
John H Meyers
> Anyone with any lower level sw experience, knows this implicitly;
> and correspondingly knows use of such entry points are at best risky...
The highly experienced and proficient Dr. Bill Wickes,
who designed the RPL architecture,
knew exactly what he was doing,
and thanks to his efficient design
and rather brilliant implementation
(thoroughly explained in the apparently still unread "rplman.doc"),
HP had an innovative, winning (and profitable) series of calculators,
superior to any competition, for a long while.
Too bad you weren't around back then, to correct him and improve things,
but you could always join HP now, spearhead the next wave of successful products,
then wait 20 more years to have someone like you come along,
to tell you what an idiot you were.
http://en.wikipedia.org/wiki/HP-48_series
[r->] [OFF]
John H Meyers
> Well after roughly a week of moderate use of the much beloved 50g with
> ROM 2.14, I have had no other issues other than the initial hiccup
> with Port 2. I have cleared flag 40, which still without fail
> triggers the initial problems and never triggers them if said flag
> is cleared, not sure if I actually used the time anyways...
The appearance of the "tip of the iceberg"
(also reported relative to the independent HP Equation library)
suggests a larger problem looming.
There's evidently a minefield in the 2.14 ROM
(marked "beta" and "not supported," after all),
and no one knows where or what will blow up,
particularly when using any third-party software,
which used to reliably work across all versions
(when written properly, following guidelines).
Want to fly with a pilot who has had only a few epileptic seizures,
but none thus far today? At least it's more exciting than
the dull old routine of no crashes for quite a long while :)
Can anyone find this ROM via an HP web site?
Is anyone gaining any benefit from it?
"If you are brave, please help test this, but it is not supported"
http://www.hpcalc.org/details.php?id=7097
[r->] [OFF]
schlie
Actually, I don't believe I criticized it's implementation; but merely
observed there are inherent risks associated with relying on such an
implementation's entry points remaining constant.
(John, I apologize for upsetting you; let's please put this behind us;
as I believe everyone understands our respective positions. I promise
I won't post on the subject any further, so you may have the last word
if you wish.)
Veli-Pekka Nousiainen
Again RPN-posting, sorry
There are stable supported entries
They stay that way
If there is a bug then it will be fixed
Just wait...be patient!
____________________________________________________
"schlie" <sch...@comcast.net> kirjoitti
viestissä:ebcb28f4-d8f5-45b5...@g19g2000yql.googlegroups.com...
Joe Horn
> Is anyone gaining any benefit from [ROM 2.14]?
Yes, but only because it has the StreamSmart aplet built in. If you
don't use a StreamSmart, I do NOT recommend upgrading to 2.14 due to
port-2-related problems already described in this thread.
-Joe-
brian.mag...@gmail.com
<velipekka.nousiai...@saunalahti.fi> wrote:
> Nice problem solving!
> So I'll wait for the next ROM to be released
> where this bug is fixed
> It should be easy to locate now
> that you have found that flag -40 is involved
> Thanks!
> VPN
> PS: Since your comments are always so perfect
> you should be a beta-tester
> => one more pair of eyes to find those nasty bugs that creep in...
>
> "Jacob Wall" <j8w1...@hotmail.com> kirjoitti
> viestissä:c461dfd8-1e47-4262-aa92-54dead949...@w1g2000prk.googlegroups.com...
> On Mar 15, 7:08 pm, timwess...@gmail.com wrote:
>
> > > with your installations, and are not entering each time 2. STO to
> > > store a library to Port 2. Have you or anyone else tried installing
> > > the new EqnLib.lib file using the method I was using?
>
> > Ok. I did get it to hang. The program to install it works just fine
> > for me whether run from the SD card or in the calculator, but a manual
> > STO on the stack does seem to hang. However, only on one of my units
> > (the empty one). The others that have about 500kb in port 2 had no
> > problem. Strange.
>
> > TW
>
> Hey, I believe I have found the problem. I completely wiped out my 49G
> +, factory settings, except RPN mode set and the 2. STO worked!!!!
>
> So I went down the list of flags, matching it to my 50g, and the
> problem seems to be dependent on Flag 40 Show Clock, If flag 40 is
> set, my calculators hang everytime, however when I clear flag 40, no
> problems. Weird.
>
> Jacob
HP should have a fix out relatively soon.
The problem is related to interrupts. It's best not to store anything
in port 2 right now unless you're willing to have it corrupt
everything in that port. If you live on the edge, you're less likely
to hit the problem if you've just done a garbage collection (doing MEM
will force garbage collection) and only store one thing into port 2
between garbage collections. One option would be to store everything
you need into port 2 before loading 2.14.
If you've corrupted your port 2 you can fix it by installing this ROM.
ftp://ftp-fourier.ujf-grenoble.fr/xcas/hpcas/hp49g.zip It will reset
your port 2.